name: build-personalized-travel-guide-open-source description: 生成、更新或还原个性化旅行手册网页，含八模块、旅行模式与记账；支持按需 Cloudflare 共享部署。

Personalized travel handbook

Build destination-specific content in the user’s workbench using the bundled assets/current-system/product/ template. Do not write destination facts into the installed Skill or its template. Preserve the approved responsive interface, eight chapters, Mini Routes, Trip Mode, itinerary adjustment and saved state. The public template is an empty component scaffold, never evidence for a destination. Restoring it previews components; it is not a completed handbook.

对话语言

面向中文用户，安装说明、进度更新、问题说明、问卷交付和最终回复使用中文；代码、命令、路径及专有名词保留原样。用户明确要求其他语言时遵从用户。此要求约束对外回复，不声称控制宿主内部思考语言。

Installation and questionnaire entry

After an authorized installation or when asked to start/open the questionnaire, expose assets/intake-questionnaire/index.html immediately as an actual clickable file. If the host cannot link installed assets, copy this self-contained file to the user workspace and attach/link that copy. A statement that installation succeeded or an instruction to invoke the Skill again is not questionnaire delivery. Opening the file does not require Python, Pillow, Node, restoration or tests. Honor host security review; do not add full development tests to installation. Never claim the browser opened successfully without an observed result.

Choose the task

Read only the applicable route and the references needed for its current stage.

Boundaries

• New-handbook gate: (1) collect the questionnaire output or an equivalent written brief; (2) show one compact daily itinerary proposal; (3) wait for the user to approve that displayed proposal. Do not research the full handbook, create a production workbench, download images, build maps or render HTML before gate 3. 按默认 completes intake only. The sole exception is an explicit instruction to skip discussion and generate directly.
• A complete brief starts a compact itinerary proposal. Reuse approval already given in the current conversation. 不要讨论，直接生成 waives discussion; 按默认 waives the questionnaire, not route review. Record the actual approval/waiver in itinerary-outline.md when creating the workbench.
• Use the current brief; reuse earlier destinations or personal records only when requested. Missing optional preferences use defaults. Transport/stays remain pending unless the user supplies bookings or a complete trip-decisions.json; this product does not research or compare flight/hotel options.
• Resolve scripts and references from this Skill root. A persisted workbench from another root must resume with its original scripts; do not mix versions. Overseas destinations do not select the legacy international Skill. ui_system: canonical is for explicit legacy compatibility only.
• Never invent venues, coordinates, hours, prices, ratings, source access or QA evidence. Verify changing facts or state uncertainty. Preserve asset provenance and repair actual failures rather than manufacturing passing records.
• Before cloud deployment, ask once whether the user wants an access code to protect private information, unless their access-mode choice is already explicit in this conversation. Explain that anyone with an open link may access shared content; do not interpret deployment approval as approval for open access. When code protection is chosen, default to the bundled responsive access-code page plus a secure server session on both phones and computers; require no username and never use the browser-native HTTP Basic prompt unless the user explicitly requests it. Follow cloud access choice and wait for the choice before publishing.
• Deployment and shared uploads follow existing user authorization. Communicate material limitations honestly; local/cloud data boundaries and the once-only deployment offer are in intake.

Production after route approval

Default to one agent for research, itinerary decisions, authoring and verification. Do not spawn subagents unless the user explicitly requests them for this task; a request to optimize, speed up or use defaults is not permission. Concurrent tool calls and bounded asset downloads within that one agent remain allowed. Use standard fast path and source ownership. Read delegation only after an explicit delegation request.

Use a verified Python interpreter (on Windows see runner setup). Preserve the current approved inputs with --brief-file as described in the production flow so initialization does not drop interests, travelers or constraints. The commands below are relative to this Skill root:

python scripts/start_build.py <workbench> --brief-file <current-brief.json> --destination <name> --country <country> --start-date YYYY-MM-DD --days N --itinerary-approved --user-statement "<verbatim user approval>"
python scripts/advance_build.py <workbench>

The controller supplies the next stage and current pack task. Use pipeline for pack ownership/dependencies, content model for module content, selection for route decisions, and data shapes for unfamiliar fields. Read the reference needed for the current decision, not this entire list.

Resolve place identity, coordinates, visible rating and image feasibility in the same visit under Google lookup. Use image policy for asset acceptance. Reuse facts across chapters and Trip Mode; do not create separate enrichment passes.

The compiled profile is the content source. Install/render through official rendering; repair owning packs rather than final HTML. Keep the product inventory and UI implemented by the bundle; authoring details live in the content model, not a second component-building task.

Offline maps default to exactly one full-day overview per itinerary day, preserving image resolution, full place labels and external navigation links. Do not automatically add local-area captures. Attempt the original street-map capture first; only evidenced failure permits the geographic offline-overview fallback. No online-map fallback.

Completion and recovery

Release validation owns QA scope and the response states. Run check_handoff.py <workbench> after source, render and required QA work; it already runs the appropriate strict audit and forward test.

• In progress: initialization, regression-test success and a completed research batch are intermediate results, not a stopping point. When continuation_required: true and user_input_required: false, send progress in commentary and execute the next action in the same turn; do not end with a final response or ask the user to say “继续”. Skill scripts report this condition but cannot enforce a host-level stop hook. Follow the controller's next action and repair named failures. A patch mismatch, bad JSON or failed optional source is a reason for a focused correction, not a request for the user to say “继续”.
• Waiting for review: only after automatic gates pass, a recorded browser limitation or authorized pending human QA may allow a preview response. final_response_allowed permits that response; handoff_allowed remains false and QA stays pending.
• Complete: claim full completion only after HANDOFF ALLOWED. Do not repeat passing checks without changed inputs or an unresolved concern.

手册完成后，按 intake 询问一次：“手册已完成。需要我帮你上传到云端，让同行人共享 PDF 文档、图片、链接和记账吗？”用户已授权部署时直接继续，不重复询问；未同意时保留本地版。云端交付必须包含附件文件与元数据、成员、账目、分摊及还款的共享，并按 current system 验证，不能仅上传静态网页便声称共享完成。

Use fetch recovery for asset/map failures and gateway recovery for platform failures. Stop repeating an unsuccessful method, preserve partial work, and diagnose its cause. A documented external blocker may require user input; workload alone does not.

Skill/code maintenance is complete when the requested rules and their generated tasks agree, affected regression tests and audit_skill_consistency.py pass, and remaining limitations are stated. Continue through fixing failures caused by the change; a first patch is not completion. UI/runtime changes additionally use the maintenance QA scope. Do not regenerate a real destination to validate an instruction-only edit.

Use the single production standard. No edition selection or quality-tier question is needed.

Paired delivery

Use the self-contained offline HTML as the primary artifact, never the workbench index.html alone or a handbook ZIP. Release validation owns export creation, hash-bound acceptance and pending-review exceptions. Tell the user: “双击离线 HTML 即可在本地离线打开，无需解压；导航外链与共享功能需要联网。”

The UI contract owns priority labels and single-image layout; apply those existing components without a separate redesign pass.

Explicit cold starts

When the user explicitly requests 冷启动/不复用/independent rebuild, use start_build.py <new-empty-workbench> ... --cold-start. Do not resume any matching old workbench. Reuse Skill code and the empty product template only; reacquire destination facts, images, maps and QA evidence. Do not copy a prior handbook’s research packs, authoring scripts, downloaded media or validation records. Retain prior builds unchanged.

旅行攻略 Skill 3.0

推荐在 Codex 中使用本 Skill，并选择 GPT 5.6 SOL 或能力更强的模型。

本次升级围绕旅行中的实际使用，优化界面、旅行模式和攻略生成流程，让行程、参考资料与开销记录更方便集中管理。

新增功能

• 自定义行程资料：支持在对应行程中添加自定义按钮，保存小红书等攻略链接、上传 PDF 票据和拍摄参考图片，方便随时打开查看。
• 摄影与穿搭提示：提供每日摄影小贴士和穿搭参考，辅助行前准备与现场拍摄。
• 每日替代方案：为当天行程提供备选安排，方便应对天气变化或计划调整。
• 旅行记账与汇率换算：记录餐饮、交通、购物等旅行开销，并支持外币金额换算。
• 准备事项与贴士优先级：在事前准备和旅游贴士中增加优先级，突出需要提前处理的事项与重点提醒。

体验优化

• 全新 UI：界面更清爽，优化信息层级和内容布局。
• 旅行模式优化：集中查看每日行程、路线图和相关资料，保留谷歌地图跳转与小红书搜索入口。
• 路线展示更清晰：更直观地查看当天地点与行程顺序。
• 保留完整八模块结构：兼顾出发前的攻略阅读与旅途中的快速查询。

生成与部署

• 先确认行程，再生成手册：生成前先与用户确认旅行安排，支持沟通调整后再制作完整攻略。
• 集成可选云部署流程：主动询问用户是否需要部署到云端，确认后继续完成部署，方便通过链接打开并分享给同行伙伴。
• 支持添加到手机桌面：部署后的网页版手册可添加到手机桌面，方便像 App 一样快速打开。

使用

航班与酒店仅整理用户提供的预订事实，未提供时保持待确认。

1. 下载完整仓库，将文件夹放入支持本地 Skill 的 Agent 技能目录。
2. 在 Codex 中说：使用 $build-personalized-travel-guide-open-source 开始制作旅行手册。
3. 提交问卷后，Agent 先给逐日行程草案。回复确认后才开始生成完整网页；只有明确说“不要讨论，直接生成”时才跳过草案确认。

运行环境需要 Python 3.10+、Pillow，以及联网检索、文件读写、图片查看和浏览器交互能力。

交付内容

完成后会生成一份可直接打开的离线 HTML 手册，无需解压。导航链接和共享功能需要联网。

如需与同行伙伴共同使用，可以选择部署到 Cloudflare。云端版支持共享链接、图片、PDF、同行成员、记账、分摊和还款，并可设置访问码。

隐私

问卷内容默认保存在本机浏览器。仓库不包含个人订单、私人旅行手册或云端访问凭据。云端分享为可选功能，部署时可使用访问码保护手册及共享资料。

许可

自有代码与文档采用 MIT License，允许按许可证使用、修改和分发。第三方组件保留原许可证，详见 THIRD_PARTY_NOTICES.md。后续获取的图片和地图不自动获得 MIT 授权。