build-loop-claude-code

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Claude Code Build Loop

Quality-gated feature work: nothing ships on "it compiles" — every increment is built, reviewed, tested end to end, and fixed before the user hears "done."

质量管控的功能开发：绝不以“能编译”作为交付标准——每一个增量都要经过构建、审查、端到端测试和修复，之后才会告知用户“完成”。

Source of work

工作来源

A plan file exists (roadmap, refactor plan, or task list with
```
- [ ]
```
checkboxes — search the repo): work the first unchecked task. Tasks are ordered intentionally — never skip ahead. If the plan references spec docs, read only the sections relevant to the current task.
No plan (or the request is outside it): build from the user's prompt. Restate it as a verifiable goal with 2–4 success criteria and confirm scope in one message before building.

存在计划文件（路线图、重构计划或带有
```
- [ ]
```
复选框的任务列表——搜索代码仓库）：处理第一个未勾选的任务。任务是按顺序排列的——绝不跳步。如果计划引用了规范文档，仅阅读与当前任务相关的章节。
无计划（或请求超出计划范围）：根据用户的提示进行构建。在开始构建前，先将提示重述为带有2-4条成功标准的可验证目标，并在一条消息中确认范围。

The loop

循环流程

Run per task (or per prompted feature). Do not advance until every step passes.

Build. Implement exactly what the task specifies. Simplest implementation that satisfies it, surgical changes, no speculative scope. Match existing project conventions.
Review. Run /review
on the changed code. If the change touches auth, payments, user input, or data access, also run /security-review
. Fix all findings in scope — bugs, security issues, edge cases, performance, style in files you touched. If the project has a design system spec (design tokens file, DESIGN.md, theme config), check UI changes against it — no hardcoded colors, type, or spacing that bypass tokens. Note pre-existing issues in untouched code for the report instead of fixing silently. Re-run
```
/review
```
until clean. If a finding contradicts the task or spec, the spec wins — flag the disagreement.
Test end to end. Run the task's verification step (or the success criteria). Run the full test suite — everything that passed before must still pass. Add tests for new logic. Then exercise the feature as a user would: run the app, walk the real flow including empty, loading, and error states.
Fix. Anything testing finds goes back through the loop: fix →
```
/review
```
→ re-test. Never mark a failing task complete; never start the next task with the app broken.
Continue. Mark the task
```
- [x]
```
, update any progress/status line in the plan, and loop to the next task until the requested scope is complete.
Report. When done, tell the user: what was built and plan progress, review findings fixed and anything deferred, how it was verified (tests + flow walked), and what needs their attention next. Be honest about anything flaky or partially verified.

每个任务（或每个提示的功能）都要执行此循环。在每一步通过前，不得进入下一步。

构建：严格按照任务要求实现。采用满足需求的最简实现方式，仅做必要修改，不添加预期外的功能。匹配现有项目的编码规范。
审查：对修改的代码运行**
```
/review
```
。如果修改涉及认证、支付、用户输入或数据访问，还需运行
```
/security-review
```
**。修复所有范围内的问题——你修改的文件中的bug、安全问题、边缘情况、性能问题和代码风格问题。如果项目有设计系统规范（设计令牌文件、DESIGN.md、主题配置），检查UI修改是否符合规范——不得绕过令牌硬编码颜色、字体或间距。对于未修改代码中存在的既有问题，在报告中注明而非擅自修复。重新运行
```
/review
```
直到无问题。如果审查发现的问题与任务或规范冲突，以规范为准——标记出分歧。
端到端测试：执行任务的验证步骤（或成功标准）。运行完整的测试套件——所有之前通过的测试必须仍然通过。为新逻辑添加测试。然后以用户的方式使用功能：运行应用，体验真实流程，包括空状态、加载状态和错误状态。
修复：测试发现的任何问题都要重新进入循环：修复→
```
/review
```
→重新测试。绝不能将失败的任务标记为完成；绝不能在应用存在问题时开始下一个任务。
继续：将任务标记为
```
- [x]
```
，更新计划中的任何进度/状态行，然后循环处理下一个任务，直到完成请求的范围。
报告：完成后，告知用户：构建的内容和计划进度、已修复的审查问题及任何延期处理的问题、验证方式（测试+流程体验），以及接下来需要他们关注的事项。对于任何不稳定或仅部分验证的内容，要如实说明。

Rules

规则

Skipped review or untested work = unfinished work.
Don't relitigate plan decisions; if a task seems wrong, ask one specific question rather than guessing.
Discovered work no task covers? Surface it and propose a task — never silently expand scope.

跳过审查或未测试的工作 = 未完成的工作。
不要重新讨论计划决策；如果任务看起来有问题，提出一个具体的问题而非猜测。
发现计划中未涵盖的工作？提出该问题并建议添加任务——绝不能擅自扩大范围。