| name | subagent-driven-development |
| description | Use when 已有书面实施计划、任务相对独立，且在本会话内通过子代理逐任务落实时。触发场景：执行实施计划、子代理开发、按计划实现、Task 派发实现、两阶段代码审查、plan execution。 |
子代理驱动开发
按书面实施计划逐任务推进：每个任务派发新的实现子代理（隔离上下文），任务完成后依次做 规格符合性审查 → 代码质量审查（顺序不可颠倒）。主会话负责读计划一次、提取任务全文、协调与决策，不把整段对话历史灌给子代理。
开场声明：「我正在使用子代理驱动开发技能执行计划。」
与「同会话逐步执行」的区别： 本技能强调每任务新子代理 + 双审查；若用户选择在当前会话手写每一步、不用 Task 派子代理，可改按 references/inline-execution-hint.md 配合 tdd-master（TDD 开发大师） 与 code-review-expert（代码审查专家），不再套用下文的 Task 模板。
Inputs / Outputs / Gates / Handoffs（统一契约）
- Inputs（最小输入）：一份书面实施计划（必须包含任务全文：步骤、代码块、命令、预期输出）；当前分支/工作目录信息。
- Outputs（产物形态）：按任务推进的执行记录（主会话 Todo 勾选）+ 每任务的 3 段产物：实现结果、规格符合性审查、代码质量审查。
- Gates（继续前必须满足）：
- 不允许子代理自行打开计划文件代替你粘贴任务全文（除非平台强制且无法粘贴，并需说明风险）。
- 审查顺序硬门控：先规格符合性审查 → 后代码质量审查。
- 发现阻塞问题必须回到实现修复并复审，通过后才进入下一任务。
- Handoffs（推荐下游）：
code-review-expert（代码审查专家）：整体收尾审查/质量门禁debug-expert（调试专家）：实现或测试失败时切换排查
适用条件
- 已有实施计划（推荐由
writing-plans（实施计划编写） 产出），任务粒度小、相对独立。
- 平台支持 Task / 子代理 等派发能力；若不支持，改用同会话执行提示文件。
flowchart TD
A[有实施计划?] -->|否| Z[先完成方案设计与实施计划编写]
A -->|是| B[任务可独立切片?]
B -->|否| Y[收紧计划或改人工串行]
B -->|是| C[本技能: 子代理逐任务]
总流程
- 读计划一次，提取全部任务标题与完整任务正文（含步骤、代码块、命令），不要让子代理自己去读计划文件。
- 用 TodoWrite（或等价方式）列出所有任务，随进度更新。
- 对每个任务循环：
- 派发 实现子代理（
references/implementer-prompt.md）
- 根据返回状态处理（见下节「实现者状态」）
- 通过后派发 规格符合性审查（
references/spec-reviewer-prompt.md）
- 规格 ✅ 后派发 代码质量审查（
references/code-quality-reviewer-prompt.md，对齐 code-review-expert（代码审查专家） 的严重度与证据要求）
- 两道审查均未决问题后，勾选任务完成
- 全部任务完成后：建议对整体变更再做一次
code-review-expert（代码审查专家） 级别的汇总审查（可再派子代理），并请用户确认合并/PR；若项目后续提供「分支收尾」类技能可再衔接。
实现者状态处理
实现子代理须返回以下之一：
| 状态 | 处理 |
|---|
| DONE | 进入规格符合性审查 |
| DONE_WITH_CONCERNS | 先阅读关切；涉及正确性/范围的先处理再审查；仅为观察性备注可记录后继续 |
| NEEDS_CONTEXT | 补充上下文后重新派发同一任务 |
| BLOCKED | 缺信息则补上下文；能力不足则换更强模型；任务过大则拆计划；计划错误则上升用户 |
禁止忽视 BLOCKED、禁止无变更重复派发同模型硬重试。
模型选用（节省成本）
- 机械实现（1–2 文件、规格完整）：较快、较省模型。
- 多文件集成与判断：标准能力模型。
- 架构与审查：在可用范围内选最强模型。
提示词模板（必读路径）
| 文件 | 用途 |
|---|
references/implementer-prompt.md | 实现子代理 |
references/spec-reviewer-prompt.md | 规格符合性审查（先） |
references/code-quality-reviewer-prompt.md | 代码质量审查（后） |
派发时将计划中的任务全文粘贴进提示词，并补充场景上下文（依赖、架构位置、工作目录）。
红线（禁止）
- 未经用户明确同意在
main/master 上开始改代码。
- 跳过任一审查，或先代码质量、后规格符合（顺序错误）。
- 并行派发多个实现子代理处理同一仓库同一分支（易冲突）。
- 让子代理自行打开计划文件代替你粘贴任务全文（除非平台强制且无法粘贴，此时应最小化摘录并说明风险）。
- 审查发现问题后不修复、不复审就进入下一任务。
- 用实现者自述替代审查员的独立读码验证。
与项目内技能的衔接
| 技能 | 作用 |
|---|
writing-plans（实施计划编写） | 产生本技能消费的勾选式计划 |
tdd-master（TDD 开发大师） | 实现与运行测试时应遵循 RED-GREEN-REFACTOR；计划中已拆步骤时以计划为准 |
code-review-expert（代码审查专家） | 代码质量审查输出结构与严重度对齐；全量收尾可再显式调用 |
debug-expert（调试专家） | 实现或测试失败时切换排查 |
示例（缩写）
[读取计划 docs/specs/plans/xxx.md，提取任务 1–N 全文，写入 Todo]
任务 1：
→ Task: implementer（全文任务 + 上下文）
→ 实现者 DONE
→ Task: spec reviewer → ✅
→ Task: code quality reviewer → 有 Important 问题 → 实现者修复 → 再审 → ✅
→ 标记任务 1 完成
任务 2：…
全部完成后 → 可选：Task 最终审查 → 用户确认合并
