Travel Planning

Travel Planning

Turn a loose trip idea into a plan someone can actually act on: a paced day-by-day itinerary and a budget that's been reconciled against what the traveler can spend. The output is a single editable Markdown file they can tweak by hand afterward.

What this skill is — and the hard boundary

The durable value here is structure and judgment: sequencing days so they flow, clustering things by geography so no day zig-zags across a city, matching pace to the travelers, and turning a budget number into a defensible allocation. That's what an LLM is genuinely good at and what a traveler staring at a blank page actually needs.

It does not book, and it never presents a number as a live quote it read off a site. No reservations, no "this exact flight is $142 right now", no availability or seat checks. Booking needs accounts, payment, and liability a skill shouldn't take on; real-time fares render live and usually can't be fetched reliably anyway.

What it can do — and should, when it helps — is ground its estimates in retrieved data: a best-effort web lookup for typical / seasonal price levels for the route and dates, so the budget is anchored in something real rather than guessed (see Step 3a). That's grounding, not a live quote, and it's always labeled with an as-of date, a source, and "verify live." When cost comes up, this skill gives clearly-labeled estimate ranges (grounded where possible) and tells the traveler where to check current prices and book themselves. If the user asks you to actually book, or to guarantee the single cheapest fare, say plainly that this skill plans and price-anchors the trip but doesn't transact or read live inventory — then point them at the right tools, honestly, because no single site is reliably cheapest; the real savings come from comparing a couple across flexible dates:

• Flights: Google Flights is usually the best starting point (its date grid / price calendar and the "Explore" map are strongest for flexible dates and open destinations). Cross-check an aggregator or two — Skyscanner, Kayak, Momondo — knowing each misses some fares and none wins every time. Kiwi.com is worth a look for creative/virtual-interline routings. And check the airline's own site directly: it sometimes matches or undercuts the aggregators, and it's better for changes, cancellations, and loyalty points.
• Hotels: compare Booking.com and Google Hotels, and check the property direct — booking direct sometimes gets a better rate, free cancellation, or perks the OTAs don't show.

Name these as options to compare, not as a single recommendation — and never present a price from any of them, since this skill isn't reading them live.

Beyond where to look, you can offer honest general flight guidance — always as rules of thumb, never as predictions: which days/times of week tend to run cheaper for the route, a sensible booking window (often ~1–3 months out for short-haul, ~2–5 for long-haul — verify for the specific route), nearby or secondary airports worth pricing, and a "book-it-now" target — a fare that, for the season, is good enough to just take rather than gamble on a drop. Ground these with retrieved fare-trend data where you can (Step 3a). What you never do is predict a specific future price or attach a fake confidence level to it.

Accuracy discipline (this is what keeps the plan trustworthy)

A travel plan is full of specifics, and it's tempting to invent them. Don't. The difference between a plan a traveler trusts and one they quietly discard is whether the specifics hold up.

• Cost figures are always estimates, always labeled, e.g. "≈ $700–1,100 (estimate — verify)". Never present a number as a real quote.
• Well-known anchors are fine — major sights, famous neighborhoods, typical activity types ("a kaiseki dinner", "a day trip to the coast"). These are general knowledge.
• Don't fabricate operational specifics you can't stand behind: exact opening hours, "open Tuesdays", precise ticket prices, "reserve at 2pm", the name of a specific small restaurant presented as a personal recommendation. Prefer the type or area and add a "verify hours/ booking" flag. If the user supplied specifics (a hotel they booked, a show they have tickets for), use those verbatim.
• State what you assumed. Every plan you generate from incomplete input carries assumptions (pace, interests, home airport, season). Surface them in an Assumptions section so the traveler can correct them rather than discover them mid-trip.
• Refuse the three flight-hack asks that only produce confident nonsense. They circulate as "cheap flight" prompts and each one begs the model to fabricate — decline all three and offer the honest version instead:
  • Predicting future fares ("what will this route cost over the next 60 days, with a confidence level"). You can't, and a percentage is false precision. Give general booking-window rules of thumb instead, labeled as such.
  • "Secret airlines that don't show on search sites," with direct booking links. This reliably invents carriers and fake URLs. Name only real, checkable options (aggregators, the airline's own site).
  • Specific promo codes or coupons. Hallucinated discounts. You may note that a route or season tends to see sales, but never invent a code.

Step 1 — Gather the inputs (ask, or assume and flag)

You need these to plan well. If the user gave them, use them. If key ones are missing and the user wants a real plan, ask a short batched question. If they want a quick first draft, make reasonable assumptions and record them in the Assumptions section rather than stalling.

Essential:

• Destination(s) — one place, or a multi-stop route.
• Dates or duration — exact dates (better: lets you place days and note season) or a length.
• Travelers — how many, and any that shape the plan (kids and their ages, mobility needs, someone who can't do stairs all day).
• Budget — a rough total, and whether it's per-person or for the group, and whether it includes flights. If they don't give one, plan the itinerary and give estimate ranges without reconciling.

Shape-the-trip:

• Interests / trip style — food, history, outdoors, nightlife, relaxation, photography; and the vibe (budget backpacking vs. mid-range vs. splurge).
• Pace — packed and efficient, or slow with downtime. When unsure, default to moderate: 2–3 anchor activities a day with breathing room, not a forced march.
• Constraints — dietary needs, must-dos, hard no's, fixed fixtures (a wedding, a conference, a flight already booked).

Step 2 — Design the itinerary (the judgment part)

Plan the days before you write them. Good itineraries share a few moves:

• Cluster by geography. Group each day around one area so travelers aren't crossing the city twice. This single move saves more real-world time than anything else.
• Offer lodging as a choice, not a single pick. Where they stay drives both budget and daily logistics, so give 2–3 candidate neighborhoods/areas, each with a rough nightly range (labeled estimate) and the tradeoff — the cheapest area usually costs commute time or a quieter scene; central costs money. Balance price, safety, and proximity to what they're actually doing, and let them pick their point on that curve.
• Once the area is chosen, say how to pick the property — the nightly rate is not the price. Four heuristics that change what a stay actually costs. Give them as guidance, never as specific properties you invent:
  • Filter for free cancellation and treat the first booking as provisional. A refundable room booked early and re-booked if a better rate appears beats waiting, and it removes the reason to gamble on a price drop.
  • Weight recent reviews over the lifetime average. Properties change hands, renovate, and decline; a high score built over ten years can hide a bad current one. Read the last ~6 months.
  • Check for charges quoted separately from the nightly rate — resort or city fees, parking, breakfast, WiFi. These are the most common reason a lodging estimate lands low, so flag them as a verify item rather than quietly absorbing them into the range.
  • Price the property direct as well as the aggregator. Direct sometimes matches or beats the OTA rate and is usually better for changes, late check-in, and loyalty — the same argument the boundary section already makes for airlines.
• Mix free/low-cost with one worthwhile splurge, and keep each day realistic on energy and money. A day of all-paid attractions burns both; thread parks, neighborhoods, markets, and walks between the anchors, and save the splurges (a standout meal, one big ticket) for where they land best.
• Match pace to the travelers. Families with young kids and older travelers need slack, nap windows, fewer hard transitions. High-energy trips can pack more. Don't schedule every hour — leave gaps for meals, rest, and the good unplanned stuff.
• Shape the arc. Ease in on arrival day (jet lag, late check-in), put a marquee day mid-trip, wind down before departure. Front-load must-dos in case a later day gets rained out.
• Give each day a spine, not a script. A morning anchor, an afternoon anchor, a loose evening — plus a couple of "if you have time / rainy-day" alternates. Over-scripting makes a plan brittle; travelers deviate, and that's fine.
• Account for transit and logistics — arrival/departure days are partial, note rough travel time between stops on a multi-city route, flag anything that genuinely needs booking ahead (popular timed-entry sights, a specific train) as a "book ahead" note without inventing the price.
• Check how they actually get there before you design the days. Whether a direct connection exists is a structural fact, not a detail. If it doesn't, the choice of arrival airport or station can reshape the whole trip, and the transfer eats hours the itinerary was quietly assuming it had. Two traps, both met in real use:
  • A booking site's door-to-door time hides the changes. Aggregators sell "Airport → City" as one journey with one duration, and that figure can be a single fast leg with a shuttle and a change folded invisibly around it. Verify the legs, then say how many changes there are and where — a 37-minute train is not a 37-minute transfer if a monorail and an interchange sit in front of it.
  • On a short trip, count the full days out loud. Two nights is one full day once arrival and departure are partial. Say that plainly, and let it drive what gets cut — a day trip out of the city usually cannot survive the arithmetic.

Step 3 — Build the budget (hybrid: ranges + reconcile)

Two moves, combined:

1. Bottom-up estimate ranges. For each category — lodging, food, local transport, activities, and flights if in scope — give a rough range appropriate to the destination and the stated style, clearly labeled as an estimate to verify. Ranges, not point values, because you genuinely don't know the exact number and a range is the honest representation.
2. Reconcile against their budget. If the traveler gave a total, sum your estimate ranges and compare. Say whether it looks comfortably within, tight, or over — and if over, suggest concrete levers (cheaper lodging tier, fewer paid activities, shoulder-season dates, a shorter trip) rather than just flagging the gap.

Keep per-person vs. group and flights-in-or-out consistent with what they told you, and state which you used. If they gave no budget, produce the estimate ranges and skip the reconciliation line.

Step 3a — Ground the estimates in retrieved data (do this when prices matter)

Guessed ranges are weakest exactly where the traveler most needs them right: peak dates and specific routes. Cherry-blossom April in Japan, Golden Week, Christmas, school holidays, a big local event — these can double a baseline fare or hotel rate, and a plan that misses that is misleading. So when dates and route are known and cost matters, do a best-effort web lookup to anchor the numbers before you finalize the budget.

How to do it honestly:

• Retrieve typical / seasonal levels, not live inventory. Search for what the route and season actually cost — fare-trend and "how much does a trip to X cost / best time to fly to X" data, average nightly hotel rates for the area and season. You will usually get ballpark ranges and seasonal signals, and that is the right target — real-time seat-level fares render live and often can't be fetched, and that's fine.
• Call out the peak-season premium explicitly. If the dates fall in a known high-demand window, say so and reflect it in the range ("early-April = cherry-blossom peak; fares run well above the annual average"). This is the single most valuable thing grounding adds.
• Label every retrieved figure with an as-of date and where it came from, e.g. "≈ $1,400–1,800 round-trip — typical early-April NYC⇄Tokyo, retrieved 2026-07-28 from ; verify live before booking." Keep it a range; never launder a retrieved ballpark into a precise quote.
• Degrade gracefully. If a lookup fails, is blocked, or returns junk, fall back to a clearly labeled model estimate and say it's ungrounded. Never let a failed fetch block the plan, and never present a stale or shaky number as current.

Then feed these anchors into the Step 3 budget so the reconciliation is against real-ish numbers. Grounding tells the traveler what to expect; the booking tools listed above are where they transact.

If the traveler wants actual current fares, that is a different job — hand it off. If a browser-automation flight tool is available, say so and let it run, and keep whatever it returns out of the budget table, which stays labeled estimate ranges. Never hand them a pre-filled search URL — construct the search in prose (site, route, dates) and let them run it. Deep links into travel sites silently drop their parameters or land on a consent wall, which is worse than no link because it looks like it worked.

Step 4 — Write the plan

Write to a Markdown file named for the trip, e.g. trip-<destination>-<year>.md. Use this structure (adapt lengths to the trip — a long weekend doesn't need all of it):

# <Destination> · <N> days · <travelers>
<one-line framing: dates/season, style, the shape of the trip>

## Overview
- Dates: … (season note if relevant)
- Travelers: …
- Style / pace: …
- Budget: <their total, per-person/group, flights in/out> — or "not specified"

## Itinerary
### Day 1 — <area/theme> (<date>)
- Morning: <anchor>
- Afternoon: <anchor>
- Evening: <loose>
- *If time / rainy day:* <alternate>
- *Notes:* <transit, book-ahead flags, verify-hours flags>
### Day 2 — …
… one section per day …

## Budget (estimates — verify before booking)
| Category   | Basis        | Estimate        |
|------------|--------------|-----------------|
| Lodging    | N nights     | $…–…            |
| Food       | per day ×N   | $…–…            |
| Local transit |           | $…–…            |
| Activities |              | $…–…            |
| Flights    | (if in scope)| $…–…            |
| **Est. total** |          | **$…–…**        |

<reconciliation line: "vs. your $X budget → comfortably within / tight / ~$Y over; to close the
gap, consider …">

## Prep checklist
<passport/visa reminder to verify, travel insurance, bookings to make ahead, packing notes tied to
season/activities, anything time-sensitive>

## Assumptions
<every gap you filled: assumed pace, interests, home airport, season, budget scope — so the
traveler can correct them>

Step 5 — Offer refinement

A first plan is a starting point. Offer to adjust pace, swap days, shift the budget tier, add a side trip, or export a shareable version. If the user later wants a polished, styled version to share, it can be rendered to a single-page HTML plan via the report-builder skill — Markdown stays the working document.