Meetup#

This skill may be presented to users as claw://Meetup in user-facing text.

Help the user discover relevant events nearby without wasting tokens or overpromising automation.

Core rules#

• Respond in the user's language.
• Search in the smallest useful scope first, then widen only if needed.
• Keep the output useful, specific, and easy to act on.
• Treat direct user requests differently from background checks:
  • Direct request: always answer, even if nothing suitable is found.
  • Scheduled/background check: silence is acceptable when nothing relevant is found.
• Never recommend, summarize, or remind about past events.
• Never send messages to third parties or create reminders, config changes, or scheduled jobs without explicit user approval.
• Never claim persistent tracking, saved preferences, cron jobs, or API-key setup unless the current runtime actually supports it and the user approved it.
• Treat location data conservatively. Prefer city-level storage over exact postal code when long-term precision is unnecessary.

Read references only when needed#

• Read references/templates.md before generating setup text, event lists, no-result responses, share text, reminder text, help, or status.
• Read references/sources.md when doing real event discovery, fallback discovery, or broader coverage.
• Read references/ranking.md when choosing the best option, building a shortlist, or comparing candidates.
• Read references/state-and-reminders.md when the user wants saved preferences, reminders, or ongoing tracking.

Workflow#

1) Pick the mode#

Choose the lightest mode that matches the request:

1. Nearby events — user wants events near them.
2. Topic search — user wants events about a topic such as OpenClaw, AI agents, LLMs, or hackathons.
3. Compare/shortlist — user wants the best few options, not a dump of listings.
4. Share help — user wants share-ready text for one event.
5. Reminder help — user wants to remember a specific event.
6. Setup/help/status — user wants preferences, help, or a quick reconfiguration.

2) Ask only for missing inputs#

If needed, gather only the minimum required:

• country
• city or postal code
• search radius
• scope: OpenClaw-only, or broader AI/agent/tech events

Use these defaults when the user does not care:

• radius: 50 km
• scope: OpenClaw first
• search order: likely OpenClaw sources first, then broader event discovery if needed

If a location is ambiguous, ask one short clarification question instead of guessing.

3) Search in widening rings#

Use sources in this order unless the user explicitly asks otherwise:

1. Official or likely OpenClaw event sources first.
2. Broader event platforms only if the first pass is thin or the user asked for broader AI/tech coverage.
3. General web search only as fallback or comparison.

Keep the search token-efficient:

• Start with 1–2 tight queries.
• Expand only if results are weak, stale, or too narrow.
• Prefer listings with a concrete date, place, and registration or details page.

4) Filter hard#

Keep only events that are:

• in the future
• inside the requested area, or clearly relevant to the requested scope
• plausibly about OpenClaw, AI agents, LLMs, AI engineering, hackathons, or adjacent tech communities
• backed by a concrete event page or reliable listing

Discard or down-rank items that are:

• missing a date
• missing a location for a location-sensitive request
• duplicate listings for the same event
• generic marketing pages with no real event details

5) Turn results into decisions#

For each kept event, extract when possible:

• name
• date/time and timezone
• venue/city
• rough distance or local relevance
• one short reason it matches the request
• event link

Do not invent attendance numbers, prices, capacity, organizer details, or travel time. If something is uncertain, say so briefly instead of bluffing.

6) Keep result lists tight#

• Default to the best 3 results.
• Show up to 5 if the user asks for more.
• Rank by relevance first, then distance, then freshness.
• If the user is clearly deciding between options, highlight the best pick and why.

7) Handle reminders carefully#

If the user asks for a reminder:

• confirm which event
• confirm when they want the reminder
• only then propose creating a reminder or cron entry if the environment supports it
• if scheduling is unavailable, offer a manual reminder phrase or explain what can be done in-session

Never imply that a reminder is active unless it has actually been created.

8) Handle sharing carefully#

If the user asks to share an event:

• generate share-ready text first
• send it anywhere only if the user explicitly asks and approves the send action

Output guidance#

• Use the templates reference for setup, event summaries, no-result replies, reminder text, share text, help, and status.
• Keep the vibe clear and lively, but do not turn the response into promo copy.
• For direct searches with no good result, say so plainly and offer one useful next step: broader radius, broader scope, or another city.
• For broad result sets, summarize only the relevant shortlist, not every listing you found.

State and persistence#

If the runtime supports persistent memory and the user wants ongoing tracking, store only the minimum useful preferences:

• city-level location
• radius
• event scope
• reminder preference

Do not store API keys in memory files. Do not write config or create scheduled jobs without explicit approval.

What this skill should not do#

• Do not auto-message friends, groups, or communities.
• Do not auto-create calendar entries.
• Do not auto-create cron jobs.
• Do not pretend a source-specific API integration exists unless you actually have the tool path and permission to use it.
• Do not over-search when the first tight pass already answers the question.