--- 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 / 子代理** 等派发能力;若不支持,改用同会话执行提示文件。 ```mermaid flowchart TD A[有实施计划?] -->|否| Z[先完成方案设计与实施计划编写] A -->|是| B[任务可独立切片?] B -->|否| Y[收紧计划或改人工串行] B -->|是| C[本技能: 子代理逐任务] ``` --- ## 总流程 1. **读计划一次**,提取全部任务标题与**完整任务正文**(含步骤、代码块、命令),**不要让子代理自己去读计划文件**。 2. 用 TodoWrite(或等价方式)列出所有任务,随进度更新。 3. **对每个任务**循环: - 派发 **实现子代理**(`references/implementer-prompt.md`) - 根据返回状态处理(见下节「实现者状态」) - 通过后派发 **规格符合性审查**(`references/spec-reviewer-prompt.md`) - 规格 ✅ 后派发 **代码质量审查**(`references/code-quality-reviewer-prompt.md`,对齐 `code-review-expert(代码审查专家)` 的严重度与证据要求) - 两道审查均未决问题后,勾选任务完成 4. **全部任务完成后**:建议对整体变更再做一次 `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 最终审查 → 用户确认合并 ```