用途
Subagent-Driven Development（子智能体驱动开发）是一个编码工作流技能，用于在当前会话中执行实现计划。它的做法是：按任务逐个派发全新的子智能体，每个任务完成后进行两阶段审查——先做规范符合性（spec compliance）审查，再做代码质量（code quality）审查。
其出发点是：把任务委派给拥有隔离上下文的专用智能体；通过精确构造指令与上下文，确保子智能体保持专注并成功完成任务。子智能体不应继承主会话的上下文或历史，而是由主控方构造恰好所需的内容，从而也保留了主控方自身用于协调工作的上下文。
核心原则：每任务一个全新子智能体 + 两阶段审查（先规范、后质量）= 高质量、快速迭代。
何时使用
资料以流程判断图形式给出使用条件：
- 是否已有实现计划？没有则先手动执行或先做头脑风暴。
- 任务是否基本相互独立？若任务紧耦合，则先手动执行或头脑风暴。
- 是否留在当前会话中？是则使用本技能；若需并行会话，则改用 executing-plans。
与 Executing Plans（并行会话）相比，本技能的特点包括：同一会话（无上下文切换）、每任务全新子智能体（无上下文污染）、每任务两阶段审查（先规范符合性后代码质量）、迭代更快（任务之间无需人类介入）。
主要能力与流程
整体流程如下：
- 读取计划，提取所有任务的完整文本，记录上下文，创建 TodoWrite。
- 对每个任务：派发实现子智能体（./implementer-prompt.md）；若实现子智能体提问，则回答问题并提供上下文，然后重新派发；实现子智能体实现、测试、提交、自审。
- 派发规范审查子智能体（./spec-reviewer-prompt.md）；若代码与规范不符，实现子智能体修复规范缺口，然后重新审查。
- 规范符合后，派发代码质量审查子智能体（./code-quality-reviewer-prompt.md）；若发现问题，实现子智能体修复质量问题，然后重新审查。
- 审查通过后在 TodoWrite 中标记任务完成，继续下一个任务。
- 所有任务完成后，派发最终代码审查子智能体对整个实现做审查，最后使用 superpowers:finishing-a-development-branch 收尾。
模型选择
原则是：为每个角色使用能够胜任该角色的最弱模型，以节省成本并提高速度。
- 机械性实现任务（隔离函数、清晰规范、1-2 个文件）：使用快速、便宜的模型。计划足够明确时，多数实现任务都是机械性的。
- 集成与判断任务（多文件协调、模式匹配、调试）：使用标准模型。
- 架构、设计、审查任务：使用可用的最强模型。
任务复杂度信号：触及 1-2 个文件且规范完整 → 便宜模型；触及多文件且有集成关注点 → 标准模型；需要设计判断或对代码库的广泛理解 → 最强模型。
处理实现者状态
实现子智能体会报告四种状态之一，需分别处理：
- DONE：进入规范符合性审查。
- DONE_WITH_CONCERNS：实现者完成了工作但标记了疑虑。先阅读疑虑再继续。若疑虑涉及正确性或范围，先处理再审查；若只是观察（例如“这个文件越来越大”），记录后继续审查。
- NEEDS_CONTEXT：实现者需要未提供的信息。补充缺失上下文后重新派发。
- BLOCKED：实现者无法完成任务。评估阻塞原因：若是上下文问题，提供更多上下文，用同一模型重新派发；若任务需要更多推理，换用更强模型重新派发；若任务过大，拆分为更小的部分；若计划本身有误，升级给人类。
资料强调：绝不要忽略升级请求，也不要在没有变化的情况下强求同一模型重试。如果实现者表示卡住，就必须做出改变。
提示模板
- ./implementer-prompt.md：派发实现子智能体
- ./spec-reviewer-prompt.md：派发规范符合性审查子智能体
- ./code-quality-reviewer-prompt.md：派发代码质量审查子智能体
示例工作流
资料给出的示例：用户声明使用 Subagent-Driven Development 执行计划，读取一次计划文件（docs/superpowers/plans/feature-plan.md），提取全部 5 个任务的完整文本与上下文，创建 TodoWrite。
任务 1（Hook 安装脚本）：派发实现子智能体并附完整任务文本与上下文；实现者先问“hook 应安装在用户级还是系统级”，主控方回答“用户级（~/.config/superpowers/hooks/）”；实现者随后完成安装命令、添加测试（5/5 通过）、自审发现遗漏 --force 标志并补上、提交。派发规范符合性审查，审查者确认合规、无多余内容。获取 git SHA 后派发代码质量审查，审查者给出优点（测试覆盖好、整洁）、无问题、通过。标记任务 1 完成。
任务 2（恢复模式）：派发实现者，无需提问，实现 verify/repair 模式、8/8 测试通过、自审通过、提交。规范审查发现问题：缺失进度报告（规范要求“每 100 项报告一次”）、多加了未要求的 --json 标志。实现者移除 --json 标志并添加进度报告，规范审查再次通过。代码质量审查发现重要问题：魔法数字（100）。实现者提取 PROGRESS_INTERVAL 常量，代码审查再次通过。标记任务 2 完成。
所有任务完成后派发最终代码审查，最终审查者认为所有需求已满足、可以合并。
适用场景与优势
相对手动执行的优势：子智能体自然遵循 TDD；每任务全新上下文（无混淆）；并行安全（子智能体互不干扰）；子智能体可以提问（工作前和工作期间均可）。
相对 Executing Plans 的优势：同一会话（无需交接）；持续推进（无需等待）；审查检查点自动化。
效率收益：无需读取文件开销（主控方提供完整文本）；主控方精确整理所需上下文；子智能体预先获得完整信息；问题在工作开始前浮现（而非之后）。
质量门禁：自审在交接前捕获问题；两阶段审查（先规范符合性、后代码质量）；审查循环确保修复真正生效；规范符合性防止过度或不足实现；代码质量保证实现质量良好。
限制与代价
资料明确列出的代价：更多的子智能体调用（每任务一个实现者 + 两个审查者）；主控方需要做更多准备工作（预先提取所有任务）；审查循环增加迭代次数。但其价值在于能尽早发现问题（比后期调试更便宜）。
红旗与禁止事项
资料列出的“绝不”事项包括：未经用户明确同意，绝不在 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 — 用于并行会话而非同会话执行。
其他信息（如具体收费、价格、平台支持等）暂未提供。