name: subagent-driven-development description: 当在当前会话中执行具有独立任务的实现计划时使用 - 为每个任务分配新的子代理，并在任务间进行代码审查，实现带质量门控的快速迭代
子代理驱动开发
通过为每个任务分配新的子代理，并在每个任务后进行代码审查来执行计划。
核心原则： 每个任务新子代理 + 任务间审查 = 高质量，快速迭代
概述
与执行计划（并行会话）相比：
- 相同会话（无上下文切换）
- 每个任务新子代理（无上下文污染）
- 每个任务后代码审查（早期发现问题）
- 更快迭代（任务间无人工介入）
何时使用：
- 保持在此会话中
- 任务大多独立
- 希望带质量门控的连续进展
何时不使用：
- 需要先审查计划（使用执行计划）
- 任务紧密耦合（手动执行更好）
- 计划需要修订（先进行头脑风暴）
过程
1. 加载计划
读取计划文件，创建TodoWrite包含所有任务。
2. 使用子代理执行任务
对于每个任务：
分配新子代理：
任务工具（通用用途）：
描述：“实现任务 N：[任务名称]”
提示：|
你正在实现来自 [计划文件] 的任务 N。
仔细阅读该任务。你的工作是：
1. 准确实现任务指定的内容
2. 编写测试（如果任务要求遵循TDD）
3. 验证实现工作
4. 提交你的工作
5. 报告回来
工作从：[目录]
报告：你实现了什么，测试了什么，测试结果，更改的文件，任何问题
子代理报告回来 工作摘要。
3. 审查子代理的工作
分配代码审查者子代理：
任务工具（超能力：代码审查者）：
使用模板在 requesting-code-review/code-reviewer.md
WHAT_WAS_IMPLEMENTED: [来自子代理的报告]
PLAN_OR_REQUIREMENTS: 来自 [计划文件] 的任务 N
BASE_SHA: [任务前的提交]
HEAD_SHA: [当前提交]
DESCRIPTION: [任务摘要]
代码审查者返回： 优势、问题（关键/重要/次要）、评估
4. 应用审查反馈
如果发现问题：
- 立即修复关键问题
- 在下一个任务前修复重要问题
- 记录次要问题
如果需要，分配跟进子代理：
“修复来自代码审查的问题：[列出问题]”
5. 标记完成，下一个任务
- 在TodoWrite中标记任务为已完成
- 移动到下一个任务
- 重复步骤2-5
6. 最终审查
所有任务完成后，分配最终代码审查者：
- 审查整个实现
- 检查所有计划要求是否满足
- 验证整体架构
7. 完成开发
最终审查通过后：
- 宣布：“我正在使用完成开发分支技能来完成这项工作。”
- 必选子技能： 使用超能力：完成开发分支
- 遵循该技能验证测试，呈现选项，执行选择
示例工作流
你：我正在使用子代理驱动开发来执行这个计划。
[加载计划，创建TodoWrite]
任务1：钩子安装脚本
[分配实现子代理]
子代理：实现了安装钩子带测试，5/5通过
[获取git SHA，分配代码审查者]
审查者：优势：良好的测试覆盖。问题：无。就绪。
[标记任务1完成]
任务2：恢复模式
[分配实现子代理]
子代理：添加了验证/修复，8/8测试通过
[分配代码审查者]
审查者：优势：扎实。问题（重要）：缺少进度报告
[分配修复子代理]
修复子代理：添加了每100次对话的进度
[验证修复，标记任务2完成]
...
[所有任务后]
[分配最终代码审查者]
最终审查者：所有要求满足，准备合并
完成！
优势
与手动执行相比：
- 子代理自然地遵循TDD
- 每个任务新上下文（无混淆）
- 并行安全（子代理不干扰）
与执行计划相比：
- 相同会话（无交接）
- 连续进展（无等待）
- 自动审查检查点
成本：
- 更多子代理调用
- 但早期发现问题（比后期调试更便宜）
红旗警告
绝不：
- 跳过任务间代码审查
- 继续存在未修复的关键问题
- 并行分配多个实现子代理（冲突）
- 不阅读计划任务就实现
如果子代理失败任务：
- 分配具有具体指令的修复子代理
- 不要尝试手动修复（上下文污染）
集成
必需的工作流技能：
- writing-plans - 必需：创建此技能执行的计划
- requesting-code-review - 必需：每个任务后审查（见步骤3）
- finishing-a-development-branch - 必需：所有任务后完成开发（见步骤7）
子代理必须使用：
- test-driven-development - 子代理为每个任务遵循TDD
替代工作流：
- executing-plans - 用于并行会话而不是相同会话执行
见代码审查者模板：requesting-code-review/code-reviewer.md