关于 build
build 是一项开发技能，通过子 Agent 执行已批准计划中的任务、验证结果并汇报进度。它也支持无计划的小型热修复或明确范围的变更，两种流程均设有验证门槛。
主要功能
- 01按依赖关系分批执行计划任务
- 02为可并行任务派发子 Agent
- 03提交已完成的任务批次
- 04在有限重试次数内运行验证
- 05支持不使用子 Agent 的顺序执行
适用场景
- 01实施已批准的多步骤计划
- 02无计划地应用小型热修复
- 03代码审查前验证变更
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/build确认已加载。
详细介绍
/build
通过子 Agent 执行计划任务、验证并汇报。
宣布：“开始 /build — 正在通过子 Agent 调度执行计划。”
前提条件
- 计划已通过
/review（第 4 步）批准，或范围说明为一句话／热修复（无需计划） - 在关联工作树中工作（而非主工作树）
有计划时
1. 加载
读取 ai-workspace/plans/<name>.md。按顺序提取任务并分批：
- 同一步骤下或标记为并行的任务 = 一批
- 依赖前序任务的任务 = 单独的顺序批次
- 记录每项任务的文件路径、测试预期和验收标准
2. 执行批次
按顺序运行批次。每批中的任务通过子 Agent 并行调度。
每项任务的 Agent 选择：
| 计划结构 | Agent | 备注 |
|---|---|---|
| 单独的“编写测试”+“实现”任务 | test-writer（RED），然后 implementer（GREEN） | 这对任务按顺序执行 |
| 组合任务（“实现 X 并添加测试”） | implementer | 在内部处理 TDD |
| 仅文档任务 | doc-writer |
**并行安全性：**仅当任务涉及不同文件时，才并行调度。
提供给每个 Agent 的子 Agent 提示词：
You are implementing Task N: [task name]
## Task Description
[FULL TEXT from plan — paste it, don't make the subagent read the file]
## Context
[Where this fits, what earlier batches produced, architectural decisions]
## Working Directory
[Absolute path to worktree]
## Project Conventions
- TDD: write failing test first, make it pass, refactor
- Commit after task completes (conventional commits) AND ensure your work is on disk before reporting DONE — the inter-batch step commits a batch boundary, but your task-level commits make recovery from inter-batch failures cleaner
- TypeScript strict, ESM, Biome, Vitest, Pino logger, no barrel exports
- Self-review before reporting back
## Report: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
处理响应：
| 状态 | 操作 |
|---|---|
| DONE | 标记任务完成 |
| DONE_WITH_CONCERNS | 阅读问题说明——如果涉及正确性／范围，在继续前处理 |
| NEEDS_CONTEXT | 补充缺失上下文，然后重新调度 |
| BLOCKED | 评估：是否需要更多上下文？能力更强的模型？拆分得更细？升级给人工处理？ |
| 任务涉及受保护文件 | 立即停止——绝不调度 |
遇到 BLOCKED 时，若不做任何调整，绝不要重试。
批次间检查——每批完成后，验证没有回归，并在开始下一批之前提交该批输出：
pnpm typecheck && pnpm test
git -C "$WORKTREE" add -A
git -C "$WORKTREE" commit -m "<type>(<scope>): batch N — <summary>"
每项任务内部的提交尽力完成；批次边界提交为强制要求（遵循 /task 不变量 REQUIRE batch.commit BEFORE batch.next）。如果某批完成验证后却未提交，那么下一批失败或会话结束时，该批所有工作都可能丢失。会话结束时，wip-checkpoint Stop 钩子（ADR-008）会将未提交状态保存为后备保障；但批次间提交能让恢复更清晰——分支历史中按批次粒度记录，而不是在旁侧引用中留下单个未提交状态块。
3. 验证（硬性门槛）
所有批次完成后：
pnpm validate
阅读输出。没有证据时，绝不宣称成功。如果失败：
- 诊断失败原因
- 修复（调度子 Agent，或针对小问题直接修复）
- 重新运行
pnpm validate - 最多进行 3 轮“修复-验证”。如果仍然失败，停止并汇报。
验证通过前，不能开始第 6 步（/review）。
4. 汇报
Build complete.
Tasks: <completed>/<total>
Validate: PASS
Next step: /review (Step 6)
包含任何 DONE_WITH_CONCERNS 备注。将构建期间做出的决定更新到 .branch-context.md。
无计划时（热修复／一句话范围）
直接实现——小范围任务无需协调子 Agent。
- TDD：编写失败测试（RED），实现修复（GREEN），重构
- 最小改动：只修复缺陷，不做其他更改（热修复）
- 根本原因：在提交信息正文中记录（热修复）
- 验证：
pnpm validate——同样的硬性门槛，最多尝试 3 次
Codex / Cursor 后备方案
不调度子 Agent。在主会话中按顺序执行任务。仍须遵守相同的验证门槛。
集成
| 关系 | 技能 |
|---|---|
| 调用方 | /task（第 5 步） |
| 依赖项 | /blueprint（第 3 步）+ /review 计划批准（第 4 步） |
| 后续步骤 | /review 构建审查（第 6 步） |