subagent-driven-development

核心用法

Subagent-Driven Development 是一种基于 Claude 子代理系统的结构化开发工作流，专为执行已制定好的实施计划而设计。其核心机制是"每个任务分配全新子代理 + 双阶段审查"：首先由实现者子代理（implementer）完成任务开发、测试与自审，随后依次触发规格审查子代理（spec reviewer）和代码质量审查子代理（code quality reviewer）进行把关，全部通过后才标记任务完成并进入下一任务。

该工作流强调"同会话执行"——与并行会话的 executing-plans 技能不同，它保持在当前 Claude 会话中连续推进，避免上下文切换开销。控制器（主代理）需一次性读取完整计划、提取所有任务文本与上下文、创建 TodoWrite 清单，随后按序调度，每个子代理获得完整的任务描述和场景信息，可在开工前提问澄清。

显著优点

质量保障体系完善：双阶段审查形成双重保险——规格审查确保"做对的事"（防止过度开发或遗漏需求），代码质量审查确保"把事做对"（代码规范、可维护性）。审查不通过时强制进入修复-重审循环，杜绝"差不多就行"。

上下文管理优化：每个任务使用全新子代理，彻底避免任务间上下文污染；控制器精准策展所需信息，子代理无需反复读取文件，获得完整 upfront 信息；问题在开工前暴露，减少返工成本。

天然契合 TDD：子代理被设计为遵循测试驱动开发，自动完成实现、测试、提交、自审流程，降低人工监督负担。

并行安全性：虽然禁止同一时刻分派多个实现子代理（防止代码冲突），但审查子代理与实现子代理可形成流水线，提升吞吐效率。

潜在缺点与局限性

成本开销显著：每个任务消耗 3 次子代理调用（实现者 + 2 审查者），加上审查循环的重复调用，以及控制器前期提取任务的一次性投入，token 消耗高于简单执行模式。

适用场景受限：仅适合"任务相对独立"且"计划已完备"的场景。高度耦合的任务、需求模糊的早期探索阶段、或需要频繁人工决策的创意工作均不适用。

决策图复杂度：何时选用本技能 vs. executing-plans vs. 手动执行，需要理解三张决策节点的流程图，对新手有一定认知负担。

审查质量依赖提示词：spec-reviewer 和 code-quality-reviewer 的具体判断标准由配套 prompt 模板定义，若模板设计不当，可能出现审查流于形式或标准过严导致频繁返工。

适合的目标群体

• 中大型功能开发：有明确 PRD/技术方案、可拆解为 3-10 个独立任务的特性开发
• 代码重构与迁移：模块间边界清晰、可逐文件/逐模块推进的重构工作
• 测试覆盖补全：为现有代码库批量补充单元测试、集成测试
• 规范化代码审查：团队希望建立统一的代码质量标准，减少人工审查的主观波动
• 异步协作场景：开发者希望启动任务后去做其他事，让子代理自主推进并等待审查结果

不适合：紧急热修复（流程过重）、架构探索（需求不稳定）、需要频繁业务决策的 UI/UX 开发。

使用风险

子代理执行风险：虽然本 skill 本身无代码执行，但其调度的 implementer 子代理会实际读写文件、执行测试、运行 git 命令。建议在版本控制环境下使用，确保可回滚。

审查顺序错误：若跳过 spec 审查直接进行代码质量审查，或未完成修复就进入下一任务，将破坏质量保障体系。必须严格遵循"实现 → 规格审查 → 代码质量审查 → 下一任务"的顺序。

并行冲突风险：违反 Red Flags 并行分派多个实现子代理，可能导致同一文件被并发修改、git 冲突、测试状态混乱。

上下文裁剪过度：控制器若提取任务时遗漏关键上下文，子代理可能基于不完整信息做出错误实现，而规格审查可能无法发现"未被告知的需求"。

提示词模板漂移：若用户修改了 implementer-prompt.md 等模板但未同步调整审查标准，可能导致审查子代理与实现子代理预期不一致，陷入反复修复循环。