Subagent Driven Development

核心机制

子代理驱动开发（Subagent-Driven Development） 是一种将复杂开发计划拆解为独立任务、通过专用子代理逐一执行的工程管理方法。其核心设计遵循「Fresh Subagent Per Task + Two-Stage Review」原则——每个任务启用全新子代理避免上下文污染，完成后依次经过规格合规审查和代码质量审查两道关卡。

执行流程

1. 前置准备：读取完整计划文件，提取所有任务文本及关联上下文，创建 TodoWrite 追踪表
2. 单任务循环：

3. 收尾阶段：全量任务完成后派遣最终代码审查，转入 superpowers:finishing-a-development-branch 完成合并

• 派遣实现子代理（./implementer-prompt.md），支持前置提问澄清需求
• 实现完成后自测、提交、自审
• 第一阶段：派遣规格审查子代理，确认代码严格匹配需求文档（禁止过度/不足实现）
• 第二阶段：派遣代码质量审查子代理，评估设计、可维护性、测试覆盖
• 任一阶段发现问题即退回修复并重新审查

显著优势

• 质量门禁：双阶段审查确保「做对的事」且「把事情做对」
• 上下文隔离：每任务新子代理消除累积混淆，支持子代理主动提问澄清
• 效率优化：控制器一次性提取完整任务文本，避免子代理重复文件IO
• TDD 内置：子代理天然遵循测试驱动开发

局限与风险

• 成本敏感：每任务触发 3 次子代理调用（实现+2审查），审查循环进一步增加开销
• 串行依赖：禁止并行派遣多个实现子代理（避免冲突），严格顺序执行
• 前置要求：必须配合 superpowers:using-git-worktrees 隔离工作区，禁止直接在 main/master 分支操作
• 审查顺序强制：规格审查未通过前严禁进入代码质量审查

适用场景

• 已有详细实施计划且任务间相对独立
• 追求代码质量优先于交付速度
• 单会话内完成（对比 executing-plans 的跨会话并行模式）
• 开发者愿意承担更高 API 调用成本换取早期缺陷拦截

关键禁忌

计划明确列出 12 条「Never」红线，核心包括：禁止跳过任一审查阶段、禁止审查发现问题后直接推进下一任务、禁止子代理自审替代独立审查、禁止忽视子代理前置提问。

核心机制

Subagent-Driven Development 是一种基于子代理分工的软件开发工作流，核心设计为每个任务启用全新子代理 + 双阶段强制审查。该模式解决传统单会话开发中上下文累积导致的决策疲劳、规格偏离和代码质量问题。

运作流程：主控 Agent 一次性解析完整计划并创建任务清单 → 按序为每个任务派遣独立实现子代理（携带完整任务文本和上下文）→ 实现完成后先后触发规约合规审查（验证是否严格匹配需求，禁止过度/不足实现）和代码质量审查（评估可读性、测试覆盖、架构合理性）→ 任一审查未通过则循环修复直至通过 → 最终全局审查后完成分支。

显著优势：① 零上下文污染——每个子代理从零开始，避免历史决策干扰；② 质量 gates 自动化——双审查机制在任务层级拦截缺陷，修复成本远低于集成阶段；③ 并行安全性——严格串行调度避免子代理冲突；④ 问题前置——实现前问答环节消除需求歧义。

关键局限：子代理调用次数显著增加（每任务 3 次起）、主控需承担更多前置解析工作、审查循环可能增加迭代耗时。此外，该模式假设任务间高度独立，强耦合任务需先解耦或改用其他模式。

适用人群：追求代码质量优先于交付速度的中大型项目开发者、需要严格执行规约的合规敏感型项目、以及希望减少人工审查负担的技术团队。

常规风险：① 未严格遵循审查顺序（如跳过规约审查直接代码审查）会导致质量目标错位；② 并行派遣多个实现子代理将引发代码冲突；③ 忽视子代理前置提问可能引入实现偏差。需配合 Git 工作树隔离和 TDD 子技能以最大化收益。