已有 BuilderOS 规格文档时…

当用户要求根据 docs/product-roadmap.md 和 docs/prd.md 把所有路线图任务从头到尾实现成完整 MVP 时使用。

适用场景

解决思路

1. 先读取 docs/product-roadmap.md，把它作为要构建什么以及构建顺序的唯一事实来源；docs/prd.md 提供技术规格，docs/design.md 提供视觉设计 token，docs/product-vision.md 提供产品策略。
2. 不要一次性加载上述所有文档；每个阶段只读取该阶段列出的具体 Reference 章节，以及任务 Notes 行指向的内容。
3. 如果缺少 docs/product-roadmap.md 或 docs/prd.md，停止执行并告诉用户先运行 Product Planner 技能（BuilderOS 的一部分：https://github.com/BuildGreatProducts/builder-os）。
4. 重复以下工作循环，直到路线图中的每个任务都完成。
5. 找到第一个未勾选任务（- [ ]）；任务顺序是有意安排的，绝不跳过。
6. 读取该任务需要的内容：它的 Files 和 Notes 行，以及当前阶段尚未在本会话读取过的 Reference 章节。
7. 严格按任务规格实现；文件路径、包名和配置值都是有意指定的。遵循仓库的 CLAUDE.md/AGENTS.md 指南：采用满足任务的最简单实现，不加入推测性功能，只做外科手术式改动。
8. 在继续下一个任务前测试并验证：运行任务 Notes 末尾的验证步骤，运行应用，运行现有测试，并为新逻辑补充测试。
9. 如果验证失败，先修复；绝不在失败时把任务标记为完成，也不要在应用损坏时开始下一个任务。
10. 将任务标记为完成：把 - [ ] 改为 - [x]，并更新头部状态行（**Status:** X/Y tasks complete、**Current Phase:** ...）。
11. 每到阶段边界：端到端运行应用，确认该阶段的 Goal 为真且可演示，然后再开始下一个阶段。
12. 此时不要执行 git 或 GitHub 操作；版本控制在所有阶段完成后只做一次。
13. PRD 的技术栈选择是最终决定：按它实现，绝不用替代方案替换。
14. 视觉样式来自 docs/design.md 的 token：绝不自行发明颜色、字体或间距。
15. 如果 docs/design.md 不存在，按路线图的 foundation 阶段指引，在样式工作开始前提示用户运行 Design System 技能。
16. 如果任务有歧义或与 PRD 冲突，检查它引用的 PRD 章节；如果仍不清楚，只问一个具体问题，而不是猜测。
17. 如果必要工作没有被任何任务覆盖，把它暴露出来并提出新增任务；不要静默扩大范围。
18. 持续执行，直到 **Status:** Y/Y tasks complete：每个任务都勾选、每个阶段都验证、核心魔法时刻端到端可用。
19. 在所有阶段完成前，不执行任何 git 或 GitHub 操作（init、commits、branches、pushes、PRs）；版本控制是收尾步骤，不属于工作循环。
20. 当每个任务都勾选且核心魔法时刻已端到端验证后，初始化 git 并创建初始提交。
21. 如果项目还不是 git 仓库，运行 git init，为当前技术栈添加合适的 .gitignore（依赖、构建产物、.env 文件——绝不提交密钥），并用一条初始提交信息提交所有内容，信息中写明产品名并说明 MVP 构建完成。
22. 如果项目已经是 git 仓库，则在当前分支上提交这次构建。
23. 询问用户是否想连接远程仓库；不要自行创建或推送。
24. 向用户询问："Want me to connect this to a remote repo? I can create one on GitHub (public or private) or connect an existing URL."
25. 如果用户同意，将其设置为 origin，推送，并确认推送成功。
26. 如果用户不同意，保持本地状态，并告诉用户提交已准备好，可随时推送。

适用边界 · 注意事项

• 缺少 docs/product-roadmap.md 或 docs/prd.md：应先运行 Product Planner 技能，而不是直接开始构建。
• 用户只想实现单个任务或单个阶段，而不是执行完整路线图。
• 缺少 docs/design.md 且尚未运行 Design System 技能时，不应直接开始样式工作。