---
name: weekend-family-activities
description: >-
  Find weekend (or any-day) activities near the user that suit their family and
  kids. Use this skill whenever the user asks what to do this weekend, wants
  ideas for outings with their kids, asks for family-friendly events, things to
  do near a town/city, or anything like "help me plan something fun for the kids
  Saturday" — even if they don't say the word "activity." Searches local events
  from official and reputable sources within a chosen radius, filters by kids'
  ages and the family's interests, and returns a ranked shortlist with a source
  link for each so the user can verify details before going.
---

# Weekend Family Activities

Help a parent (or caregiver) decide what to do with their kids on an upcoming
day — usually a weekend — by finding real, currently-scheduled local activities
that fit their family. The goal is a short, trustworthy shortlist the user can
act on today, not an exhaustive listicle. Every suggestion carries a source link
so the user can confirm the details themselves, because event times, prices, and
age rules change often and a wrong detail wastes a family's whole outing.

## The shape of a good run

1. Load any saved family profile so you don't re-ask what you already know.
2. Settle the **when** and **where**.
3. Confirm **who's coming** (kids' ages/count) and **what they like**.
4. Check the **weather** for the target date(s).
5. Search real sources for events happening on the target date(s).
6. Return a ranked shortlist — weather-aware — each with a source link.
7. Offer to add chosen ones to the calendar.
8. Save/update the profile for next time.

Move quickly. If the profile already answers the setup questions, skip straight
to searching and just confirm the details in one line ("Using Ann Arbor, MI,
20-mile radius, your two kids ages 5 and 8 — searching now.").

## Step 1 — Load the saved profile

Before asking anything, check for a saved profile at
`~/.weekend-family-activities/profile.json`. If it exists, read it and use its
values as defaults. A profile looks like:

```json
{
  "location": "Ann Arbor, MI",
  "radius_miles": 20,
  "kids": [
    {"age": 5, "notes": "loves animals"},
    {"age": 8, "notes": "into science, gets bored on long walks"}
  ],
  "interests": ["outdoors", "museums", "hands-on"],
  "avoid": ["anything past 8pm"]
}
```

If there's no profile, that's fine — you'll build one at the end. Never block on
it.

## Step 2 — When and where

**When:** Establish the actual calendar date. Run `date` in the shell to anchor
"today," then resolve what the user means — "this weekend" is the upcoming
Saturday and Sunday, "Saturday" is the next one. State the resolved date back to
the user so there's no ambiguity ("this weekend = Sat Jul 25 & Sun Jul 26").
Search for events on those specific dates.

**Where:** You need a town/city and state (or equivalent). Take it from the
profile if present; otherwise ask. Then settle the search radius. Offer 10, 20,
and 50 miles as easy anchors, but accept **any** distance the user names (30, 25,
15 — whatever fits their willingness to drive) and honor it exactly. Default to
whatever the profile holds, or 20 on a first run. A bigger radius is worth
suggesting for small towns where 10 miles may turn up little; a tighter one suits
young kids who don't travel well.

**Lock the region, always.** Many town names repeat across states — there's an
Arlington in MA, VA, TX, and more — and searches will happily drift to the wrong
one, especially with national publishers like Macaroni KID. Once you know the
state, carry it in every query (`"<town>, <state> ..."`) and, when you land on a
listing, sanity-check that its town/state actually matches before trusting it.
Also anchor by nearby landmarks the user would recognize (neighboring towns, the
metro area) so results stay in the right place — for Arlington, MA that means
Boston-area towns like Cambridge, Lexington, Winchester, not a Virginia suburb.

## Step 3 — Who's coming and what they like

You need enough to filter sensibly, not an interrogation. Ask for:

- **How many kids and their ages.** Age is the single most important filter — a
  toddler and a twelve-year-old want completely different things. Gender rarely
  matters for activity fit; only factor it in if the user volunteers it or asks.
- **Activity interests**, if any. If the user has no preference, treat that as
  "open to all kid-appropriate activities" and cast a wide net rather than
  pressing them to choose. Useful buckets to offer as examples: outdoors/parks,
  museums & science centers, library & story times, sports & active play, arts &
  crafts, animals/zoo/farm, festivals & fairs, movies/shows.
- **Any constraints** worth knowing: budget (free-only?), timing limits, nap
  schedules, accessibility, indoor-only if the weather's bad. Ask lightly — one
  combined question is better than five.

Ask only for what's missing from the profile. Bundle open questions into a
single message so the user answers once.

## Step 4 — Check the weather

Pull the forecast for the target date(s) and location before you rank anything.
Weather is decisive for a family outing — a heat advisory, rain, or cold snap can
turn a great outdoor plan into a miserable one, and it matters most for the
youngest kids, who tolerate extremes poorly. So treat the forecast as a real
input to the shortlist, not a footnote.

Get it from an authoritative source. The U.S. National Weather Service
(`forecast.weather.gov`, or the `api.weather.gov` JSON API) is free, reliable,
and needs no key — prefer it. AccuWeather, Weather.gov's mobile pages, or a
`WebSearch` for "<town> weather Saturday" work as alternatives or cross-checks.
Note the high/low, chance of precipitation, and any advisories (heat, air
quality, storms) for each target day.

Then let the forecast steer the ranking:

- **Nice weather** → favor outdoor options (parks, spray pads, farms, festivals)
  and say why the timing is good.
- **Rain, extreme heat/cold, or air-quality alerts** → lead with indoor options
  (museums, libraries, indoor play, aquariums) and demote or flag the outdoor
  ones. For a spray park on a 95°F day, note the heat; for a hike in the rain,
  don't rank it first.
- **Mixed / one good day** → point out which day is better for the outdoor
  picks so the user can plan around it.

Always surface the forecast to the user in a line or two so they see the
reasoning behind the ordering ("Sat looks sunny and 78°F, Sun has afternoon
showers — so I've put the outdoor picks on Saturday").

## Step 5 — Search real sources

Find events actually happening on the target date(s) within the radius. The goal
is **dated, scheduled activities** — a story time at 10:30am Saturday, a nature
program, a festival — not a list of places that merely exist. A business
directory can tell you a trampoline park is in town, but only an events calendar
tells you there's a toddler open-play session this Saturday morning.

The reliable way to get there is a **place-first pipeline**: figure out which
towns are in range, list the kid-friendly venues in those towns, then read each
venue's own calendar. Going straight to the source calendars beats hoping a
generic search surfaces them. Work the pipeline in three phases:

### Phase A — Build the town list by distance

Starting from the user's town, list the nearby towns/cities that fall within the
chosen radius, roughly nearest-first. A quick `WebSearch` like `"towns within 20
miles of <town>, <state>"` or reasoning from a map works. Keep the user's own
town first, then expand outward. This ordered list is your search frontier —
nearer towns matter more because a family won't drive an hour with a toddler.

### Phase B — Enumerate kid-friendly venues in those towns

For each town (nearest first), identify the venue types that actually run
children's programming: **public libraries, museums & children's museums, science
centers, zoos & aquariums, nature centers / Audubon sanctuaries, botanical
gardens & arboretums, farms & petting farms, Parks & Rec departments, community
centers / YMCAs, and state or regional parks.** A directory or map search (even
Yelp or Google) is *fine here* — this is the one place their venue lists are
useful. You're only collecting venue **names and official sites**, not treating
their listings as activities.

### Phase C — Fetch each venue's own activity calendar

Go to each venue's official site and read *its* events/programs calendar with
`web_fetch` (or `WebSearch` for `"<venue> events calendar"`). This is where the
real dated activities live:

- **Library calendars** — the densest source of free toddler/kid programming
  (story times, sing-alongs, crafts). Often on LibCal (`<library>.libcal.com`).
- **Parks & Rec portals** — MyRec, RecDesk, CivicRec/CivicPlus,
  ActiveNet/ActiveCommunities host sign-up programs and drop-in events.
- **Museum / zoo / nature-center / farm / garden calendars** — special programs,
  not just open hours.

Then **fill gaps** with curated family-event publishers that aggregate across
towns — Macaroni KID (hyperlocal), Mommy Poppins, "Boston Central", "<City> with
Kids", local newspaper/Patch community calendars — plus Eventbrite and Meetup
filtered to kids/family + date. These catch one-off festivals and pop-ups that no
single venue calendar lists.

### Keep it bounded and honest

You don't have to crawl every venue in every town — that's slow and unnecessary.
Prioritize: cover the user's own town thoroughly, then the nearest few, and among
venues lead with the types most likely to have something for the kids' ages
(libraries and nature/animal spots for toddlers; science centers and museums for
older kids). Stop once you have a strong shortlist.

Two practical snags to expect: many calendars (LibCal, MyRec, ActiveNet) are
**JavaScript-rendered**, so a plain `web_fetch` may come back empty or without
dates — when that happens, fall back to a targeted `WebSearch` for that venue's
events, or note the calendar exists and point the user to it rather than guessing
what's on it. And watch the region: confirm each venue's town/state matches the
user's area (see the region guard in Step 2) so you don't pull an event from a
same-named town in another state.

For each candidate activity, pin down: name, what it is, venue + rough distance
from the user's town, date/time, age suitability, cost, and **how to get there
and park**. If a detail isn't findable, say so rather than guessing — a
confidently wrong price or time is worse than an honest "check the site."

### Getting there and parking

Distance alone doesn't tell a parent whether the outing works. A free lot fifty
feet from the door is a different Saturday than circling a downtown block with a
five-year-old in the back seat, and a venue that's a ten-minute bus ride may beat
one that's closer but has no parking at all. So for each pick, note whichever of
these you can actually verify:

- **Parking** — on-site lot vs. street vs. paid structure, cost, and whether it
  fills up (many venue sites say so outright: "the lot fills by 10am on event
  Saturdays").
- **Transit**, when it's genuinely competitive — a bus or train line that lands
  near the door, with the route named. Don't manufacture a transit option for a
  suburban nature center that nothing serves.
- **Anything that changes the plan** — a park entry fee charged per vehicle, a
  festival shuttle from a remote lot, event-day road closures, stroller-hostile
  approaches.

Venues' own **"Visit," "Directions," "Plan Your Visit," or "Parking"** pages are
where this lives, and you're often already on the site reading the events
calendar — grab it in the same pass. City parking authorities and transit
agencies (the local transit authority's trip planner, a downtown development
authority's parking map) cover the venues that don't say.

**Same sourcing rule as everything else: verified or omitted.** Do not infer that
a museum has free parking because museums usually do, and do not assemble a
plausible-sounding transit route from a map. If the venue's site doesn't say and
a quick check doesn't turn it up, write "parking not listed — check before you
go" and move on. An honest blank costs the user thirty seconds; an invented lot
costs them the morning.

**Sourcing rule:** every activity you present must include the URL you got it
from so the user can fact-check. Never invent an event or its details. If
searches genuinely turn up little (small town, quiet weekend), say so plainly and
suggest widening the radius or offer evergreen options (local park, library
drop-in, nearby larger town) clearly labeled as not date-verified.

## Step 6 — Present a ranked shortlist

Give a **short** list — roughly 4 to 7 of the best fits, ranked by how well they
match this family, not a data dump. Rank on: age fit first, then weather fit and
interest match, then convenience (distance, timing) and cost. Lead with why each
one suits *this* family, and let the forecast from Step 4 shape the order —
indoor options rise on a bad-weather day, outdoor options on a good one.

Present in chat as a clean scannable list. For each item include: name, a
one-line what/why-it-fits, date & time, distance/location, age fit, cost, how to
get there and park, and the source URL. For example:

> **1. Dino Discovery Day — Hands-On Museum** · Sat 10am–1pm · ~8 mi (Ann Arbor)
> Live fossil dig and animal encounters — hits your 5-year-old's animal love and
> your 8-year-old's science streak. Ages 3–10. $8/kid, adults free.
> Getting there: free lot behind the building, fills by 10:30 on event days.
> Source: https://example.org/dino-day

Keep the getting-there line to one line, and drop it entirely rather than pad it
— "parking not listed — check before you go" is fine, but only say it when it
matters (a downtown venue, a festival), not on every item.

Keep the prose light and warm — you're helping a parent picture the day, not
filing a report. After the list, note anything worth a heads-up (weather,
registration required, sells out).

## Step 7 — Offer the calendar

After presenting the shortlist, ask which ones (if any) the user wants on their
calendar. Don't add anything preemptively. When they choose, create events with
the calendar tool using the confirmed date/time, venue as location, and the
source URL in the notes. If no calendar tool is connected, offer a copy-pasteable
summary or an .ics file instead.

## Step 8 — Save the profile for next time

At the end, write or update `~/.weekend-family-activities/profile.json` with the
location, radius, kids' ages/notes, interests, and any constraints learned this
run. On future runs this is what lets you skip the setup questions. If the user
corrects something ("actually the little one is 6 now"), update the profile so it
stays current. Mention once that you've saved their defaults; don't belabor it.

## Guardrails

- **Accuracy over volume.** A trustworthy list of four beats a padded list of
  twelve. Every item needs a source link.
- **Don't re-ask what you know.** The profile exists so returning users get to
  suggestions fast.
- **Kids' safety and privacy.** Keep details to what's needed for activity fit.
  Don't request or store more about children than ages and light preferences.
- **Be honest about gaps.** If you can't verify a time or price, say "confirm on
  the site" rather than inventing one.