End-to-end road trip and travel itinerary planner that produces navigation-ready guides. Use this skill whenever the user asks to plan a road trip, self-drive tour, multi-day driving itinerary, or travel route — even if they just mention a destination and dates. Also trigger when the user asks for driving directions between multiple stops, wants to optimize a travel route, or needs a day-by-day travel guide with navigation links. Covers route planning, driving time verification, holiday/closure checks, parking details, weather forecasting, cultural-layer research, pre-trip homework recommendations. Generates markdown documents, interactive HTML guides with embedded Leaflet maps, and shareable PNG portable cards for offline IM sharing.
End-to-end road trip and travel itinerary planner that produces navigation-ready guides. Use this skill whenever the user asks to plan a road trip, self-drive tour, multi-day driving itinerary, or travel route — even if they just mention a destination and dates. Also trigger when the user asks for driving directions between multiple stops, wants to optimize a travel route, or needs a day-by-day travel guide with navigation links. Covers route planning, driving time verification, holiday/closure checks, parking details, weather forecasting, cultural-layer research, pre-trip homework recommendations. Generates markdown documents, interactive HTML guides with embedded Leaflet maps, and shareable PNG portable cards for offline IM sharing.
Road Trip Planner
Plan multi-day driving itineraries from a vague idea ("I want to drive the California coast") to navigation-ready guides with real-time-verified driving times, point-to-point Google Maps links, interactive maps, and per-stop parking/timing details.
When This Skill Applies
User wants to plan a road trip or multi-day driving tour
User asks for a driving itinerary between cities/attractions
User wants route optimization (eliminate backtracking)
User needs a travel guide with navigation links
User mentions self-drive, rental car, or road trip anywhere in their request
Tool Compatibility
This skill works across different Claude environments. Adapt tool usage based on what's available:
Capability
Claude.ai
Claude Code
Coordinate lookup
places_search
web_search (search "[place] GPS coordinates")
Map verification
places_map_display
Generate Leaflet HTML preview, or use web_search to verify route on Google Maps
Driving time
web_search
web_search / MCP browser tools
File output
{output_dir}
Project directory (ask user or use ./trip-output/)
Degradation rule: If a tool is unavailable, fall back to web_search for data and Leaflet HTML for visualization. Never skip a verification step just because the preferred tool is missing.
Layered output rule: Core deliverables (daily markdown + HTML) must always succeed. Enhancement layers (weather forecast, pre-trip content discovery, PNG cards) are fail-soft — if a search fails or a rendering tool is unavailable, log the miss and continue. Never let an optional enhancement block the core deliverable.
Writing Principles
These rules apply to every piece of content generated by this skill. They elevate output from "tourist brochure" to "trusted friend who's been there."
1. Why see + What to observe (per stop)
Every stop card must answer two questions, not just "visit X for 1 hour":
Why this place matters (1 sentence — historical, geographical, or experiential reason)
What specifically to look at (2-3 concrete observation points — NOT "take photos", but "look at the left hand of the statue — it holds a scroll with [inscription]")
Bad example: "Hearst Castle — 参观 2 小时"
Good example: "Hearst Castle — 1920s 美国报业大亨 William Hearst 的私人庄园，把欧洲古董运过半个地球拼装而成。看什么：(1) Neptune Pool 的罗马柱是真的 1 世纪庞贝出土的；(2) 室内 Gothic Suite 的天花板是从西班牙修道院整体拆运；(3) 户外室外泳池底部铺金箔，下午 3 点阳光下最明显。"
2. Don't fabricate — web-search or leave blank
Every concrete number (address, ticket price, phone, mileage, opening hours) must come from a web_search result, not LLM memory. If a number can't be verified:
Leave the field blank with a [需现场确认 / verify on arrival] marker
NEVER fill with a plausible-looking estimate
Fabricated ticket prices and wrong addresses are the fastest way to destroy trust.
3. Bilingual search habit
For international destinations, search the same query in both Chinese and English — coverage differs:
Chinese search: 小红书/马蜂窝/知乎 — strong on 实用贴士, 本地美食, 打卡时间
English search: Reddit/TripAdvisor/official sites — strong on operating hours, historical accuracy, safety info
Always cross-reference both when facts disagree.
4. Cut noise, keep signal
When filtering travel content (for pre-trip homework or restaurant picks):
Keep: content with knowledge-add (背景故事, 建造工艺, 考古过程, 建筑细节, 实际开销)
Cut: pure check-in photos, no-analysis recommendations, sponsored-looking content
Prefer long-form (B站 >10min explainers, 公众号 with cited sources) over short-form打卡
Gather Requirements
Before planning, collect these inputs. Ask the user if not provided:
Input
Required
Example
Destination / region
Yes
"California coast", "Iceland ring road"
Departure city
Yes
"Toronto", "San Francisco"
Travel dates
Yes
"April 3-6, 2026"
Number of days
Yes
4 days
Transport
Yes
Rental car / own car
Route type
Yes
One-way (A→B) / Loop (A→…→A) / Out-and-back
Interests
Helpful
Nature, tech, food, photography
Budget level
Helpful
Budget / mid-range / comfort
Existing bookings
Helpful
Flight times, hotel confirmations
Group size
Helpful
Solo / couple / family
Output language
Helpful
中文 / English / bilingual (default: 中文)
Route type matters for optimization:
One-way: Optimize for a single geographic direction, no doubling back
Loop: Ensure the final leg returning to origin is accounted for in time/fuel budget
Out-and-back: Plan the return route separately — avoid repeating the same stops, suggest alternative roads for the return
Workflow
Execute these steps in order, for each day. Do not skip steps — every shortcut taken here (especially steps 2-5) leads to a broken itinerary the user will discover mid-trip.
Parallel execution note: Steps 3, 4, and 5 (driving time / holiday check / weather forecast) are all independent web_search calls per stop. Fire them in parallel — a single batched round of N×3 searches instead of 3 sequential rounds. This compresses research time from ~3 minutes to ~1 minute and is strictly better than serial execution.
Step 1: Route Framework
Design the day's route based on user interests and geography.
Assign a theme to each day (e.g., "Silicon Valley tech tour", "coastal highway scenic drive")
List all candidate stops with addresses
Use places_search to get exact coordinates for every stop — never rely on memory for coordinates
Never add origin parameter — user may not be at the expected location, causing Google Maps to route from the wrong place
Never add waypoints parameter — waypoints can route users onto closed/restricted roads (e.g., Cañada Rd incident — 30+ min wasted)
Prefer place names over coordinates — coordinates are error-prone (NVIDIA photo spot, Stanford entrance). Only use coordinates when place name is genuinely ambiguous, and web_search the coordinates first
Two-segment navigation for every stop: always provide BOTH a driving link to the parking lot AND a walking link to the attraction entrance. Users need to know where to park separately from where to go
Two layers of nav links: summary table at top AND inline in each section
Include skip links: "If skipping stop X, click here to go directly from A to C"
Include conditional rules: "If you arrive at [Station X] after [TIME], skip [Station Y] to protect [hard deadline Z]"
Step 7: Generate Interactive HTML Guide
Create one .html file per day in {output_dir}. Read references/html-template.md for the complete template code before writing.
Key requirements:
Leaflet.js map with numbered color-coded pins and dashed route line
CARTO Voyager tiles (not Google Maps iframe — it fails in restricted environments)
Blue navigation buttons on every stop card that open Google Maps with coordinate URLs
Highlight the day's main event with gold border (.hl class)
Optional stops get dashed-outline numbers (.sn-o class)
Alert boxes: yellow for cost warnings, red for safety warnings
Mobile-optimized, max-width 480px
Light theme (white cards on off-white background) for readability
Step 8: Generate PNG Portable Cards
Create a PNG summary card per day (Day1-[Region]-速查卡.png etc.) for offline / IM-sharing use. Unlike the HTML guide, PNG cards:
Don't need network to open
Can be shared in WeChat / Telegram / iMessage groups in one tap
Render the same on every device (no layout drift)
Fit on one phone screen when zoomed to fit
What goes on the card (single vertical image, ~750×1600px portrait):
┌─────────────────────────────────┐
│ Day N · [Theme] 📅 Date │ ← Header strip (brand color)
├─────────────────────────────────┤
│ 🌤️ [Weather] · ☀️ Sunset HH:MM │ ← Weather + sunset bar
├─────────────────────────────────┤
│ ① [Stop 1] 🕐 8:00 │
│ [1-line why] │
│ 🚗 XX min to next │
│ │
│ ② [Stop 2] 🕐 10:30 │
│ [1-line why] │
│ 🚗 XX min to next │
│ ... │
│ │
│ ⭐ [Main highlight] 🕐 16:00 │ ← Gold-bordered highlight
│ │
├─────────────────────────────────┤
│ 💰 预计开销 $XXX · 🅿️ 停车 $XX │ ← Cost strip
│ ⚠️ [1-line critical warning] │ ← if any
└─────────────────────────────────┘
Generation approach (in order of preference):
Headless browser screenshot (preferred — leverages existing HTML template):
Create a purpose-built DayN-card.html with fixed 750px width and no scroll
Use Playwright / Puppeteer to screenshot: page.setViewportSize({width: 750, height: 1600}); await page.screenshot({path: 'DayN-card.png', fullPage: true})
In Claude Code: uvx playwright screenshot --viewport-size 750,1600 DayN-card.html DayN-card.png
