subagent-driven-development 的核心是：为实施计划中的每个独立任务，派发一个上下文干净的全新子代理来完成。任务完成后，必须先通过“规格合规审查”（确认是否按需求实现），再通过“代码质量审查”（确认代码质量是否过关），两道关卡都通过才算完成。这种模式能有效避免长会话中的上下文污染，确保 AI 连续执行多任务时不“跑偏”。
subagent-driven-development 详解：每个任务一个子代理，两阶段审查
让 AI 代理连续执行一个复杂的实施计划时，一个常见痛点是：会话越长，代理的“记忆”越混乱。它可能把前一个任务的代码风格、命名习惯甚至错误逻辑带入后续任务，或者悄悄“顺手”添加计划外的功能。subagent-driven-development 技能通过严格的隔离和审查机制，专门解决这个问题。在开始执行前，请确保你已经使用 using-superpowers 技能加载了相关技能，并且通过 brainstorming 和 writing-plans 技能产出了一份清晰的实施计划。你可以将本技能视为计划执行的“调度中枢”，它与 executing-plans 技能功能互补，后者适用于并行会话场景。
核心机制：三个角色与两道质量门禁
整个工作流围绕三类子代理协作展开，每类子代理职责分明，且由主控代理（即你在对话中操控的 AI）精确调度。
1. 实现代理 (Implementer)
它的任务是接收单个任务的完整描述，在一个全新的、隔离的会话上下文中完成编码、测试和提交。其提示模板 (implementer-prompt.md) 明确要求它在开工前必须提问以澄清任何疑点，并在完成后进行严格的自我审查（检查完整性、质量、纪律和测试），然后按 DONE、DONE_WITH_CONCERNS、BLOCKED 或 NEEDS_CONTEXT 格式汇报状态。
2. 规格审查代理 (Spec Reviewer) 它不轻信实现代理的报告。核心指令是“Do Not Trust the Report”，要求它独立阅读代码，将实际实现与原始规格逐条对照。它的目标是回答一个简单问题：代理是否准确地实现了需求，不多也不少？任何偏差都必须被指出，直到修复后重新审查通过。
3. 代码质量审查代理 (Code Quality Reviewer)
只有在规格审查通过后，它才会介入。它使用统一的 code-reviewer.md 模板，结合任务计划，对本次变更进行深度审查：关注代码的可读性、可测试性、文件职责是否清晰、是否遵循现有代码库模式、是否遵循 DRY 原则等。问题同样需要修复并循环审查直至通过。
两道审查的顺序至关重要：先确认“做了正确的事”（规格合规），再确认“事情做得正确”（代码质量）。这个顺序颠倒不得。
完整执行流程详解
SKILL.md 中的流程图清晰地展示了这个闭环。以下是分步解读：
第一阶段：准备与任务派发
- 读取计划，一次性提取所有任务：主控代理读取实施计划文件一次，提取所有任务的完整文本和上下文，并创建 TodoWrite 任务列表。这是效率关键点——子代理永远不需要自己去读计划文件，避免了信息获取不全或偏差。
- 派发实现代理：按顺序，将完整的任务描述 + 上下文传给一个全新的实现代理。
- 处理实现代理反馈：
DONE：进入审查。DONE_WITH_CONCERNS：主控代理需评估其顾虑，再决定是否进入审查。NEEDS_CONTEXT：主控代理补充缺失信息后重新派发。BLOCKED：主控代理诊断原因（上下文不足？任务太难？模型能力？计划有误？），并采取相应措施（补充信息、换更强模型、拆分任务或上报），绝不能在不作任何改变的情况下强制同一模型重试。
第二阶段：双阶段审查循环
4. 规格合规审查：派发规格审查代理。它阅读代码后，报告是否✅ Spec compliant 或 ❌ Issues found。若发现问题，实现代理（或由主控代理指派的新修复代理）必须修复，然后再次审查，此循环直到通过。
5. 代码质量审查：规格通过后，派发代码质量审查代理。它基于 code-reviewer.md 模板，结合任务计划，对本次变更进行深度审查。同样，任何问题必须修复并循环直至通过。
6. 标记完成：两道审查均通过后，在 TodoWrite 中将该任务标记为完成，然后开始下一个任务。
7. 最终总览：所有任务完成后，可派发一个最终的代码审查代理，对整个实现做一次全景审查，然后使用 finishing-a-development-branch 技能收尾。
模型选择与成本优化策略
不是每个任务都需要最强的模型。根据任务复杂度选择模型能显著节省成本和时间：
- 机械性实现任务（例如：在
src/math.js中新增一个multiply函数，规格清晰，涉及1-2个文件）：使用快速、廉价的模型。当计划足够细致时，大部分实现任务属于此类。 - 集成与判断任务（例如：涉及多个文件协调、模式匹配或调试）：使用标准模型。
- 架构、设计与审查任务（例如：需要全局理解代码库的代码质量审查）：使用能力最强的模型。
任务复杂度的信号包括：触及文件的数量、是否需要集成判断、是否需要设计决策等。
何时使用？与其它方式的区别
根据 SKILL.md 中的“When to Use”决策图，选择此技能需满足三个条件：
- 你已有一份完整的实施计划。
- 计划中的任务大致相互独立。
- 你希望在当前会话内连续执行，无需切换上下文。
如果任务间高度耦合，或者你还未形成完整计划，应先使用 brainstorming 或 writing-plans 技能。如果需要在多个并行会话中执行不同任务，那么 executing-plans 技能可能更合适。
与手动执行相比，subagent-driven-development 的优势在于：子代理天然遵循 TDD、上下文隔离避免混淆、子代理可以在开工前提问以澄清需求。与 executing-plans 相比，它的优势在于同一会话内连续执行、无需人工介入每个任务检查点、并自动完成双阶段审查。
行为验证：测试脚本如何保证流程正确
SuperPowers 的测试体系为这套工作流提供了行为验证。以 test-subagent-driven-development.sh 脚本为例，它通过让 Claude Code 描述技能行为，验证其理解是否符合预期，例如断言代理能识别“读取计划”、“规格合规出现在代码质量之前”、“自我审查”、“一次读取计划”、“审查者不信任报告”以及“审查循环”等核心概念。
而 test-subagent-driven-development-integration.sh 则进行更慢但更真实的端到端测试。它创建一个包含两个任务的微型项目，并实际执行该技能，随后验证诸如“子代理是否被派发”、“TodoWrite是否被用于追踪”、“最终实现是否功能正确且测试通过”等具体行为。这证明了技能在真实场景下按设计工作。
关键注意事项与红线
几条绝不能违反的规则，源自 SKILL.md 的“Red Flags”部分：
- 不要在 main/master 分支上开工：必须先使用
using-git-worktrees技能创建隔离的工作区。 - 不能跳过任何审查：规格合规审查和代码质量审查必须依次进行，且审查循环必须执行到通过。
- 不能并行派发多个实现代理：会产生代码冲突，只能串行执行。
- 不要让子代理自己去读计划文件：必须由主控代理提取完整文本提供。
- 不要忽视子代理的问题：必须在实现代理开始工作前回答清楚。
- 不要接受“差不多就行”：规格审查发现问题就等于没完成，必须修复。
- 实现代理的自我审查不能替代正式审查：两者都是必要的质量环节。
FAQ
Q: 实现代理报告 BLOCKED 了，我该怎么办？ A: 首先诊断原因。如果是上下文不足，就补充信息后重新派发。如果任务本身需要更强的推理能力，就换用更强大的模型重新派发。如果任务太大，就将其拆分成更小的部分。如果是原始计划本身有误，则需要上报给人类决策，而不是强行重试。
Q: 两阶段审查听起来开销很大，值得吗？ A: 绝对值得。在单个任务完成后立刻发现并修复问题，其成本远低于所有任务做完后再进行大规模返工。审查代理本身速度很快，且能防止因规格偏差或质量低下导致的后期高昂调试成本。
Q: 计划要写到什么细度才适合使用这个技能？ A: 计划中的每个任务描述必须足够完整，实现代理拿到后无需猜测意图。例如，“实现登录功能”这样的描述太模糊，应该细化为具体的文件、函数名、输入输出和验收标准。一份好的计划是成功的一半。
Q: 它和 test-driven-development 技能是什么关系？
A: 实现代理在执行任务时，应遵循 test-driven-development 技能的要求，先写失败测试再实现功能。因此，TDD 是子代理在其单个任务内应遵守的开发纪律，而 subagent-driven-development 则是管理多个任务执行和审查的顶层工作流。
Q: 为什么审查顺序不能颠倒？ A: 如果先审查代码质量，可能会出现一个情况：代码写得非常漂亮、符合各种最佳实践，但它根本没有实现正确的需求，或者多实现了一堆无用功能。此时再进行规格审查，之前为代码质量所做的工作可能需要全部推倒重来。先确保方向正确，再打磨质量，是更高效的策略。