Trip Planner Skill

Produces a detailed, realistic, day-by-day travel plan as a single polished HTML file — geographically sensible routing, honest time budgets, verified opening hours and prices, an embedded interactive map, and a pre-trip checklist. The visual design reuses the study-notes HTML output spec (collapsible blocks, hierarchical nav, colored callouts, dark-mode theme, scroll-position memory), retargeted to travel and documented in references/design-system.md.

Audience assumption: the reader is the traveler. Write so they can follow the plan on their phone during the trip — concrete times, addresses, prices, "how to get there", and what to do if it rains.

Environment (Windows / Claude Code). There is no places_search, places_map_display_v0, or weather_fetch tool here. Do research with web_search; render the map by embedding Leaflet + OpenStreetMap in the output HTML (OSM tiles need no API key). For requirements gathering use the AskUserQuestion structured-question tool if available, otherwise ask in plain text — batched by dependency layer, each question carrying a recommended answer (see Step 1).

Browser scraping — read the DOM with javascript_tool, don't screenshot-and-eyeball. 查机票/酒店价、 携程/高德评论时，优先用 javascript_tool 抓 DOM 取结构化 JSON（省 token，且绕开高德 canvas 截图报错—— 评价在 HTML 面板里，JS 抓得到）。探测脚本 + 各站点已复验选择器模板见 references/scraping-method.md； 只在确认加载/需要视觉/canvas 内容时才截图。保存的选择器只是"自检缓存"、会过期——取到 0 条就按该文档 §八 自愈降级（探测脚本 → 锚定内容模式 ¥/HH:MM/日期 → 语义兜底），别干等、别放弃；自愈失败仍取不到，就如实 标「未读到 · 以官网为准」，绝不编。

Output path. Write the final HTML to the current working directory (or a directory the user names). Filename: \x3C目的地>\x3CN>日游行程.html (e.g. 东京5日游行程.html).

数据诚信契约（DATA INTEGRITY — 凌驾本文件一切其它规则）

这个 skill 唯一不能破的底线：页面上每一个具体数字/事实，要么本会话真的查到了，要么就别写成具体值。 宁可不写，绝不编。 一次编造的营业时间能把游客送到闭馆的门口，一张编造的"4.8 分 3,201 条点评（已核）" 能让整份行程的可信度归零。这条契约的违反，比任何排版/组件缺失都严重。

浏览器优先，不是浏览器可选。 机票、酒店（价格+评论）都是强制要主动尝试浏览器的项—— 先去连/去查，连不上或用户跳过才退到估价。不许因为"这趟没机票"或图省事，跳过尝试直接走 web_search 估价。

两类来源，泾渭分明：

• 实查（可写具体值）：本会话真的用浏览器（携程/飞猪/航司官网/高德）或 web_search 读到了， 且就近标了来源——浏览器读的标「实查于 YYYY-MM-DD」/「浏览器实读点评区」/「高德实测」， web_search 读的标「web_search · 未浏览器核实」，火车标「以 12306 为准」。 注意：web_search 只能给价格区间和事实概要，给不了真实评论区——评论结论与评分只有浏览器读得到， web_search 写评论=编造。
• 没查到（禁止写具体值）：没读到就不许填一个看起来合理的数。用不含杜撰细节的 hedge 占位， 例如「营业时间以官网为准」「评分以 App 为准」「打车费用以高德为准」「车次时刻以 12306 实时为准」。

受控『已验证』词表——只有真查到才能用： 已核 / 已核实 / 可信 / 实测 / 实测数据 / 浏览器实读 / 浏览器实查 / 高德实测 / 分布正常 / 不像刷分 / 好评集中在X / 口碑稳 / 活跃真实。这些词只有当本会话确实读到对应内容、且同一处带了来源+日期标记时 才允许出现。同一张卡/同一段里，价格标了「未核实/估价」，就绝不能在别处出现这些词——那是自相矛盾， 是最恶劣的"伪装成已核实"。也不要用同义词（口碑扎实/水分不大/可放心订/评分稳）绕开——任何关于评论区 的结论性判断，没有就近来源标记，一律不写。

按面分项的硬规矩（每一面都管，不只是酒店）：

逃生门（"你直接安排就行"）只放宽提问，不放宽这条契约：缺的偏好按推荐值填、写进顶部假设 callout； 但任何事实仍然遵守上表——没查到就 hedge，绝不因为是非交互模式就开始编数字。

scripts/check_html.py 的第 8–10 检查是这条契约的兜底（抓最常见的编造：无凭据的酒店评分/评论结论、 假"最低"比价、复制粘贴的假天气）。但校验器只是结构兜底、挡不住刻意绕过——真正的防线是你自己守住"宁可 不写绝不编"。

Run it as a workflow (plan → research → verify → assemble)

Don't free-write a plan in one pass. The quality comes from the structure:

1. Plan — gather requirements (Step 1), then sketch the day count, geographic clusters, and which stops need booking. Nothing is researched yet; this is the skeleton.
2. Research (fan-out) — for each day/cluster, look up transport, weather, opening hours, closure days, and prices with web_search (Steps 2–3). For a big trip you may run parallel subagents, one per day or per city.
3. Verify (the decisive step) — enforce the 数据诚信契约 above: every specific number/fact is either actually verified this session (with a source marker) or written as a hedge that carries no invented specifics — never a plausible-looking number. This applies to every surface, not just hotels: 票价/营业时间/地址/车次/时刻/船票/打车费/里程/步数/预约配额/坐标/天气. Re-check that no stop is scheduled on its closing day and that intercity connections leave realistic buffers.
4. Assemble — build the HTML per references/design-system.md, then run the checker (scripts/check_html.py).

The six steps below are mandatory and in order. Do not skip Step 1.

Step 1 — 需求采集（GRILL，问透为止 — never skip, never jump straight to an itinerary）

This is the most common failure mode: producing a generic itinerary before knowing who's traveling and what they want. Don't. 需求采集采用 grill 式访谈（方法源自 grill-me）： 沿着决策树把每一个分支问到底，直到没有任何一项需求是靠猜的。四条铁律：

1. 问透为止，不设问题数上限。 下面清单里的每一项，要么用户答了，要么用户明确同意用推荐值—— 没有第三种状态。一轮 3–4 问、按依赖顺序分多轮（用 AskUserQuestion，没有就纯文本编号提问）， 问完一层再问下一层，直到清单清零。
2. 每问必附推荐答案。 每个问题给出你基于已知信息的推荐选项和一句理由（放在选项第一位）， 用户嫌烦可以整轮"都按推荐"。
3. 能查的绝不问。 凡是 web_search/浏览器能查到的（天气、闭馆日、签证政策、有没有直达高铁）， 自己查；只问存在于用户脑子里的事（偏好、约束、已订了什么）。
4. 先读 prompt，绝不重问已知。 开场先把用户已给的信息抽出来打勾，只 grill 缺口。

需求决策树（按依赖顺序分层 grill）

第 1 层 · 骨架（决定一切的硬事实）

• 目的地 + 出发地（精确到城市/机场）
• 日期 / 天数（精确日期；驱动天气、节庆、闭馆、票价）
• 大交通是否已订？ 已订 → 拿到具体班次/车次时刻，行程以它为锚，Step 2 只做接驳； 未订 → Step 2 全流程实查比价
• 城际出行方式偏好 — 飞机 / 高铁 / 自驾 / 不限（价格 vs 时间怎么权衡；红眼/早班能不能接受）
• 时间硬约束 — 出发日最早几点能出门？返程当天必须几点前到家？行程中间有无固定事项（会议/探亲/复诊）
• 证件 — 身份证/护照在不在有效期？出境/港澳台需要的签证签注办了吗（政策本身自己查，证件状态问用户）

第 2 层 · 人和钱（决定行程形态）

• 同行构成 — 人数；亲子（孩子年龄）/ 银发（体力、无障碍）/ 情侣 / 朋友 / 独行 / 商务+休闲
• 健康与体力 — 每天能走多少步？爬山/楼梯行不行？需不需要午休？晕车船/高反史？常用药？
• 预算口径 — 总预算还是人均/天？机酒大头含不含在内？有没有不能破的硬上限？
• 节奏 — 暴走 / 适中 / 悠闲（每天少而精）
• 兴趣偏好 — 自然 / 历史人文 / 美食 / 购物 / 艺术展馆 / 夜生活 / 亲子乐园 / 摄影出片
• 必去 / 避雷清单 — 点名要去的，和明确不想要的类型

第 3 层 · 落地细节（决定每张卡片怎么填）

• 住宿 — 已订（给地址）还是待选？几间房、什么床型？品牌偏好/忌讳？要不要含早？位置偏好 （市中心 / 枢纽旁 / 景区附近）
• 市内交通方式 — 地铁公交 / 打车 / 自驾租车 / 步行为主
• 行李 — 有无托运需求（廉航是否适配）？婴儿车 / 轮椅？
• 餐饮 — 忌口、过敏、清真/素食？辣度接受度？有没有必吃清单？
• 天气与弹性 — 雨天还出门吗？高温耐受？行程有变数吗（要不要退改弹性/保险提醒）？

第 4 层 · 收口

• 最后一问固定是：「还有什么硬要求是我没问到的？」 答"没有"才算 grill 结束。
• 结束后回读一遍完整需求清单（含所有推荐值的采纳情况）让用户确认，再进 Step 2。

Escape hatch：用户说"你直接安排就行 / just decide for me"时不再追问，全部缺口按推荐值填——但 整张假设清单必须原样写进 HTML 顶部的 info callout（已有机制），并在回复里提醒"按这些假设排的， 不符再说"。

Step 2 — 机票 / 火车票查询（只查询，不下单）

Fit the itinerary to real arrival/departure times — but only read, never book.

1. First pass — web_search. Find candidate 班次/航班 (times, duration, rough price range, train/flight number). Examples: "上海 到 成都 航班 时刻", "北京 西安 高铁 时刻表 票价". Capture 2–3 candidates. For trains, a fare/区间 from web_search or 12306 is enough — stop here (12306 is the single source of truth; use a browser only if you need live 余票/具体车次).
2. Flights — browser price check is MANDATORY (机票必须用浏览器查一遍). A flight fare moves too much for a web_search number to be trusted, so for every air leg you must open the booking sites in a browser — Claude in Chrome / Windows-MCP / Desktop Commander, whichever is connected — and read the live fare for the chosen flight/date on several platforms: 携程 / 飞猪 / 航司官网（必查： 东航/国航/南航等实测可查，官网有券时更低）（去哪儿/美团/同程/艺龙已废，别浪费时间——平台真值表见 references/research-playbook.md）。International: add Google Flights / Skyscanner (no login). 国内机票全平台列表价均为裸价——无一例外，航司官网也是（个别官网页面标着「含税总价」，订单页实测 仍另加机建+燃油，别被页头骗了）。预算必须用含税总价 = 裸价 + 机建费 + 燃油附加费；燃油费率随油价 频繁调价，先 web_search 最新标准再折算并注明执行日期；要看真实税费可进订单第一步的价格明细页（只读， 绝不提交）。读不到就标「票面价 · 燃油/机建另计，以出票页为准」，不许编税费。 Put those real, same-session prices + the exact query time into the .price-compare block, cheapest tagged. This is query-only — obey the prohibitions below.
   • At a login wall / captcha — defer it, don't block; batch all logins into ONE prompt. You never enter passwords or solve captchas yourself. When a platform throws a login/captcha wall, don't stop and wait there. Instead: read whatever shows without logging in (e.g. a price-calendar lowest), leave that tab open and navigate it to its login page so it's ready for the user, add it to a "needs-login" list, and move on — open and read every other platform (incl. login-free ones like Google Flights) first. Only after all platforms are queried, if the needs-login list is non-empty, ask the user once, listing them, e.g.: "这几个要登录才能看完整价： 飞猪、某航司官网。我已把每个标签页都停在登录页了——请你一次性全部登录（我不会替你输密码或过验证码），都登好 告诉我，我再回去逐个读价。" Wait for one confirmation, then go back and read the now-accessible fares on each previously-walled tab. (Batching beats pausing per-platform — the user logs in once, not N times.)
   • Fall back per-platform as a last resort — no browser connected, or the user skips / can't log into a given site. For just those, use web_search ranges and label them "web_search 估价 · 未浏览器 核实，请在购票平台确认". Never present an estimate as a browser-verified price; keep the platforms you did read live as the real comparison.
3. Hard prohibitions — what YOU never do (the user may do these manually):
   • ❌ You never log in or type passwords. (If login helps, the user logs in manually, then you resume reading — see the login-wall step above.)
   • ❌ You never read, solve, or bypass CAPTCHAs / 验证码 / 滑块. (The user clears it themselves.)
   • ❌ Never place an order, reserve, or pay — booking is always the user's, not yours.
4. Integrate the chosen transport into the plan:
   • The arrival time anchors Day 1 (don't schedule a 9 AM museum if the flight lands at 13:00).
   • The departure time caps the last day (leave time to get to the airport/station + check-in).
   • Between cities, leave a generous 赶车 / 赶飞机 buffer (airport: arrive ~2–3h before international / ~1.5h domestic; train: ~30–45 min at a big station).
   • Put each leg in a transport-segment card (times, price range, booking link) — see the design system. The link is for the user to book; the skill never books.

More detail and copy-paste search patterns: references/research-playbook.md.

Step 3 — 天气 + 真实数据

• Weather: web_search the destination + travel dates — typical seasonal weather and, if the dates are within ~10–14 days, the forecast. This drives clothing notes, the energy curve, and rain Plan B.
• Season-specific facts: festivals/events on those dates, peak-season crowds, closure days (many museums close Mondays; some attractions close for holidays), and ticketing windows (timed-entry, sells-out-early).
• Per-place facts — verify, never fabricate: opening hours, closing day, address, and ticket price for every attraction and recommended restaurant. If a fact can't be confirmed, mark it "以官网为准" rather than inventing it. Wrong hours that send the traveler to a closed door are the worst failure this skill can produce.
• 小红书攻略 — 每趟都搜一遍，不是可选项（用户反复要求，且产物里经常被漏掉）。 至少跑一次 web_search "\x3C目的地> 攻略 小红书" / "\x3C目的地> \x3C主题/人群> 避雷 小红书"，捞本地玩法、出片机位、 排队/避坑、亲子或银发实操。但必须鉴别软广：通篇只夸、出现「合作/赞助/探店/团购券/到店报暗号」、 统一话术配统一滤镜、引导私信下单的当广告打折；只采被多篇独立笔记重复印证的具体经验（如"X点后不排队"）， 单篇热帖不作准，硬事实（票价/时间）仍以官网为准。把采到的写进相关 POI 的 poi-tip 或 tip callout。 详见 references/research-playbook.md §1 的鉴别清单。

Step 4 — 行程编排逻辑（核心）

This is what separates a real plan from a list of famous places. Apply all of it:

• 地理聚类: group each day's stops by proximity so the route is a smooth line, not zig-zag backtracking. One neighborhood/area per half-day where possible. The embedded map makes bad routing obvious — use it as a check.
• 时间预算: for each stop budget 停留时长 + 点间通勤 + 缓冲. Be honest about transit time between points. Aim for 2–4 主要点 per day — fewer for 悠闲/银发/亲子, more only for 暴走. Don't cram.
• 点间通勤 + 步数 (标在卡片上): between consecutive stops, state the commute (mode + distance + time, e.g. 🚶 600 m · 步行 8 min or 🚇 3 站 · 12 min) as a transit connector, and it must match the day's route on the map. Sum each day's walking into a 步数估算 (≈ 1,300 步/km) shown in the day's overview line. Keep walking legs short for 银发/亲子 and call it out. 跨片区/打车腿的里程·时长·过路费必须真的去高德路线规划跑一遍（浏览器已连时这是强制动作，标「（高德 实测）」；不是写个「以高德为准」就算完——那只是连不上浏览器时的退路）。纯步行短腿（≤2km）可按 70–80 m/min 估，但出现打车¥或分钟就必须有高德来源。
• 餐饮卡位: place 午餐 / 晚餐 at a spot that's on the route at the right time, near the stop you'll be at — not a detour across town.
• 硬约束:
  • Skip any stop on its closing day; reorder days to fit.
  • Use 日出 / 日落 times for viewpoints, photo spots, night views.
  • Flag every stop that needs advance booking / 预约 / timed ticket with a must callout and a checklist item.
• 体力曲线: keep the arrival day and departure day light; put the most demanding day in the middle. Don't schedule a dawn hike the morning after a red-eye.
• 天气备选 (Plan B): for outdoor-heavy days, give an indoor alternative (museum, mall, aquarium, café district) in a weather callout, so rain doesn't wreck the day.

Deeper heuristics (time-budget rules of thumb, clustering, multi-city pacing): references/research-playbook.md.

Step 5 — 住宿备选（选酒店：看评论、偏连锁、多平台比价）

This step is NOT optional, and it is the one most often silently dropped. The final HTML must contain a 住宿备选 section with at least 3 .hotel cards in every plan — including when the user never mentioned hotels, and including non-interactive / "你直接安排就行" runs (pick the area from the itinerary's geographic clusters and state your assumption, e.g. "按 市中心+近地铁 选了3家，已订可忽略"). The only exception: the user explicitly says accommodation is already settled (已订酒店 / 住朋友家 / 公司安排). Then replace the section with a single 已订住宿 card (their hotel's name/address if given, map pin, transit from it to each day's first stop) and add data-hotels="user-booked" on that section so the checker knows the omission is deliberate. check_html.py fails the build if neither is present.

Give the user at least 3 hotel options (备选), not one — placed near the itinerary's geographic clusters / transit and matching their 住宿位置偏好 from Step 1.

浏览器核实对酒店是强制项，和机票同级——必须主动去连、去查，不是"有机票才连浏览器"。 （这是真实翻车点：一次纯火车的行程里，agent 以为"机票才是 skill 强制要浏览器的那项"，于是压根没去连 Chrome，酒店直接走了 web_search 估价。错。）只要本行程要选酒店（非"已订"），你就必须主动尝试启动/连接 浏览器（Claude in Chrome / Windows-MCP / Desktop Commander，哪个连着用哪个），对价格和评论都实查—— 和 Step 2 机票一字不差的纪律。有没有机票，与酒店要不要连浏览器，毫无关系。

• 价格：浏览器读现役平台（携程/飞猪）实时价。只有在真的尝试过、确认没有浏览器可用（没连上 / 用户 跳过）时，才退到 web_search 区间，并标「web_search 估价 · 未浏览器核实」。默认就走估价、不去连浏览器 = 违规。
• 评论：评论只能靠浏览器（携程/高德点评区）——web_search 给不了真实评论区，硬写就是编造。 没浏览器读到评论时，遵守数据诚信契约：.h-rating 写「评分以 App 为准」（不写任何分数/条数）， .review-check 只写连锁常识推荐理由，绝不写"可信/已核/分布正常/好评集中在X"这类结论。
• A missing browser never justifies skipping the section; it only downgrades prices to labeled estimates and strips the review verdict — it never licenses a web_search「估价」shortcut that skips the attempt, nor a fabricated rating.

Selecting a hotel is otherwise the same discipline as flights: research, don't trust the listing; compare prices across platforms; read the actual review section; never book.

• Read the reviews, NOT the marketing blurb (硬性要求). A pretty listing and a high headline score mean nothing on their own. Open the actual review section (大众点评 / 携程 / 去哪儿 / 小红书 / Google / Booking) and read recent and negative reviews, then judge whether the review area looks normal:

  • Healthy signs: a large review count, recent activity (reviews in the last weeks), specific praise (mentions 隔音/早餐/前台/床), and a believable mix — 100% 5★ is a red flag, not a green one.
  • Avoid / warn (recurring serious complaints): 卫生差 / 有虫 / 隔音差 / 不安全 / 偷换房型 / 强制消费 / 前台态度 / 与图片不符. If the same serious complaint repeats across recent reviews → drop it.
  • Fake-review tells: a burst of identical, generic, dateless 5★; a score wildly out of line with the written complaints; or all reviews old/stale. Treat these as untrustworthy.
  • 评论必须双信源：携程 + 高德，缺一不可。 单一平台不够可信——携程好评偏光鲜、运营痕迹重，高德 POI 评价更接近真实住客口碑。流程：携程筛「4.7 分以上」找候选连锁、读携程评论 → 同一家再去高德读一遍 （amap.com/search?query={城市}{酒店名} → 点搜索按钮 → 点 POI →「评价」）→ 交叉比对，携程光鲜但 高德有复发吐槽（旧/吵/窗户/卫生），信高德。.review-check 写清两边各自说了什么。

• Prefer chains (连锁) when they fit — especially for 银发/亲子 (consistent cleanliness, standards, easy recourse): 华住会 (汉庭/全季/桔子/星程/宜必思/美居), 锦江 (锦江之星/7天/维也纳), 首旅如家 (如家/和颐). But a chain is not an auto-pick — a specific branch with bad recent reviews is still out; reviews override the brand. A boutique/民宿 is fine if its reviews are strong, specific, and authentic and it suits the trip — just flag the higher variance.

• 价格和评论是两套独立的多源要求，都要做——别混为一谈（真实翻车点）。 一次运行里 agent 把"评论双信源 携程+高德"当成了"查两家就完事"，于是只碰了携程和高德，把飞猪价格比价整个丢了。记牢这张表，三个平台 都要碰：

  维度	必查平台	为什么不能互替
  价格比价（.price-compare）	携程 + 飞猪（国际加 Booking/Agoda）	高德没有房价，不能当价格源
  评论核验（.review-check）	携程 + 高德	飞猪评论不顶替高德；高德 POI 口碑更真

  → 一张合格的酒店卡 = 携程（价+评）+ 飞猪（价）+ 高德（评）三次浏览器读。查了携程+高德 ≠ 完成，飞猪价格 仍要查；只有飞猪真的连不上/验证码墙/未读到，才在那一行如实标「飞猪 · 验证码墙未读」并退到 web_search 估价 （标「估」），绝不是默认不查飞猪。check_html.py 会 FAIL 任何「飞猪只写了"订前自己比"却没真查」的酒店卡。

  • 一个源失败，绝不连累另一个（真实翻车点）。 一次运行里高德评论没加载出来，agent 就写「高德/飞猪我没 核到」——把价格源飞猪和评论源高德捆在一起一起放弃了。高德（评论源）失败，与飞猪（价格源）该不该查， 毫无关系；反之亦然。一个挂了就单独如实标它挂了，另一个照查。
  • 高德评论是懒加载——别太早下"没评价"的结论。 点开 POI 后 wait 3–5s、必要时在详情面板内下滚一下再读； 搜索若默认跳了北京＝没解析到城市，把城市名加进 query 重搜+点搜索按钮。「高德没返回评价」十有八九是没等够。

• 别默认「集团 App 会员价更低」——实测未必，且华住会官网查不到价；会员价只有真读到才写。Use the same defer-and-batch login handling and the query-only prohibitions from Step 2 (never log in / solve captchas yourself, never book). Trains/flights/hotels all share that flow.

• Output each option as a hotel card (chain badge, 评分 + 点评数, 区域/到地铁/到当天景点群的距离, a short 评论体检 note saying what reviews actually say, the multi-platform .price-compare, and a booking link). Pin the top pick on the map. Mark a 推荐 vs 次选/备选 if helpful. See references/design-system.md (hotel card) and references/research-playbook.md (vetting method).

Step 6 — 输出（沿用 study-notes 的 HTML 规范，按旅行场景改造）

Read references/design-system.md and follow it exactly. Build ONE standalone HTML file containing:

• Themed hero header (required, on every trip): a gradient banner keyed to the trip's subject (theme-night/ocean/sunset/forest/city/sakura/snow/desert, optional deco-stars/deco-glow, or a custom gradient from the destination's palette), with the headline facts wrapped as translucent .tag pills (3–6: 天数 / 核心体验 / 预算档 / 节奏 / 人数). Use .chip pills elsewhere to wrap short item lists (必吃、亮点、随手鸟点). See "Themed hero header" in the design system.
• Embedded Leaflet map (#map + the TRIP data object) showing each day's stops as numbered pins and the day's route as a colored dashed line. Every stop needs lat/lng (look them up; district-level is an acceptable fallback). OSM tiles, no key.
• Per-day timeline: one .sec-COLOR section per day, opening with a daily overview line (.day-meta: 当日花费 + 步数 + 主要点数). Each stop is a POI card showing 名称 / 到达时间 / 停留时长 / 票价 / 营业时间 + a one-line poi-tip, with a collapsible \x3Cdetails> for "如何前往 / 周边吃喝". Between consecutive cards put a transit connector (.transit: 步行/地铁/打车 + 距离 + 时间) = the route to the next point.
• Transport-segment cards: 航班 / 车次, times, price range, booking link. For flights, include a .price-compare multi-platform comparison (去哪儿/携程/飞猪/官网…, cheapest tagged).
• 住宿备选 section (.hotel cards, ≥3 options): chain badge, 评分 + 点评数, 区域/距离, a 评论体检 note (what the reviews actually say — not the listing blurb), a multi-platform per-night .price-compare, and a booking link. Prefer chains; reviews override the brand. Pin the top pick on the map.
• Budget table (.budget) with per-day subtotals (fixed 大项 grouped, then one block per day, each day's subtotal = that day's 当日花费 chip) and a grand .total row + pre-departure checklist (.checklist, persists ticks in localStorage) covering 订票 / 证件 / 预约 / 必带物.
• Kept mechanisms: collapsible sections, hierarchical TOC + floating sub-heading navigator, scroll-position memory, dark-mode theme. Callouts carry travel meaning: must = 必订/必约, warn = 注意/赶车/闭馆, avoid = 避雷, tip = 省钱省时, weather = 雨天 Plan B, info = 须知.

Build + check (before presenting)

After assembling the HTML, run the static checker and fix anything it flags:

python3 scripts/check_html.py \x3Coutput>.html
# or on Windows: py scripts\check_html.py \x3Coutput>.html

It verifies \x3Cdiv> balance, that the Leaflet CDN + #map + a non-empty TRIP object are present, that every map stop has numeric coordinates, that no leftover KaTeX $$…$$ math slipped in from the template's study-notes lineage, and that the travel components actually landed: ≥3 .hotel cards (or the explicit data-hotels="user-booked" marker), a .budget table, and the localStorage-backed .checklist. Re-run until clean, then tell the user where the file is.

Output spec summary (the retargeted規范, for quick reference)

The full spec is in references/design-system.md. In brief, what changed from study-notes:

Test prompts

After building the skill, try these (they exercise requirements-gathering, English input, and the train-query path):

1. 下个月中旬带爸妈去成都玩4天,从上海出发,预算中等,想看大熊猫、吃地道川菜,老人家走不动太多路,节奏悠闲点,帮我做个行程。 — 银发亲子 + most info given; should confirm only the few missing bits, then plan light-paced days with low-walking routing and an indoor Plan B.

2. Plan a 5-day Tokyo itinerary for the two of us in early July, flying from Shanghai. We love food and anime (Akihabara), want one day-trip outside the city, mid-range budget, and don't mind a packed schedule. — English, couple, fast pace; should fit flights to Day 1 / Day 5, cluster by district, and map it.

3. 9月23到26号去西安,兵马俑、城墙、回民街都想去,顺便帮我看下从北京出发的高铁大概几点有车、大概多少钱。 — destination + dates + a transport-query ask; should still gather missing prefs (同行/预算/节奏), web_search the 北京→西安 高铁 options into a transport card (query-only), and avoid any closure-day clashes.