子代理驱动开发

按 实现计划 执行：每个任务派一个干净上下文的子代理；每任务后 两阶段评审——先 规格符合性，再 代码质量。

为何用子代理： 隔离上下文、指令精确、不污染主会话；主会话保留做协调。

核心： 每任务新子代理 + 两阶段评审 = 质量与迭代速度的平衡。

何时使用

已有实现计划
任务 大体独立
留在本会话 连续推进（相对 executing-plans 的「另开会话」）

若任务强耦合、或适合并行会话执行 → 考虑 executing-plans。

流程概要

读计划，一次性 抽出全部任务全文与上下文，建 TodoWrite。
每任务：派发 实现子代理（implementer-prompt.md）→ 若问问题先答 → 实现、测试、提交、自审 → 规格评审子代理 → 不通过则修到通过 → 代码质量评审子代理 → 不通过则修到通过 → 勾掉任务。
全部完成后：可选 终局代码评审，再 finishing-a-development-branch。

禁止： 并行派多个实现子代理（易冲突）；让子代理自己去读计划文件（应把任务全文贴给它）；跳过任一评审阶段；规格未 ✅ 就做代码质量评审。

模型选择

能完成任务的最弱模型优先，省成本。机械实现 → 快模型；多文件整合与判断 → 标准模型；架构与评审 → 最强模型。

实现子代理状态

DONE → 进入规格评审。
DONE_WITH_CONCERNS → 先读顾虑；涉及正确性/范围先处理；仅是观察可记录后继续。
NEEDS_CONTEXT → 补上下文再派。
BLOCKED → 缺信息则补；要推理则换强模型；太大则拆任务；计划错了则升级人类。

不要无视 BLOCKED 或原样重派同模型。

提示模板

./implementer-prompt.md
./spec-reviewer-prompt.md
./code-quality-reviewer-prompt.md

优势相对手动 / executing-plans

子代理易自然遵循 TDD；每任务干净上下文；可并行安全（若只并行非实现类）；实现前可问问题；本会话连续推进、无需人机之间每步等待。

成本： 每任务多次子代理调用 + 评审循环；但早发现问题通常更省。

衔接技能

必须： using-git-worktrees、writing-plans、finishing-a-development-branch。
评审模板： requesting-code-review。
子代理实现时建议： test-driven-development。
替代路径： executing-plans（另会话批量执行）。

红线： 未获同意不在 main/master 上开工；不跳过评审；开放问题未解决不进下一任务。