/roadtrip-skill

name: roadtrip-navigator
description: >
  Generate North American road-trip itineraries as a map-first, offline-friendly
  single-file HTML page. Plans around daily driving segments, overnight stops,
  fuel/EV-charging, national-park reservations (Recreation.gov / NPS), seasonal
  road closures, and timezone/border crossings — for executable, decision-ready
  trips. Two entry modes: give a start + region/destination + days and it plans
  the whole route, or hand it an existing route and it verifies, fills gaps, and
  produces the page.
read-when: >
  road trip, self drive, 自驾, 公路旅行, national park, scenic drive, RV trip,
  EV road trip, Southwest loop, route 66, drive itinerary, campground, 自驾路线,
  租车自驾, 环线, road trip planner, US/Canada drive, park reservation

RoadTrip Navigator

Turn **"start + days"** or **"an existing route"** into a road trip you can actually drive: paced into days, with overnight stops, fuel/charging, park reservations, seasonal road risks, and a map-first single-file HTML page.

North American road trips revolve around the **car**, not flights: *how many hours do we drive today, where do we sleep, will we make it on the fuel/charge we have, and is the road even open.* That focus is what this skill adds on top of a generic "list of attractions."

When to use

Use this skill whenever the request is about driving a multi-stop trip in the US / Canada / Mexico (see `read-when` triggers). If the user only wants a single city guide or a flight itinerary, this is not the right skill.

Two entry modes

Detect the mode up front (see `scripts/helper.py` for the heuristic):

• **Light mode (plan it for me):** user gives a start, a rough region or

destination, day count, and party/vehicle. → Run the full 7-step workflow, designing the route yourself.

• **Heavy mode (verify my route):** user pastes/links/screenshots an existing

route. → Skip route invention. Parse their route into the schema, then *verify and fill gaps*: driving segmentation, overnight realism, fuel/charge coverage, reservation countdown, seasonal closures, and produce the page.

When unsure which mode, ask one short question. Otherwise infer and proceed.

The five things that make this more than a list

These are where pure-model answers fail and where this skill earns its keep:

1. **Daily driving segmentation (the core).** Slice the whole route into days under a sane daily drive limit, place an overnight at each segment end, and *validate* each day: drive ≤ limit, arrive before dark, no stop hits a closed gate, fatigue buffer. This is the road-trip equivalent of connection-checking — most AI itineraries skip it. 2. **Reservation countdown.** Recreation.gov campgrounds often release ~6 months out; popular timed-entry a few days out; in-park lodges up to ~13 months out. From the departure date, work backwards into a "book by" to-do list. 3. **Fuel / charge planning.** Gas: flag long empty stretches ("next fuel in X mi"). EV: plan a charging corridor against the vehicle's range and note whether each leg makes it, charger power, and a backup. 4. **Seasonal road conditions & closures.** Mountain passes that close in winter (Going-to-the-Sun, Tioga Pass, Trail Ridge Rd), wildfire/hurricane/snow season. If the travel date hits one, down-rank or reroute and say so. 5. **Timezones & borders.** Correct arrival times across timezone lines; for border crossings, flag documents / vehicle papers / insurance / wait times.

Workflow (7 steps)

> Run `scripts/helper.py "<user request>"` first — it parses slots, guesses the > entry mode, picks the trip region (for HTML theming), and prints what's still > missing. Use its output to drive the steps below.

Step 1 — Collect requirements (slot filling)

Required: **start, travel date, days, party makeup, vehicle (gas/EV/RV + range)**. Optional: destination/region, budget, preferences (scenic vs. fast, hike intensity, loop vs. one-way, border crossing). Only ask follow-ups for missing **required** slots; fill the rest with sensible defaults and proceed.

**Validate place names before planning.** Slot presence is not slot truth: a made-up start like "ABC" parses fine and would otherwise flow straight into a fabricated route. Run every user-supplied place — start, destination, named waypoints; in heavy mode each day's from/to towns — through `python3 tools/places_client.py "<name>"` and branch on its verdict: `match` → adopt the returned canonical name + coordinates; `did-you-mean` → confirm the intended place with the user (one short question, same spirit as the required-slot follow-ups); `no-match` → **stop and ask — never plan a route around a place you could not verify**; `unverified` (offline) → use your own judgment and ask about any name you don't recognize. A `match` with `outsideNA: true` is a real place outside US/Canada/Mexico — tell the user it's beyond this skill's coverage instead of calling it fake.

Step 2 — Route / destination planning (if not given)

Decide **loop vs. one-way** first (affects one-way drop fees and pacing). For region-level input ("the Southwest", "Pacific Northwest"): search candidates → seasonal & closure check → shortlist. Compute rough total miles / driving days for the shortlist and drop any "can't be driven in N days" option.

**Present two candidate routes before committing (light mode only).** Once the shortlist is down to viable options, draft **exactly two** genuinely distinct routes yourself — e.g. a faster direct corridor vs. a scenic detour, or two different geographic loops — each with a short label, a one-line summary, and rough total miles/driving days. Show both to the user and ask them to pick (or say "surprise me") before moving to Step 3. This is a single short question, same spirit as the required-slot follow-up in Step 1 — don't draft a full itinerary for either option first. If the conversation is one-shot and no reply is possible, pick the better-rated opti