用途
Subagent-Driven Development 用于在当前会话中执行实现计划（implementation plan）。它通过为每个任务派发一个全新的子代理来执行，并在每个任务完成后进行两阶段审查：先做规格符合性审查（spec compliance review），再做代码质量审查（code quality review）。
核心原则：每个任务使用全新子代理 + 两阶段审查（先规格后质量）= 高质量、快速迭代。
何时使用
根据资料中的决策流程：
- 是否已有实现计划？没有则先手动执行或先做头脑风暴。
- 任务是否大多相互独立？若任务紧密耦合，则先手动执行或先做头脑风暴。
- 是否留在当前会话？是则使用 subagent-driven-development；否则（并行会话）使用 executing-plans。
与 Executing Plans（并行会话）相比，本技能的特点：
- 同一会话（无上下文切换）
- 每个任务使用全新子代理（无上下文污染）
- 每个任务后两阶段审查：先规格符合性，再代码质量
- 迭代更快（任务之间无需人工介入）
主要能力与流程
整体流程如下：
- 读取计划，提取所有任务全文，记录上下文，创建 TodoWrite。
- 对每个任务：
- 派发实现者子代理（./implementer-prompt.md）。
- 若实现者子代理提问，则回答问题并提供上下文，然后重新派发。
- 实现者子代理实现、测试、提交、自审。
- 派发规格审查者子代理（./spec-reviewer-prompt.md）。
- 若规格审查者确认代码符合规格，则进入下一步；否则实现者子代理修复规格缺口，并重新审查。
- 派发代码质量审查者子代理（./code-quality-reviewer-prompt.md）。
- 若代码质量审查者批准，则在 TodoWrite 中标记任务完成；否则实现者子代理修复质量问题，并重新审查。
- 若还有任务，重复上述步骤。
- 所有任务完成后，派发最终代码审查者子代理审查整个实现。
- 使用 superpowers:finishing-a-development-branch 完成开发分支。
提示模板
- ./implementer-prompt.md - 派发实现者子代理
- ./spec-reviewer-prompt.md - 派发规格符合性审查者子代理
- ./code-quality-reviewer-prompt.md - 派发代码质量审查者子代理
使用方式示例
资料给出的示例工作流：
- 读取计划文件一次：docs/plans/feature-plan.md
- 提取全部 5 个任务及其全文和上下文
- 创建包含所有任务的 TodoWrite
任务 1：Hook 安装脚本
- 获取任务 1 文本和上下文（已提取）
- 派发实现子代理，附带完整任务文本 + 上下文
- 实现者提问：「开始之前——hook 应安装在用户级还是系统级？」
- 回答：「用户级（~/.config/superpowers/hooks/）」
- 实现者实现 install-hook 命令，添加测试 5/5 通过，自审发现遗漏 --force 标志并补充，提交
- 派发规格符合性审查者，审查者确认符合规格
- 获取 git SHA，派发代码质量审查者，审查者批准
- 标记任务 1 完成
任务 2：恢复模式
- 派发实现子代理，实现者添加 verify/repair 模式，8/8 测试通过，自审通过，提交
- 派发规格符合性审查者，审查者发现问题：缺少进度报告（规格要求「每 100 项报告一次」），且多加了 --json 标志（未要求）
- 实现者修复：移除 --json 标志，添加进度报告
- 规格审查者再次审查，确认符合规格
- 派发代码质量审查者，审查者指出重要问题：魔法数字（100）
- 实现者修复：提取 PROGRESS_INTERVAL 常量
- 代码审查者再次审查，批准
- 标记任务 2 完成
所有任务完成后，派发最终代码审查者，确认所有需求满足，可合并。
优势
相比手动执行：
- 子代理自然遵循 TDD
- 每个任务全新上下文（无混淆）
- 并行安全（子代理互不干扰）
- 子代理可以提问（工作前和工作期间均可）
相比 Executing Plans：
- 同一会话（无交接）
- 持续进展（无需等待）
- 审查检查点自动化
效率提升：
- 无文件读取开销（控制器提供全文）
- 控制器精确筛选所需上下文
- 子代理预先获得完整信息
- 问题在工作开始前浮现（而非之后）
质量门禁：
- 自审在交接前发现问题
- 两阶段审查：先规格符合性，再代码质量
- 审查循环确保修复真正生效
- 规格符合性防止过度/不足构建
- 代码质量确保实现构建良好
成本：
- 更多子代理调用（每个任务：实现者 + 2 个审查者）
- 控制器做更多准备工作（预先提取所有任务）
- 审查循环增加迭代
- 但能尽早发现问题（比后期调试更便宜）
限制与红线
资料明确列出「绝不」事项：
- 未经用户明确同意，绝不在 main/master 分支上开始实现
- 绝不跳过审查（规格符合性或代码质量）
- 绝不带着未修复的问题继续
- 绝不并行派发多个实现子代理（会冲突）
- 绝不让子代理读取计划文件（应提供全文）
- 绝不跳过场景设定上下文（子代理需要理解任务所处位置）
- 绝不忽略子代理的提问（先回答再让其继续）
- 绝不在规格符合性上接受「差不多」（规格审查者发现问题 = 未完成）
- 绝不跳过审查循环（审查者发现问题 = 实现者修复 = 再次审查）
- 绝不让实现者自审替代实际审查（两者都需要）
- 绝不在规格符合性通过前开始代码质量审查（顺序错误）
- 绝不在任一审查存在未解决问题时进入下一任务
若子代理提问：清晰完整地回答，必要时提供额外上下文，不要催促其进入实现。
若审查者发现问题：由同一实现者子代理修复，审查者再次审查，重复直到批准，不要跳过复审。
若子代理任务失败：派发修复子代理并给出具体指令，不要尝试手动修复（会污染上下文）。
集成
必需的工作流技能：
- superpowers:using-git-worktrees - 必需：开始前设置隔离工作区
- superpowers:writing-plans - 创建本技能所执行的计划
- superpowers:requesting-code-review - 审查者子代理的代码审查模板
- superpowers:finishing-a-development-branch - 所有任务完成后完成开发
子代理应使用：
- superpowers:test-driven-development - 子代理为每个任务遵循 TDD
替代工作流：
- superpowers:executing-plans - 用于并行会话而非同会话执行