subagent-driven-development

name	subagent-driven-development
description	当在当前会话中执行包含独立任务的实现计划时使用

子代理驱动开发

通过为每个任务分派一个全新的子代理来执行计划，每个任务完成后进行两阶段审查：先审查规格合规性，再审查代码质量。

为什么用子代理： 你将任务委派给具有隔离上下文的专用智能体。通过精心设计它们的指令和上下文，确保它们专注并成功完成任务。它们不应继承你的会话上下文——你要精确构造它们所需的一切。这样也能为你自己保留用于协调工作的上下文。

核心原则： 每个任务一个全新子代理 + 两阶段审查（先规格后质量）= 高质量、快速迭代

何时使用

使用条件：

1. 有实现计划
2. 任务基本独立
3. 留在当前会话（非并行会话）

不满足时：

• 无计划 → 先头脑风暴或手动执行
• 任务紧密耦合 → 手动执行或先头脑风暴
• 并行会话 → 使用 executing-plans

与 Executing Plans 的对比：

• 同一会话（无上下文切换）
• 每个任务全新子代理（无上下文污染）
• 每个任务后两阶段审查：先规格合规性，再代码质量
• 更快的迭代（任务间无需人工介入）

前置检查

开始执行前，先评估任务复杂度：

• 简单修复或添加（1–2 个文件、少量代码、无架构变更）：继续执行本技能，跳过 using-git-worktrees
• 其他情况：先调用 using-git-worktrees 建立隔离工作区，再继续本技能流程

流程

总体流程：

1. 使用 read_file(path="计划文件路径") 读取计划，提取所有任务的完整文本，记录上下文，创建待办清单
2. 对每个任务循环：
   • 分派实现子代理：run_skill(name="implement", arguments="完整任务文本 + 上下文")
   • 如有疑问，回答问题后重新分派
   • 实现完成后，分派规格审查子代理：run_skill(name="flow-review", arguments="审查以下实现是否匹配原始规格，检查有无遗漏需求或过度实现")
   • 如规格不通过，实现者修复后重新审查
   • 规格通过后，分派代码质量审查子代理：run_skill(name="flow-review", arguments="审查代码质量：命名、结构、重复、边界情况、测试覆盖")
   • 如质量不通过，实现者修复后重新审查
   • 通过后标记任务完成
3. 所有任务完成后，分派最终代码审查子代理：run_skill(name="flow-review", arguments="审查整体实现...")
4. 使用 finishing-a-development-branch 收尾

模型选择

使用能胜任每个角色的最低成本模型，以节省开支并提高速度。

任务类型	复杂度信号	模型选择
机械性实现	1-2 个文件，清晰规格	快速、便宜的模型
集成和判断	多文件协调，模式匹配，调试	标准模型
架构、设计和审查	需要设计判断或广泛代码库理解	最强的可用模型

处理实现者状态

实现子代理报告四种状态之一：

状态	含义	处理
DONE	完成	进入规格合规性审查
DONE_WITH_CONCERNS	完成但有疑虑	阅读疑虑。涉及正确性/范围的，审查前解决；观察性说明的，记录并继续
NEEDS_CONTEXT	需要未提供的信息	提供缺失上下文并重新分派
BLOCKED	无法完成	1) 上下文问题 → 提供更多上下文；2) 需更强推理 → 用更强模型；3) 任务太大 → 拆分；4) 计划有问题 → 上报人类

绝不 忽略上报或在不做任何更改的情况下让同一模型重试。如果实现者说卡住了，说明有什么东西需要改变。

子代理调用

• run_skill(name="implement", arguments="完整任务文本 + 上下文") — 分派实现子代理（执行代码修改、测试、提交）
• run_skill(name="flow-review", arguments="审查以下实现是否匹配原始规格，检查有无遗漏需求或过度实现") — 规格合规审查
• run_skill(name="flow-review", arguments="审查代码质量：命名、结构、重复、边界情况、测试覆盖") — 代码质量审查

优势

与手动执行相比：

• 子代理自然遵循 TDD
• 每个任务全新上下文（不会混淆）
• 并行安全（子代理不会互相干扰）
• 子代理可以提问

与 Executing Plans 相比：

• 同一会话（无交接）
• 持续进展（无需等待）
• 审查检查点自动化

质量关卡：

• 自审在交接前发现问题
• 两阶段审查确保规格合规和代码质量
• 审查循环确保修复确实有效
• 问题在工作开始前就被提出

成本： 更多子代理调用，但能及早发现问题（比后期调试更省成本）。

红线

绝不：

• 未经用户明确同意就在 main/master 分支上开始实现
• 跳过审查（规格合规性或代码质量）
• 带着未修复的问题继续
• 并行分派多个实现子代理（会冲突）
• 让子代理自己读取计划文件（应在主代理中使用 read_file(path="...") 读取后将完整文本提供给子代理）
• 跳过场景铺设上下文
• 忽视子代理的问题（在让它们继续之前先回答）
• 在规格合规性上接受"差不多就行"
• 跳过审查循环（审查者发现问题 → 实现者修复 → 再次审查）
• 让实现者的自审替代正式审查（两者都需要）
• 在规格合规性审查通过之前开始代码质量审查
• 在任一审查有未解决问题时就进入下一个任务

如果子代理提问： 清晰完整地回答，必要时提供额外上下文，不要催促它们进入实现阶段。

如果审查者发现问题： 实现者（同一子代理）修复 → 审查者再次审查 → 重复直到通过。不要跳过重新审查。

如果子代理失败： 分派修复子代理并提供具体指令，不要尝试手动修复（上下文污染）。

集成

必需的工作流技能：

• writing-plans - 创建本技能执行的计划
• requesting-code-review - 审查子代理的代码审查模板
• finishing-a-development-branch - 所有任务完成后收尾

条件工作流技能：

• using-git-worktrees - 非简单任务时，在开始前建立隔离工作区（见前置检查）

子代理应使用：

• test-driven-development - 子代理对每个任务遵循 TDD

替代工作流：

• executing-plans - 用于并行会话而非同会话执行