Build（构建阶段 · 路由）

来源：addyosmani/agent-skills v0.6.9 的 incremental-implementation / test-driven-development / context-engineering / source-driven-development / frontend-ui-engineering / api-and-interface-design / doubt-driven-development。 本文件是路由层，七份原文都是本技能目录下的子文件，用 read 按相对路径读取。

这个阶段干什么

按任务清单，一次一个薄垂直切片地把代码写出来。 每片都要被证据证明能跑，再往下走。

⚠️ 内嵌子文件没有注册成独立技能，用 read <文件名> 读（相对本技能目录）。

路由表

每个切片的主循环

1. 读这个任务的验收标准
2. 摆好相关上下文（现有代码 / 模式 / 类型）
3. 先写一条会失败的测试（RED）
4. 写最少的代码让它过（GREEN）
5. 跑受影响范围的测试，确认没回归
6. 跑构建，确认能编译
7. 提交（一个任务一个 commit，便于回滚）
8. 在 tasks/plan.md 里把那一项勾上

⛔ 验证范围只由 diff 决定 —— 改了什么就跑相关的，不跑全量套件。 全量是人在最后那次端到端里自己决定要不要跑的事，不是这里的例行步骤。

⛔ 不要 git add -A 盲提。 只暂存这个任务碰到的文件 + 它自己的状态更新， 这样任何一点都是干净的回滚点。

什么时候先读哪个

要写代码
  │
  ├── 第三方库/框架不熟？ ──→ source-driven-development（先查官方文档）
  ├── 上下文不清楚？ ───────→ context-engineering
  ├── 是 UI？ ─────────────→ frontend-ui-engineering
  ├── 是接口/契约？ ────────→ api-and-interface-design
  └── 其余 ────────────────→ incremental-implementation（+ test-driven-development）
                                  │
                                  └── 这个决策非平凡/风险高？ ──→ doubt-driven-development

什么时候停

遇到下面任一种，停下来处理，别硬推：

边界

做：写实现代码、写测试、改 UI/接口、一个任务一个提交、回写任务清单。

不做：

• ❌ 不改需求 —— 那在 define
• ❌ 不重新拆任务 —— 那在 plan
• ❌ 不替人做主观验收（好不好用、对不对）—— 那是 verify + 人
• ❌ 不做合并前评审 —— 那是 review

★ 共享纪律见 meta。本阶段最吃重的是 「守住范围」 和 「强制简单」 —— 顺手改无关代码、以及过度设计，都发生在这一阶段。