核心用法
Subagent-Driven Development 是一种在同一会话内执行独立任务的开发工作流。其核心机制为：每个任务派遣全新子代理 + 双阶段审查（规格合规优先，代码质量次之）。
操作流程分为三个阶段：
1. 准备阶段：一次性读取计划文件，提取所有任务完整文本与上下文，创建 TodoWrite 清单
2. 单任务循环：
3. 收尾阶段：所有任务完成后，派遣最终代码审查子代理，通过后使用 finishing-a-development-branch 技能完成
- 派遣实现子代理（./implementer-prompt.md），支持前置问答环节
- 子代理完成实现、测试、提交、自评
- 阶段一：派遣规格审查子代理，确认代码完全符合需求规格
- 阶段二：派遣代码质量审查子代理，评估代码质量与最佳实践
- 任一阶段发现问题，由原实现子代理修复后重新审查
显著优点
- 上下文纯净：每个子代理独立启动，避免任务间上下文污染
- 缺陷早发现：双阶段审查机制在任务级别拦截规格偏差与代码质量问题
- 并行安全：串行执行设计避免多实现子代理冲突
- 成本可控：问题在任务级解决，远早于集成后调试的修复成本
- 流程标准化：强制审查节点消除"差不多就行"的主观判断
潜在局限
- 子代理调用成本高：每个任务需 3 次子代理调用（实现+双审查），复杂任务可能因审查循环进一步增加
- 前置工作量大：控制器需一次性提取所有任务文本与上下文
- 串行效率瓶颈：禁止并行派遣实现子代理，大规模任务集执行时间较长
- 依赖计划质量：计划本身缺陷无法通过此技能弥补
- 学习曲线陡峭：双阶段审查顺序、循环机制等规则需严格遵守
适合人群
- 需要高质量交付的中大型功能开发
- 已有清晰计划文档的独立任务集
- 追求代码可维护性的团队场景
- 愿意权衡成本换质量的关键路径功能
不适合：快速原型验证、计划模糊、成本敏感或追求极致速度的场景。
常规风险
| 风险点 | 说明 |
|--------|------|
| 审查顺序错误 | 必须先规格后质量，颠倒会导致无效返工 |
| 跳过重新审查 | 修复后必须让原审查子代理再审，不可直接通过 |
| 子代理自评替代 | 子代理自评与独立审查缺一不可 |
| 并行派遣实现 | 会导致代码冲突，必须严格串行 |
| 未回答子代理问题 | 强行推进将引入理解偏差 |
| 忽视"close enough" | 规格审查发现问题即视为未完成 |
安全提示：本技能为流程编排型技能，本身不直接执行代码，但子代理可能生成并执行代码，需确保执行环境可信。