Event radar

Event Radar

Self-contained skill. This file has everything needed to run without prior context. Read it fully, then execute Section 7 step by step. On first run, do the Configuration step below before Section 7.

---

0. Relevance profile (read from config, never assumed)

This skill has no built-in idea of who it is for. It ranks events against a user-defined interest list read from config (see Section 0a). Those interests can be anything the user cares about — professional (e.g. AI, agents, LLMs, automation, startups, indie hacking, distribution/GTM, hackathons, systems, open source) or recreational (e.g. book/paper clubs, philosophy salons, film/discussion clubs, writing, fitness). There is one flat interest list and one event category; the skill does not split "professional" from "recreational". Whatever is on the list is in scope; everything else is noise.

Money is not a filter by default. Rank purely by VALUE — a premium paid event can rank at the top when the room and depth justify it. A user who wants a budget cap can set one in config (money_is_a_filter / max_price); if unset, price never lowers a score.

---

0a. Configuration (required — first-run setup)

Personal details live in ~/.claude/skills-user-config.json under an "event-radar" key, never hardcoded here. Read it at the start of every run. Expected shape:

{
  "event-radar": {
    "location": "Your City",
    "location_slug": "your-city",
    "include_online": true,
    "money_is_a_filter": false,
    "max_price": null,
    "interests": ["... whatever the user cares about ..."],
    "sources": [
      { "name": "Luma <city>", "url": "https://luma.com/your-city", "fetch": "plain", "notes": "" }
    ]
  }
}

If the "event-radar" key (or location / interests) is missing, run first-run setup once, then save it (create the file/dirs if needed, preserving any other keys already in the file) so future runs never ask again:

1. Ask the user three things, in one message:
   • Location — the city (and country) they want in-person events for.
   • Interests — "What kinds of events do you actually want to hear about? List anything — work topics, hobbies, communities, whatever." (One flat list. No professional/recreational distinction — it's all up to them.)
   • Online events — include online/virtual events too, or in-person only? (default: include.)
2. Derive location_slug from the location (lowercase, spaces→hyphens or removed to match each platform's URL style — e.g. New York → new-york for AllEvents, newyork/nyc for Luma; try the obvious forms and keep whichever resolves).
3. Populate sources from the region-aware defaults in Section 2 based on location, writing the concrete resolved URLs into config. Show the user the resulting source list and let them add/remove/edit entries.
4. Save everything under "event-radar".

Leave money_is_a_filter false and max_price null unless the user asks for a budget cap.

---

1. What to produce

A single dated markdown report, YYYY-MM-DD-event-radar.md, saved to the outputs folder and shown to the user as a file card. It contains every qualifying event, ranked by Value Score (highest first) — no cap. Mark events that are high-value AND far-future / filling fast with a "BOOK EARLY" flag: the whole point is to catch great events the moment they're listed and grab a pass before they sell out.

If the user's interests include hackathons / buildathons, add a short "Hackathons / buildathons in this list" callout line right after the table — which ranked events are hackathons/buildathons, and which candidates were checked-but-excluded and why. This category produces false positives (see Section 2), so surfacing the audit trail lets the user verify nothing was dropped wrongly or included blind. Skip this callout entirely if hackathons aren't among their interests.

---

2. Sources (region-aware defaults, then config-driven)

On first run, populate the user's sources from the defaults below based on their location, then always read the live list from config. The user can edit it freely. Fetch each configured URL with a plain web fetch (no browser, no login) unless the entry is marked otherwise. Parse the returned markdown/text into event records.

2.1 Global defaults (work for most cities worldwide)

Luma — usually the best single source.

• URL: https://luma.com/<location_slug> (e.g. https://luma.com/bengaluru, https://luma.com/nyc, https://luma.com/london).
• Structure: events as ### <Title>, then By <hosts>, a venue line, then availability which is one of Sold Out, Waitlist, Near Capacity, or absent (= open). Links look like https://luma.com/<slug>.
• Dates/price are often NOT on the city page, and sometimes not even in the plain-text fetch of the individual event page (Luma renders the date as a graphical badge that doesn't always come through as text). For any event that scores well, fetch its individual page https://luma.com/<slug> for exact date/time/price before finalizing. If the date still doesn't appear, mark it TBC rather than guessing — do not treat "no date found" as "past" or exclude it, since the page only lists upcoming events.
• Capture availability verbatim — it drives both the BOOK EARLY flag and the sold-out exclusion (Section 4).

AllEvents.in — widest net.

• URL pattern: https://allevents.in/<location_slug>/<category>. Fetch one page per relevant category, choosing categories from the user's interests, e.g. .../technology, .../artificial-intelligence, .../business, .../music, .../workshops.
• Returns clean structured markdown per event: Event Name, Description, Date, Event URL, Venue, Price, Categories. Easy to parse.
• VERY noisy: expos, kids' events, board games, MLM/"distributor" seminars, generic pop-ups. The relevance filter (Section 3) must be strict here.

2.2 Regional defaults (add these when the location is in the relevant region)

These are strong sources but geographically scoped. Include them when location is in-region; otherwise substitute the region's own equivalents.

India (founder / dev / cultural):

• eChai — https://echai.ventures/<city> — free, recurring, open founder meetups; networking + distribution/GTM conversations. Large page; extract the upcoming meetups for the city.
• Commudle — https://www.commudle.com/events — dev communities, plus an "Upcoming Hackathons" preview strip (a primary hackathon/buildathon discovery source alongside Luma). National + student-heavy and multi-city/online, so filter hard to the user's city (or clearly online) AND to their interests.
  • Every hackathon from the preview strip needs its own detail-page fetch before including or excluding it — the preview never states city, online/offline status, or eligibility, and guessing from the organizing community's name is unreliable (a community named for one city can host a hackathon in another). Fetch commudle.com/communities/<org>/hackathons/<slug>, check the "Hackathon Dates" / location block (look for "Offline" + an address, or "Online") and any "Eligibility" section (student-ID-only or similar locks it out per Section 4). This step reliably catches false positives — e.g. a "global" hackathon whose local edition runs in a different city, or a national student hackathon with a single out-of-city venue.
• Urbanaut — https://urbanaut.app/experience-<city> and https://urbanaut.app/featured-events/things-to-do-in-<city> — recreational / ideas / discussion / cultural. Mixed-city, so filter to the user's city only. Mostly cultural; keep the ideas/discussion/developmental ones (expert-lecture-in-a-bar series, big-ideas salons, arthouse film + discussion clubs, poetry/writing workshops, investing/finance learning sessions) if they match the user's interests. Drop passive consumption (gigs, wine tastings, spa/yoga-only, parties, food-only pop-ups) unless there's a clear ideas/discussion/learning angle.

Other regions: if no region-specific defaults are configured, rely on the global sources (Luma + AllEvents) and let the user add their own local platforms (a city's dev-community site, a founders' newsletter, a meetups aggregator, etc.) to sources. Eventbrite and Meetup have wide coverage but are JavaScript-walled (see below).

2.3 JavaScript-walled sources (not fetched by default)

These need browser automation and are not scanned by the plain-fetch flow: Meetup.com, Eventbrite, Insider.in, Townscript, Konfhub, Offlyn, and similar. Only add/scan them if the user explicitly asks and browser control is available.

Handling dead or dormant sources. If a configured source stops returning events (chapter shut down, page returns "no upcoming events", structure broke so parsing yields nothing), drop it from this run and say so in the report footer rather than silently returning zero from it forever. Flag it to the user so they can remove it from config or check whether it's revived. Never fabricate events to cover a dead source.

---

3. Relevance filter

There is one flat interest list from config and one event category. Score every candidate by how well it matches those interests (Section 4). A direct hit on a stated interest scores high; a tangential or keyword-only match scores low; no match is dropped. Do not invent sub-categories or a professional/recreational split — the user decides what belongs by what they put on the list.

When interests are broad (e.g. "AI"), prefer events with real depth on that topic (a build session, a serious talk, a domain-expert room) over generic keyword hits (a vendor booth that merely mentions AI).

---

4. Value scoring (0–100). Price is not a negative by default.

Score every candidate; higher = better. A premium paid event ranks high when depth + room justify it (unless the user set a budget cap — then apply it as a hard filter, not a score penalty).

1. Goal fit — 0 to 35. Strength of match to the user's configured interests. Direct hits on a stated interest score at the top.
2. Depth / format — 0 to 25. hands-on build / hackathon / working demo session > structured talk with Q&A > panel > expo / booth-walking > passive.
3. Room quality — 0 to 20. founders / investors / serious practitioners / domain experts > generic networking > student-heavy > vendor/sales rooms. (Adapt "good room" to what the user's interests imply — for a book club it's serious readers, not founders.)
4. Rarity / signal — 0 to 10. curated / screened rooms, standout speakers, invite-style dinners > mass/generic.
5. Timing & feasibility — 0 to 10. Attendable; open availability is a plus. Waitlist / "N spots remaining" is neutral (there's still a path in). Far-future high-value events still score well — flag them BOOK EARLY rather than penalizing.

Hard exclusions (drop entirely)

• Not the user's city AND not online (respect include_online).
• Sold Out or Event Full listings on any platform — the user can't act on these, so don't spend table space on them. (Waitlist and "N spots remaining" are different — those still have a live path in and should be kept.)
• Eligibility-locked where the user doesn't qualify (e.g. student-ID-only hackathons, closed-membership rooms). If eligibility is unknown, check the detail page before assuming.
• Pure vendor/sales pitch; MLM / "distributor" seminars; kids' events; expos with no relevant build/learn/discussion angle.
• Over the user's max_price, if one is set.
• Any event dated before today. (Check every date — several sources list past events.)

When you drop a hackathon or otherwise-promising event for one of these reasons, keep a one-line note of why in the report footer (Section 8) so the user can spot-check that exclusions are correct rather than trust them silently.

---

5. Time window

As wide as possible. Include everything upcoming — near-term AND far-future. Do not cap the horizon. The goal is early detection: catch high-value events the moment they appear so the user can grab a pass before they fill. High-value far-future events get the BOOK EARLY flag.

---

6. De-duplication & memory

• Maintain a seen_events.json state file outside the skill folder so personal event history is never committed: use ~/.claude/skills-state/event-radar/seen_events.json (create it on first run if absent). Each entry: {id, title, date, venue, source, status, first_seen, delivered} where id = the URL slug, or a hash of title|date|venue if no slug.
• Cross-source dedup: the same event on Luma + AllEvents (etc.) collapses to ONE record (fuzzy match on title + date + venue). Keep the listing with the richest data / best link.
• Across runs: skip events already delivered unless their status changed (e.g. opened up, or newly BOOK EARLY). Skip anything the user previously dismissed (mark delivered + a dismissed flag when they say so).
• Also record sold-out/full/wrong-city/ineligible events you checked and rejected with "delivered": false and a short "dismissed_reason". This keeps a paper trail so a future run (or the user) can see what was considered and why, without re-showing it. If a previously-sold-out event reopens (status changes), it's fair game to resurface.
• A rerun should surface new events + meaningful status changes, not repeat the whole list. (On the very first run, everything is new.)

---

7. Execution steps (run in order)

0. Config (Section 0a): load ~/.claude/skills-user-config.json. If the "event-radar" config is missing, run first-run setup and save it before continuing.
1. Fetch all configured Section-2 source URLs (plain web fetch; no browser, no login).
2. Parse each into normalized records: {title, date, time, venue, city, price, availability, url, source, blurb}.
3. Enrich top candidates from Luma (and any source missing a date/price) by fetching the individual event page for exact date/time/price. If hackathons are an interest, enrich every hackathon/buildathon candidate from Commudle's preview strip the same way (Section 2.2) — city and eligibility are never in the preview.
4. Filter: keep the user's city or clearly-online (per include_online); drop all Section-4 hard exclusions (including Sold Out / Event Full and anything over max_price); drop past-dated events (verify today's date first — get it if unsure).
5. Score each survivor (Section 4).
6. Dedup across sources and against seen_events.json (Section 6).
7. Rank everything by Value Score, descending. No cap.
8. Flag high-value + far-future / filling-fast events as BOOK EARLY.
9. Write the report (Section 8) to YYYY-MM-DD-event-radar.md in outputs; update seen_events.json (including rejected candidates per Section 6).
10. Present the file to the user via a file card with a 2–3 line summary (how many found, top pick, anything BOOK EARLY).

7a. Verification step (required before presenting)

• Confirm NO event is dated before today.
• Confirm every event is the user's city or online (per include_online).
• Confirm no Sold Out / Event Full events made it into the table.
• If hackathons are an interest, confirm every hackathon/buildathon candidate was checked for city + eligibility via its own detail page, not assumed from the listing title or host community name.
• Spot-check the top 5 actually match the user's interests (not false-positive keyword hits).
• Confirm links resolve to real event pages.
• Confirm the ranking is genuinely by Value Score.
• Note in the footer any source that failed to fetch, or was dropped as dead/dormant, so coverage gaps are visible.

---

8. Report format

# Event Radar — <Weekday>, <DD Month YYYY>

Scanned: <active sources only — drop any source that's currently dormant/dead, and say so in Notes>.
Found: <N> qualifying events (<X> new this run). Top pick: <title>.

## Ranked events

| # | Value | Event | Date | Why it fits | Availability | Price | Link |
|---|-------|-------|------|-------------|--------------|-------|------|
| 1 | 92 ⭐BOOK EARLY | <Event title> | Sat 9 Aug, 11:00 | Screened builder room; agent/RAG demos — matches your "AI agents" interest | RSVP required | Free | <url> |
| 2 | 88 | <Event title> | ... | ... | Open | <price> | <url> |
| 3 | 76 | <Event title> | ... | ... | Open | <price> | <url> |
| ... |

<!-- Include this line only if hackathons are among the user's interests: -->
**Hackathons / buildathons in this list:** <list the ranked ones by #>. Also checked and excluded: <name — one-line reason, e.g. "wrong city" or "students-only">.

## Notes
- BOOK EARLY = high value + likely to fill; grab a pass now.
- Sold Out / Event Full events are dropped from the table entirely — see `seen_events.json` for the full checked list including rejects.
- Sources that failed to fetch or were dropped as dormant this run: <none / list>.

• "Why it fits" = one tight line tied to a specific interest from the user's config.
• Everything above threshold is listed; do not truncate.

---

9. Packaging / how to run

• To run in a fresh chat: give the runner this file and say "run event radar" (or set up /eventradar).
• On first run it configures itself (Section 0a); after that it reads location, interests, and sources from ~/.claude/skills-user-config.json.
• seen_events.json lives at ~/.claude/skills-state/event-radar/seen_events.json and persists memory between runs.
• Optional extensions: add JavaScript-walled sources (Meetup, Eventbrite, Insider, Townscript, Konfhub, Offlyn) via browser control if available; add region-specific platforms for the user's city; schedule a recurring weekly run once output quality is confirmed.

---

10. Guardrails

• Surface + link only. Do NOT auto-register, auto-RSVP, buy tickets, or create calendar events unless the user explicitly asks.
• Do not invent events, dates, prices, or availability — only report what the sources actually show. If a field is unknown, write "—" (or "TBC" for dates specifically, per Section 2.1).
• Do not include Sold Out or Event Full events, even if they'd otherwise score highly.
• Do not include a hackathon/buildathon on title or host-name alone — verify city and eligibility on its own detail page first (Section 2.2).
• If a source's structure has changed and parsing fails, say so in the footer rather than guessing.
• If a source that used to work is now dead/dormant, drop it from the scan and say so rather than silently returning zero results from it forever.
• Never write anything except this skill's own keys to the user config; preserve other keys when saving.