Menu
当在当前会话中执行具有独立任务的实现计划时使用
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
在进行任何创造性工作之前，你必须使用此 skill - 创建功能、构建组件、添加功能或修改行为。在实现之前探索用户意图、需求和设计。
当面对 2 个以上可在无共享状态或顺序依赖下处理的独立任务时使用
当你有一个书面实现计划，需要在带有 review 检查点的独立会话中执行时使用
当实现完成、所有测试通过、且你需要决定如何集成工作时使用 - 通过为合并、PR 或清理呈现结构化选项来指导开发工作的完成
当收到代码审查反馈时使用，在实现建议之前，尤其是当反馈看似不清或在技术上存疑时 - 需要技术严谨性和验证，而非表演性附和或盲目实现
当完成任务、实现主要功能或合并之前使用，以验证工作满足需求
| name | subagent-driven-development |
| description | 当在当前会话中执行具有独立任务的实现计划时使用 |
通过为每个任务派发一个全新的 implementer subagent 来执行计划，每个任务之后进行一次 task review（规范合规 + 代码质量），并在最后进行一次覆盖整个分支的 broad review。
为什么用 subagent： 你把任务委托给拥有隔离上下文的专门 agent。通过精确构建它们的指令和上下文，你确保它们保持专注并成功完成各自的任务。它们绝不应该继承你会话的上下文或历史——你精确构造它们所需的内容。这也为你自己的协调工作保留了上下文。
核心原则： 每个任务一个全新 subagent + task review（规范 + 质量）+ 最后的 broad review = 高质量、快速迭代
叙述（Narration）： 在工具调用之间，至多用一行简短叙述——ledger 和工具结果承载记录。
持续执行： 不要在任务之间暂停向你的 human partner 请示。不停顿地执行计划中的所有任务。停止的唯一理由是：你无法解决的 BLOCKED 状态、确实阻碍推进的歧义，或所有任务完成。"我是否继续？"这类提示和进度汇报是在浪费他们的时间——他们让你执行计划，那就执行。
digraph when_to_use {
"有实现计划？" [shape=diamond];
"任务大多独立？" [shape=diamond];
"留在当前会话？" [shape=diamond];
"subagent-driven-development" [shape=box];
"executing-plans" [shape=box];
"手动执行或先 brainstorm" [shape=box];
"有实现计划？" -> "任务大多独立？" [label="是"];
"有实现计划？" -> "手动执行或先 brainstorm" [label="否"];
"任务大多独立？" -> "留在当前会话？" [label="是"];
"任务大多独立？" -> "手动执行或先 brainstorm" [label="否 - 强耦合"];
"留在当前会话？" -> "subagent-driven-development" [label="是"];
"留在当前会话？" -> "executing-plans" [label="否 - 并行会话"];
}
对比 Executing Plans（并行会话）：
digraph process {
rankdir=TB;
subgraph cluster_per_task {
label="每个任务";
"派发 implementer subagent（./implementer-prompt.md）" [shape=box];
"Implementer subagent 提问？" [shape=diamond];
"回答问题，提供上下文" [shape=box];
"Implementer subagent 实现、测试、提交、自审" [shape=box];
"写 diff 文件，派发 task reviewer subagent（./task-reviewer-prompt.md）" [shape=box];
"Task reviewer 报告规范 ✅ 且质量通过？" [shape=diamond];
"为 Critical/Important 发现派发修复 subagent" [shape=box];
"在 todo 列表和进度 ledger 中标记任务完成" [shape=box];
}
"阅读计划，记录上下文和全局约束，创建 todos" [shape=box];
"还有剩余任务？" [shape=diamond];
"派发最终 code reviewer subagent（../requesting-code-review/code-reviewer.md）" [shape=box];
"使用 superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];
"阅读计划，记录上下文和全局约束，创建 todos" -> "派发 implementer subagent（./implementer-prompt.md）";
"派发 implementer subagent（./implementer-prompt.md）" -> "Implementer subagent 提问？";
"Implementer subagent 提问？" -> "回答问题，提供上下文" [label="是"];
"回答问题，提供上下文" -> "派发 implementer subagent（./implementer-prompt.md）";
"Implementer subagent 提问？" -> "Implementer subagent 实现、测试、提交、自审" [label="否"];
"Implementer subagent 实现、测试、提交、自审" -> "写 diff 文件，派发 task reviewer subagent（./task-reviewer-prompt.md）";
"写 diff 文件，派发 task reviewer subagent（./task-reviewer-prompt.md）" -> "Task reviewer 报告规范 ✅ 且质量通过？";
"Task reviewer 报告规范 ✅ 且质量通过？" -> "为 Critical/Important 发现派发修复 subagent" [label="否"];
"为 Critical/Important 发现派发修复 subagent" -> "写 diff 文件，派发 task reviewer subagent（./task-reviewer-prompt.md）" [label="重新 review"];
"Task reviewer 报告规范 ✅ 且质量通过？" -> "在 todo 列表和进度 ledger 中标记任务完成" [label="是"];
"在 todo 列表和进度 ledger 中标记任务完成" -> "还有剩余任务？";
"还有剩余任务？" -> "派发 implementer subagent（./implementer-prompt.md）" [label="是"];
"还有剩余任务？" -> "派发最终 code reviewer subagent（../requesting-code-review/code-reviewer.md）" [label="否"];
"派发最终 code reviewer subagent（../requesting-code-review/code-reviewer.md）" -> "使用 superpowers:finishing-a-development-branch";
}
在派发任务 1 之前，把整个计划扫一遍，找出冲突：
把你发现的所有问题作为一个批量问题提交给你的 human partner——每个发现放在要求它的那段计划文本旁边，询问以哪个为准——在执行开始前一次性提出，而不是在计划进行中每发现一个就打断一次。如果扫描结果是干净的，无需多言直接推进。review 循环仍然是兜底，捕获那些只有在实现过程中才会浮现的冲突。
为每个角色使用能够胜任的、最不强大的模型，以节省成本并提高速度。
机械性实现任务（孤立函数、清晰规范、1-2 个文件）：使用快速、便宜的模型。当计划定义良好时，大多数实现任务都是机械的。
集成和判断任务（多文件协调、模式匹配、调试）：使用标准模型。
架构和设计任务：使用可用的最强大模型。最终的整分支 review 就属于这一类——用可用的最强大模型派发它，而不是会话默认模型。
审查任务：选择具有同等判断力的模型，并按 diff 的规模、复杂度和风险来缩放。一个小的机械 diff 不需要最强大的模型；一个微妙的并发改动则需要。
派发 subagent 时务必显式指定模型。 省略模型会继承你会话的模型——通常是最强大也最昂贵的——这会无声地使本节失效。
回合数胜过 token 单价。 实际耗时和上下文成本随 subagent 走了多少个回合而攀升，而最便宜的模型在多步骤工作上通常要花 2-3 倍的回合——总体成本更高。对 reviewer 以及依据散文描述工作的 implementer，用中端模型作为下限。当任务的计划文本包含了要写的完整代码时，实现工作就是誊抄加测试：对那个 implementer 使用最便宜档次。单文件机械修复也用最便宜档次。
任务复杂度信号（实现任务）：
Implementer subagent 报告四种状态之一。恰当地处理每一种：
DONE： 生成 review 包（scripts/review-package BASE HEAD，从本 skill 目录运行——它会打印自己写入的唯一文件路径；BASE 是你派发 implementer 之前记录的 commit——绝不要用 HEAD~1，那会无声地丢弃多 commit 任务中除最后一个之外的所有 commit），然后带着打印出的路径派发 task reviewer。
DONE_WITH_CONCERNS： Implementer 完成了工作但标记了疑虑。在继续之前阅读这些疑虑。如果疑虑关于正确性或范围，在 review 之前解决它们。如果只是观察性备注（例如"这个文件越来越大了"），记录下来并继续 review。
NEEDS_CONTEXT： Implementer 需要未被提供的信息。提供缺失的上下文并重新派发。
BLOCKED： Implementer 无法完成任务。评估阻碍因素：
绝不无视一个上报，或在没有任何改变的情况下强制同一模型重试。如果 implementer 说它卡住了，那就一定有东西需要改变。
Task reviewer 可能报告 "⚠️ Cannot verify from diff"（无法从 diff 验证）项——即位于未改动代码中、或跨越多个任务的需求。这些不会阻塞 review 的其余部分，但你必须在标记任务完成之前，自己逐一解决它们：你掌握 reviewer 所缺乏的计划和跨任务上下文。如果你确认某一项确实是缺口，把它当作一次失败的规范 review 处理——退回给 implementer 并重新 review。
每个任务的 review 是任务范围的关卡。broad review 只发生一次，在最终的整分支 review 时。当你填写 reviewer 模板时：
scripts/review-package BASE HEAD，把它打印出的文件路径传给 reviewer（或者，在没有 bash 的情况下：对该范围运行 git log --oneline、git diff --stat 和 git diff -U10，重定向到一个唯一命名的文件）。输出绝不进入你自己的上下文，而 reviewer 一次 Read 就能看到 commit 列表、stat 摘要和带上下文的完整 diff。使用你在派发 implementer 之前记录的 BASE——绝不要用 HEAD~1，那会无声地截断多 commit 任务。scripts/review-package MERGE_BASE HEAD（MERGE_BASE = 分支起始的 commit，例如 git merge-base main HEAD），并在最终 review 派发中包含打印出的路径，这样最终 reviewer 读一个文件即可，而不用用 git 命令重新推导分支 diff。你粘贴进派发 prompt 的一切——以及 subagent 打印回来的一切——都会在会话剩余时间里常驻你的上下文，并在之后每一轮被重新读取。把产物作为文件交接：
scripts/task-brief PLAN_FILE N——它把任务的完整文本提取到一个唯一命名的文件并打印路径。组织派发内容，让简报保持为需求的唯一来源。你的派发应包含：(1) 一句话说明这个任务在项目中处于什么位置；(2) 简报路径，以"先读这个——它是你的需求，包含要逐字使用的精确值"引入；(3) 简报无法知晓的、来自更早任务的接口和决定；(4) 你在简报中注意到的任何歧义的解决方案；(5) 报告文件路径和报告契约。精确值（数字、魔法字符串、签名、测试用例）只出现在简报中。…/task-N-brief.md → 报告 …/task-N-report.md），并把它放入派发 prompt。Implementer 在那里写入完整报告，只返回状态、commits、一行测试摘要和疑虑。对话记忆无法在压缩（compaction）后存活。在真实会话中，丢失了进度的 controller 曾重新派发整个已完成的任务序列——这是观察到的最昂贵的失败。把进度追踪在 ledger 文件里，而不仅仅在 todos 中。
cat "$(git rev-parse --show-toplevel)/.superpowers/sdd/progress.md"。那里标记为完成的任务是 DONE——不要重新派发它们；在第一个未标记完成的任务处恢复。Task N: complete (commits <base7>..<head7>, review clean)。git log，胜过你自己的回忆。git clean -fdx 会销毁 ledger（它是 git 忽略的临时文件）；如果发生这种情况，从 git log 恢复。你：我正在使用 Subagent-Driven Development 来执行这个计划。
[读取计划文件一次：docs/superpowers/plans/feature-plan.md]
[为所有任务创建 todos]
任务 1：Hook 安装脚本
[为任务 1 运行 task-brief；带着简报 + 报告路径 + 上下文派发 implementer]
Implementer："开始之前——hook 应该安装在用户级还是系统级？"
你："用户级（~/.config/superpowers/hooks/）"
Implementer："明白。开始实现..."
[稍后] Implementer：
- 实现了 install-hook 命令
- 添加了测试，5/5 通过
- 自审：发现漏了 --force 标志，已补上
- 已提交
[运行 review-package，带着打印出的路径派发 task reviewer]
Task reviewer：规范 ✅ - 所有需求都满足，没有多余。
优点：测试覆盖好，干净。问题：无。任务质量：通过。
[标记任务 1 完成]
任务 2：恢复模式
[为任务 2 运行 task-brief；带着简报 + 报告路径 + 上下文派发 implementer]
Implementer：[没有问题，继续]
Implementer：
- 添加了 verify/repair 模式
- 8/8 测试通过
- 自审：一切良好
- 已提交
[运行 review-package，带着打印出的路径派发 task reviewer]
Task reviewer：规范 ❌：
- 缺失：进度报告（规范说"每 100 项报告一次"）
- 多余：添加了 --json 标志（未被要求）
问题（Important）：魔法数字（100）
[带着所有发现派发修复 subagent]
Fixer：移除了 --json 标志，添加了进度报告，提取了 PROGRESS_INTERVAL 常量
[Task reviewer 再次 review]
Task reviewer：规范 ✅。任务质量：通过。
[标记任务 2 完成]
...
[所有任务之后]
[派发最终 code-reviewer]
最终 reviewer：所有需求都满足，可以合并
完成！
对比手动执行：
对比 Executing Plans：
效率提升：
质量关卡：
成本：
绝不：
scripts/task-brief）scripts/review-package BASE HEAD），并在 prompt 中指明打印出的路径git log）如果 subagent 提问：
如果 reviewer 发现问题：
如果 subagent 任务失败：
必需的工作流 skills：
Subagent 应使用：
替代工作流：