build-mvp

构建 MVP

按顺序执行 docs/product-roadmap.md 中的每一项任务，直到所有任务都标记为已完成，从而构建完整应用。

设置

先阅读 docs/product-roadmap.md——它是构建内容及其顺序的唯一准则。docs/prd.md 是其背后的技术规范；docs/design.md 包含视觉设计令牌；docs/product-vision.md 包含产品战略。不要一次性完整加载这些文档——每个阶段都会列出需要阅读的特定参考章节，以及任务“Notes”行指向的内容。如果缺少 docs/product-roadmap.md 或 docs/prd.md，请停止，并告知用户先运行 Product Planner 技能（属于 BuilderOS：https://github.com/BuildGreatProducts/builder-os）。

工作循环

重复以下步骤，直到路线图中的每项任务都已完成：

1. 找到第一项未勾选的任务（- [ ]）。任务顺序是经过规划的——绝不要跳过。
2. 阅读任务所需内容——它的“Files”和“Notes”行，以及当前阶段的“Reference”章节（如果本次会话尚未阅读）。
3. 严格按要求实现任务——文件路径、包名称和配置值都是经过审慎决定的。遵循仓库的 CLAUDE.md/AGENTS.md 指南：采用满足任务要求的最简单实现，不添加臆测的功能，只做必要的精准修改。
4. 继续之前先测试并验证。 执行任务“Notes”末尾的验证步骤，运行应用和现有测试，并为新增逻辑添加测试。如果验证失败，先修复问题——绝不要将失败的任务标记为完成，也不要在应用仍有问题时开始下一项任务。
5. 将任务标记为已完成——把 - [ ] 改为 - [x]，并更新标题状态行（**Status:** X/Y tasks complete、**Current Phase:** ...）。
6. 每个阶段结束时： 端到端运行应用，并确认该阶段的目标已实现且可以演示，然后再开始下一阶段。这里不要执行 git 或 GitHub 操作——等所有阶段完成后再统一进行版本控制。

规则

• PRD 中的技术栈选择是最终决定——必须按其实现，不能换用其他方案。
• 视觉样式必须来自 docs/design.md 中的令牌——绝不要自行设定颜色、字体或间距。如果 docs/design.md 不存在，请遵循路线图中基础阶段的指导：在开始样式工作之前，提示用户运行 Design System 技能。
• 如果任务含糊不清或与 PRD 冲突，请查阅任务引用的 PRD 章节；如果仍不明确，请提出一个具体问题，不要猜测。
• 如果有必要的工作未被任何任务涵盖，请指出并建议添加任务——不要默默扩大范围。
• 持续执行，直到达到 **Status:** Y/Y tasks complete：每项任务都已勾选，每个阶段都已验证，核心体验已端到端正常运行。
• 在所有阶段完成之前，不要执行 git 或 GitHub 操作（初始化、提交、分支、推送、PR）——版本控制是收尾步骤，不属于工作循环。

收尾

所有任务都已勾选，并且核心体验已通过端到端验证后：

1. 初始化 git 并创建初始提交。 如果项目还不是 git 仓库，请运行 git init，为技术栈添加合理的 .gitignore（依赖项、构建产物、.env 文件——绝不要提交密钥），并提交所有内容。初始提交消息应注明产品名称及 MVP 构建已完成。如果项目已经是 git 仓库，则在当前分支上提交本次构建。
2. 询问用户是否要连接远程仓库。 不要自行创建或推送任何内容——询问：“要我帮你连接远程仓库吗？我可以在 GitHub 上创建一个仓库（公开或私有），也可以连接到现有 URL。”如果用户同意，请将其设置为 origin、执行推送，并确认推送成功。如果用户不同意，则将项目保留在本地，并告知他们提交已准备就绪，可随时推送。