name: 子代理驱动开发 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. 完成开发
最终审查通过后：
- 宣布：“我正在使用 finishing-a-development-branch 技能来完成这项工作。”
- 必需子技能： 使用超能力:finishing-a-development-branch
- 遵循该技能验证测试，呈现选项，执行选择
示例工作流程
您：我正在使用子代理驱动开发来执行此计划。
[加载计划，创建TodoWrite]
任务1：钩子安装脚本
[分发实施子代理]
子代理：实施了安装钩子，测试5/5通过
[获取git SHAs，分发代码审查者]
审查者：优点：测试覆盖良好。问题：无。准备就绪。
[标记任务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