build-mvp

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Build MVP

构建MVP

Build the complete app by executing every task in

docs/product-roadmap.md

, in order, until all tasks are checked off.

通过按顺序执行

docs/product-roadmap.md

中的所有任务，构建完整应用，直至所有任务都被勾选完成。

Setup

准备工作

Read

docs/product-roadmap.md

first — it is the source of truth for what to build and in what order.

docs/prd.md

is the technical spec behind it;

docs/design.md

holds the visual design tokens;

docs/product-vision.md

holds the product strategy. Do not load these documents wholesale — each phase lists the specific Reference sections to read, plus whatever a task's Notes line points to. If

docs/product-roadmap.md

docs/prd.md

is missing, stop and tell the user to run the Product Planner skill first (part of BuilderOS: https://github.com/BuildGreatProducts/builder-os).

首先阅读

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）。

Work loop

工作循环

Repeat until every task in the roadmap is complete:

Find the first unchecked task (
```
- [ ]
```
). Tasks are ordered intentionally — never skip ahead.
Read what the task needs — its Files and Notes lines, plus the current phase's Reference sections if not yet read this session.
Implement the task exactly as specified — file paths, package names, and config values are deliberate. Follow the repo's
```
CLAUDE.md
```
/
```
AGENTS.md
```
guidelines: simplest implementation that satisfies the task, no speculative features, surgical changes only.
Test and verify before moving on. Run the verification step at the end of the task's Notes, run the app, run existing tests, and add tests for new logic. If verification fails, fix it first — never mark a failing task complete or start the next task with the app broken.
Mark the task complete — change
```
- [ ]
```
to
```
- [x]
```
and update the header status line (
```
**Status:** X/Y tasks complete
```
,
```
**Current Phase:** ...
```
).
At each phase boundary: run the app end to end and confirm the phase's Goal is true and demoable before starting the next phase. No git or GitHub actions here — version control happens once at the end, after every phase is complete.

重复以下步骤直至路线图中的所有任务完成：

找到首个未勾选的任务（
```
- [ ]
```
）。任务是按特定顺序排列的——切勿跳过任务。
了解任务需求——查看任务的Files和Notes行，以及当前阶段的参考章节（若本次会话尚未阅读）。
严格按要求实现任务——文件路径、包名称和配置值都是经过确定的。遵循仓库的
```
CLAUDE.md
```
/
```
AGENTS.md
```
指南：采用能满足任务要求的最简实现方式，不添加推测性功能，仅进行精准修改。
测试验证后再推进。执行任务Notes末尾的验证步骤，运行应用，执行现有测试，并为新逻辑添加测试。若验证失败，先修复问题——切勿标记失败任务为完成，也不要在应用存在问题时启动下一项任务。
标记任务完成——将
```
- [ ]
```
改为
```
- [x]
```
并更新标题栏的状态行（
```
**状态:** X/Y 任务已完成
```
，
```
**当前阶段:** ...
```
）。
在每个阶段边界处：端到端运行应用，确认该阶段的目标已达成且可演示后，再启动下一阶段。此阶段不进行git或GitHub操作——版本控制在所有阶段完成后统一进行。

Rules

规则

The PRD's stack choices are final — implement them, never substitute alternatives.
Visual styling comes from
```
docs/design.md
```
tokens — never invent colors, type, or spacing. If
```
docs/design.md
```
doesn't exist, follow the roadmap's foundation-phase guidance: prompt the user to run the Design System skill before styling work begins.
If a task is ambiguous or conflicts with the PRD, check the PRD section it references; if still unclear, ask one specific question rather than guessing.
If necessary work isn't covered by any task, surface it and propose adding a task — don't silently expand scope.
Keep going until
```
**Status:** Y/Y tasks complete
```
: every task checked, every phase verified, the magic moment working end to end.
No git or GitHub actions (init, commits, branches, pushes, PRs) until every phase is complete — version control is the wrap-up step, not part of the work loop.

PRD中选择的技术栈是最终决定——严格按其实现，切勿替换为其他方案。
视觉样式来自
```
docs/design.md
```
中的令牌——切勿自行定义颜色、字体或间距。若
```
docs/design.md
```
不存在，请遵循路线图中基础阶段的指引：提示用户在开始样式工作前先运行Design System技能。
若任务存在歧义或与PRD冲突，请查看其引用的PRD章节；若仍不明确，请提出一个具体问题而非自行猜测。
若存在未被任何任务覆盖的必要工作，请告知用户并建议添加新任务——切勿擅自扩大范围。
持续推进直至
```
**状态:** Y/Y 任务已完成
```
：所有任务已勾选，所有阶段已验证，核心功能可端到端运行。
在所有阶段完成前，不进行任何git或GitHub操作（初始化、提交、分支、推送、PR）——版本控制是收尾步骤，不属于工作循环的一部分。

Wrap up

收尾工作

When every task is checked off and the magic moment has been verified end to end:

Initialize git and create the initial commit. If the project isn't a git repository yet, run
```
git init
```
, add a sensible
```
.gitignore
```
for the stack (dependencies, build output,
```
.env
```
files — never commit secrets), and commit everything with an initial commit message naming the product and noting the MVP build is complete. If the project is already a git repository, commit the build on the current branch instead.
Ask the user if they want to connect a remote repo. Don't create or push anything on your own — ask: "Want me to connect this to a remote repo? I can create one on GitHub (public or private) or connect an existing URL." If yes, set it up as
```
origin
```
, push, and confirm the push succeeded. If no, leave it local and tell them the commit is ready to push whenever they are.

当所有任务都已勾选且核心功能已通过端到端验证后：

初始化git并创建初始提交。若项目尚未成为git仓库，运行
```
git init
```
，为技术栈添加合理的
```
.gitignore
```
文件（包含依赖项、构建输出、
```
.env
```
文件——切勿提交机密信息），并使用包含产品名称且注明MVP构建完成的初始提交消息提交所有内容。若项目已是git仓库，则在当前分支上提交构建内容。
询问用户是否要连接远程仓库。不要自行创建或推送任何内容——询问：“需要我将此项目连接到远程仓库吗？我可以在GitHub上创建一个（公开或私有）仓库，或是连接现有仓库的URL。”若用户同意，将其设置为
```
origin
```
并推送，确认推送成功。若用户拒绝，则保持本地仓库，并告知用户提交内容已准备好，可随时推送。