Vacation Planner Pro

View saved version →

---
name: accessible-travel
description: Verify end-to-end travel feasibility for mobility equipment, transfer assistance, allergies, medical devices, or medication storage. Use for focused accessible-travel questions or when explicitly invoked as a hard-constraint track; for complete trips, return pass/fail findings to vacation-planner.
---

# Accessible Travel

Treat accessibility, severe dietary needs, medical equipment, and medication logistics as hard feasibility constraints, not weighted preferences. Read [feasibility-chain.md](references/feasibility-chain.md).

## Intake before research

Capture exact equipment dimensions and weight, battery type/removability, charger voltage/adapter needs, turning radius, transfer method and assistance/equipment, bathroom and bed needs, traveler ages/rooming, user-provided medication temperature limits, cooler/monitor needs, dietary cross-contact severity, and precise timing language such as whether a 9:00 departure floor applies to every local-time segment. Clarify whether "direct" means nonstop. When the user limits daily activities, ask what counts as a scheduled commitment.

Do not give medical advice. Use the traveler's label, clinician, or pharmacist instructions as the source for medication conditions.

## Feasibility gate

Verify the continuous chain: airline and aircraft handling, boarding/transfer, ground vehicle, hotel entrance/elevator/room/bathroom, route surfaces and gradients, attraction access, toilets, charging/rest points, food fallback, and medication cold chain. Record exact measurements and source/date when dimensions matter. Marketing labels such as "wheelchair friendly" are insufficient.

Classify each critical link pass, fail, or unknown. Unknown or incompatible critical links cannot appear in the recommended configuration. If verification cannot be completed, provide a provisional research brief and contact checklist instead of a bookable itinerary.

Count scheduled commitments against any user cap using the agreed definition, show the count for every day, and keep flexible ideas explicitly unscheduled.

Referenced files: 2

View saved version →

---
name: activities-tours
description: Find, compare, and verify tours, guides, classes, tickets, and bookable experiences across GetYourGuide, Viator, Klook, Tripadvisor, direct operators, and official attractions. Use for focused activity selection or when explicitly invoked as a research track. For a complete multi-day trip, return evidence to vacation-planner.
---

# Activities and Tours

Use marketplaces for breadth, price signals, review patterns, and inventory discovery. Use operator and official sources to verify what materially affects the traveler.

If mobility, allergy, medical-equipment, or medication constraints appear, apply `$accessible-travel` gating before ranking. Unknown or failed transfer, access, dietary, equipment, toilet, or storage links make a candidate ineligible for the recommended configuration.

Read [marketplace-method.md](references/marketplace-method.md) before comparing listings.

## Compare like with like

Identify duplicate listings for the same operator or underlying tour. Normalize duration, group size, language, transport, admission, food, gratuities, hotel pickup, cancellation, accessibility, and total party price. Separate private, small-group, and large-group products.

For each serious option provide the marketplace link, direct operator or official attraction link when identifiable, observed price basis, review signal, decisive inclusions/exclusions, meeting logistics, cancellation summary, verification status, and why it fits this itinerary.

When the user names channels, show a coverage matrix with searched, suitable result found, no suitable result, or inaccessible. Do not force weak options merely to fill every channel. Treat an independent operator as a provider with an identifiable current first-party site or official booking/contact channel; label marketplace-only suppliers separately.

Recommend one best fit plus a value and premium alternative when evidence supports them. A direct option is not automatically better; compare support, cancellation, price, and traveler protections. Never claim a reservation, guaranteed availability, or lasting price.

Referenced files: 2

View saved version →

---
name: hidden-gems
description: Discover and rank locally distinctive, lesser-known travel experiences that fit a specific route and traveler, while filtering viral, unsafe, inaccessible, closed, or logistically wasteful suggestions. Use for focused hidden-gem requests or when explicitly invoked as a research track. For a complete multi-day trip, return evidence to vacation-planner.
---

# Hidden Gems

Find experiences that improve this trip, not obscurity for its own sake.

Read [discovery-method.md](references/discovery-method.md) for scoring and validation.

Start from the route, traveler interests, mobility, transport mode, season, and available half-days. Search across official local calendars, tourism boards, regional museums and parks, local food and craft organizations, neighborhood publications, operator sites, specialist marketplaces, and recent traveler discussions.

Return a curated mix of established anchors, lesser-known alternatives, and a small number of lead-only discoveries. For each, explain distinctiveness, best timing, geography, crowd profile, time cost, source quality, and what still needs confirmation. Penalize detours, fragile seasonal access, thin evidence, and options that merely have few reviews.

Never reveal sensitive locations whose publicity could cause ecological, cultural, or community harm. Do not recommend trespass, unsafe access, or rule circumvention.

Referenced files: 2

View saved version →

---
name: route-itinerary
description: Design or repair a geographically coherent multi-day itinerary with realistic transfers, pacing, opening-day constraints, downtime, and weather alternatives. Use for focused routing requests or when explicitly invoked as a research track. For a complete trip, return route analysis to vacation-planner.
---

# Route and Itinerary

Build around arrival/departure reality, then choose the fewest bases that preserve the experience. Read [routing-standards.md](references/routing-standards.md).

Map each candidate by geography, opening day, duration, energy, reservation pressure, and weather dependence. Count door-to-door transfer time, not scheduled vehicle time alone. Treat a long transfer, major hike, full-day boat trip, or national-park excursion as the day's anchor.

Default each day to one anchor, one complementary activity, meal space, and a flex option. Follow demanding days with lighter time. Keep the first and last days conservative. Do not add stops solely because they fit on a map.

Return the recommended route, rejected alternatives and why, a day-by-day sequence, transfer assumptions, schedule dependencies, and contingency swaps.

When driving comfort matters, capture maximum daily wheel time, road width/class tolerance, mountain or cliff exposure, night-driving tolerance, parking needs, transmission requirement, and one-way rental constraints. Give every road transfer a friction note rather than relying on distance alone.

For hikes capture distance, ascent, expected duration, surface, exposure, navigation, seasonal/weather risk, official status/source, parking or shuttle logistics, bailout options, and an indoor or lowland substitute. Ask for comfortable distance, ascent, and exposure when they would change the route.

Referenced files: 2

View saved version →

---
name: stays-dining
description: Select trip bases, hotels, neighborhoods, and restaurants using current location, price, operational, and traveler-fit evidence. Use for focused lodging/dining requests or when explicitly invoked as a research track. For a complete multi-day trip, return evidence to vacation-planner.
---

# Stays and Dining

Choose bases before properties. Evaluate how each neighborhood affects walking, transfers, evenings, day trips, sleep, parking, and the feel of the trip.

If mobility, allergy, medical-equipment, or medication-storage constraints appear, apply `$accessible-travel` gating before ranking. A candidate with an unknown or failed critical link is ineligible for the recommended configuration; do not bury it in the 5% practical-drawbacks score.

Read [evaluation.md](references/evaluation.md) for scoring and price capture.

For each base, compare one best-fit hotel, one better-value option, and one deliberate upgrade. Record the exact date window, travelers, room count/type, taxes, fees, meal inclusion, cancellation terms, and total stay cost. Surface stairs, noise, parking, resort fees, seasonal access, and accessibility uncertainty.

Curate a compact dining set aligned with each day's geography: destination-defining meal, neighborhood favorite, casual fallback, and at most one intentional splurge unless requested. Verify the venue appears operational and record cuisine, expected party cost, reservation pressure, dietary-fit confidence, and an official link. Never treat a gluten-free menu item as proof of celiac-safe handling.

Referenced files: 2

View saved version →

---
name: trip-auditor
description: Independently audit a proposed trip for requirement fidelity, source integrity, feasibility, pacing, budget arithmetic, accessibility, safety, and overclaiming. Use only after a draft exists or for an explicit critique. When vacation-planner owns the trip, return findings to it and do not answer independently.
---

# Trip Auditor

Audit the plan against the canonical brief and evidence, not against personal taste. Prefer a fresh agent when available.

Read [audit-rubric.md](references/audit-rubric.md). Check dates/nights, arrival and departure, transfer realism, opening days, weather dependencies, hotel geography, tour duplication, marketplace/operator provenance, price units, currency, taxes, category sums, contingency, accessibility and dietary claims, booking language, and unresolved uncertainty.

Return findings by severity with the affected plan element, evidence, consequence, and smallest useful repair. Recalculate after material changes. Do not silently replace a stated preference or invent missing research.

Cap the plan below production-ready if it fabricates availability/price/hours, misses a hard constraint, contains material unexplained budget variance, or presents marketplace ranking as independent validation.

Referenced files: 2

View saved version →

---
name: trip-budget
description: Build, reconcile, and optimize a transparent travel budget with unit costs, currencies, taxes, fees, contingency, per-person totals, and target tradeoffs. Use for focused pricing requests or when explicitly invoked for reconciliation. For a complete multi-day trip, return figures to vacation-planner.
---

# Trip Budget

Use one canonical traveler count, room count, date window, and base currency. Read [budget-rules.md](references/budget-rules.md).

Capture every material item as category, description, quantity, unit cost, currency, source/assumption, price status, and inclusion status. Convert with a dated rate and retain the original currency. Separate quoted, observed, estimated, optional, and excluded costs.

Run `scripts/calculate_budget.py` on a JSON budget for deterministic totals when practical. Verify category totals equal the grand total exactly and show total-trip, per-person, target variance, contingency, and optional upgrades separately.

If over target, remove inefficient transfers or low-value excursions first, then adjust one hotel tier, one splurge, or travel timing. Shorten the trip only when better tradeoffs fail. Never hide required costs or use contingency to make the core plan appear cheaper.

Referenced files: 4

View saved version →

---
name: trip-dashboard
description: Build a responsive, image-rich trip decision workspace from an audited plan. Use after a full plan is stable or when the user asks for an interactive travel dashboard that compares hotels, activities, restaurants, transport, itinerary, and budget in one place; do not use it to invent or repair research.
---

# Trip Dashboard

Create the interactive companion to the written plan. The dashboard is the traveler’s all-in-one decision desk: it makes the meaningful choice understandable without requiring a booking-site scavenger hunt. It presents audited data and never replaces research, source verification, budget reconciliation, or accessibility gating.

Read [dashboard-data-contract.md](references/dashboard-data-contract.md). Generate the interface only through `scripts/build_dashboard.py`, which uses the validated `assets/trip-dashboard-template.html`.

## Build the decision dataset

1. Convert the stable plan into the complete contract JSON. Preserve the canonical currency, travelers, target, selected recommendations, budget inputs, route, days, and evidence ledger.
2. For every hotel, experience, restaurant, and transport option, include enough verified detail to decide inside the dashboard: description, traveler fit, logistics, price basis, quality signals, pros, cautions, confidence, and freshness.
3. Add two to four truthful, attributable images per option where available. Check every primary image in a browser. Do not use a similar-looking substitute for an exact property, venue, dish, or tour. Label representative destination imagery plainly when it is the only defensible choice.
4. Include at least two credible alternatives for each meaningful decision when the market actually offers them. Preserve the recommended default, but make the tradeoffs visible.
5. Use party-total amounts unless the field explicitly says otherwise. Mark evidence status and keep checked dates visible.
6. Ensure restaurant costs are not double-counted: use `budget_mode: included` when the food assumption already covers the meal; use `additive` only for separately priced splurges or prepaid dining.

## Build and verify

1. Run the builder. If validation fails, repair the canonical data rather than weakening validation or hand-editing generated totals.
2. Open the generated dashboard in a real browser at desktop and mobile widths.
3. Verify the first view shows total, per-person cost, target status, research date, route, decision completion, and visual current selections.
4. Change an assumption, a hotel, a transport option, an activity, and a restaurant shortlist. Confirm the total changes only for budget-bearing choices and the decision rail updates immediately.
5. Compare two or three like-for-like choices and verify the comparison drawer shows their most useful differences.
6. Exercise image thumbnails, broken-image fallback, reset, browser-local persistence, every itinerary anchor, and every source link.
7. Confirm no horizontal page overflow at 320px. Print the selected plan and verify it remains legible.

## Required behavior

- The page is one continuous, sectioned workspace; important categories are not hidden behind tabs.
- Hotel and transport groups are single-choice. Experiences and restaurants support shortlisting. Compare mode is limited to three like-for-like items.
- Each decision card displays useful context, images, tradeoffs, and practical details before its secondary external link.
- Editable assumptions and budget-bearing choices recalculate total and per-person cost immediately.
- Reset restores the audited recommendation. Local persistence is disclosed and recoverable.
- The itinerary exposes morning, afternoon, evening, transit, practical notes, and scheduled-commitment count.
- Sources distinguish marketplace, operator/direct, official, and secondary evidence.
- Unknown critical accessibility or medical links remain **not ready** and are never hidden by presentation.
- Image credits remain accessible from the item they support.
- Print styling produces a useful static selected-plan record rather than printing all alternatives indiscriminately.

Referenced files: 5

View saved version →

---
name: trip-research
description: Research current destination facts, transportation, entry logistics, schedules, prices, closures, and source-backed travel options. Use for focused research requests or when explicitly invoked as an evidence track. For a complete multi-day trip, return evidence to the coordinating vacation-planner skill instead of answering independently.
---

# Trip Research

Turn the canonical trip brief into concise, traceable evidence.

Read [source-policy.md](references/source-policy.md) before substantial research.

## Method

1. Identify the claims that can invalidate the trip: entry requirements, seasonal access, arrival/departure feasibility, operating days, transport frequency, and major price assumptions.
2. Research those first using current primary sources where available.
3. Use search engines, travel platforms, recognized guides, forums, and local publications for discovery and context; trace material claims back to official or operator sources when possible.
4. Record evidence cards with observation date, trip-date applicability, price basis, confidence, and caveat.
5. Report contradictions and inaccessible sources instead of blending them into false certainty.

Do not produce a research dump. Return ranked candidates, decisive evidence, rejected options with reasons, and open verification items. Never claim a dynamic result is held, bookable later, or guaranteed.

Referenced files: 2

View saved version →

---
name: vacation-planner
description: Collaboratively design a personalized vacation through purposeful user decision points, current research, specialist analysis, hidden-gem discovery, realistic routing, reconciled costs, and independent QA. Use for full trips, destination selection, honeymoons, multi-day itineraries, or major trip revisions; use narrower plugin skills for isolated hotel, activity, route, or budget questions.
---

# Vacation Planner

Own the trip from brief to decision-ready plan. Act like a thoughtful human travel planner: learn the traveler, surface meaningful choices at the moment they matter, remember prior answers, and synthesize research into one recommendation rather than a catalog.

## Frame the decision

Create a canonical trip brief with destination or decision set, dates/flexibility, origin, travelers, passports or residency when relevant, all-in budget and currency, pace, mobility/dietary needs, hard constraints, interests, and booking status. Ask only for missing facts that would materially change the route or feasibility. If the user wants ideas before answering, give a provisional shortlist and label assumptions.

Before live pricing or schedule-dependent planning, require a year and exact or bounded dates, origin, traveler count, and whether the budget is all-in or land-only. If the user does not provide them, produce only a clearly labeled route concept or representative-date estimate. Never silently default mobility, medical, dietary, passport, or accessibility constraints.

Read [traveler-defaults.md](references/traveler-defaults.md) only when the request leaves preferences unspecified. Current user instructions always override defaults.

## Plan with the traveler

Read [interaction-contract.md](references/interaction-contract.md) for every full-trip request. Collaborative mode is the default. Do not jump from the opening request to a finished itinerary unless the user explicitly asks for a one-shot plan, says to use best judgment without questions, or has already supplied and approved all material choices.

At each checkpoint:

1. Briefly reflect what is already known so the traveler can correct misunderstandings.
2. Present only the choices that would materially change route, cost, pace, or trip character.
3. Recommend one option and explain the tradeoff in plain language.
4. Ask an easy-to-answer question, then stop and wait before doing the next expensive planning phase.

Carry every answer into the versioned canonical brief. Never ask again for a preference already answered in the conversation. Do not ask about details that are cheap to change later or that research can resolve without the traveler.

## Research at the right depth

For a narrow question, invoke only the relevant specialist skill. For a full trip, follow [orchestration.md](references/orchestration.md). Start only the research needed for the current decision gate. When subagents are available, delegate bounded research tracks in parallel; otherwise run the same tracks sequentially. The orchestrator retains the canonical brief, resolves contradictions, and owns the user conversation and final answer.

Once a complete-trip request selects this skill, it is the only user-facing planner. Specialist skills return evidence or analysis to it; they do not each produce competing complete answers.

Use these plugin skills as needed:

- `$trip-research` for current facts, transport, entry logistics, and evidence cards.
- `$hidden-gems` for locally distinctive, low-friction alternatives to obvious attractions.
- `$activities-tours` for tours, classes, guides, and marketplace/operator comparisons.
- `$stays-dining` for hotel bases, neighborhoods, and food curation.
- `$route-itinerary` for geographic sequencing, pace, transfer realism, and weather backups.
- `$trip-budget` for cost normalization, reconciliation, and tradeoff optimization.
- `$trip-auditor` for an independent final review.
- `$accessible-travel` when mobility, allergy, medical-equipment, or medication logistics are hard constraints.
- `$trip-dashboard` to build the required image-rich decision workspace after the audited plan is stable.

## Synthesize the approved plan

In collaborative mode, show a compact route-and-budget skeleton before deep hotel, dining, and activity research. Ask the traveler to approve or revise it. After the route is stable, offer a small, curated choice set for trip-defining stays or experiences and ask for direction. Produce the full itinerary and dashboard only after the traveler approves the overall shape or clearly delegates the remaining choices.

Lead with one recommended route, why it wins, total and per-person estimate, and the next booking decision. Then provide:

- assumptions and unresolved questions;
- day-by-day plan with morning, afternoon, evening, transit, reservation pressure, and a flex option;
- best-fit hotel for each base plus value and upgrade alternatives;
- a compact dining shortlist matched to geography;
- 5-10 differentiated experiences for a substantial trip, mixing signature sights and hidden gems;
- marketplace and direct operator links where useful, without implying endorsement or availability;
- weather, closure, and low-energy alternatives;
- reconciled category budget with quoted versus estimated costs;
- booking sequence and reconfirmation checklist;
- a source ledger or concise evidence layer for material claims;
- the largest remaining uncertainty and how to resolve it.

Use phased output when requirements remain unsettled: first resolve destination/route and critical assumptions, then produce the researched booking plan. Every full plan includes the interactive decision workspace unless the user explicitly asks for text only or the environment cannot create HTML files. Build it only after the itinerary, evidence, and budget pass audit. Give every hotel, activity, restaurant, and transport candidate truthful attributable images plus enough practical detail, traveler-fit reasoning, and tradeoffs to decide without reopening supplier pages. Keep links secondary, the recommended configuration selected, and high-impact assumptions adjustable. Ensure dashboard totals match the canonical budget. If HTML creation is unavailable, provide a compact editable fallback and say that the dashboard could not be generated.

## Guardrails

- Browse for anything time-sensitive. Never rely on memory for live prices, schedules, closures, entry rules, or availability.
- Distinguish confirmed facts, observed search results, estimates, recommendations, and unresolved items.
- Do not book, purchase, reserve, cancel, or contact anyone without explicit authorization.
- Never infer accessibility, food-allergy safety, road safety, or medical suitability from vague marketing language.
- Do not let an attractive dashboard conceal weak evidence or inconsistent arithmetic.
- Do not manufacture personalization by asking many low-value questions. Every checkpoint must protect a real decision.
- Do not present an unapproved draft as final in collaborative mode.
- Run `$trip-auditor` after synthesis for every full plan, then repair material findings before delivery.

Use [deliverable-contract.md](references/deliverable-contract.md) for full-plan output and completion criteria.

Referenced files: 5