sp-subagent-driven-development

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Subagent-Driven Development

Subagent驱动开发

Execute plan by dispatching a fresh implementer subagent per task, a task review (spec compliance + code quality) after each, and a broad whole-branch review at the end.

Why subagents: You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.

Core principle: Fresh subagent per task + task review (spec + quality) + broad final review = high quality, fast iteration

Narration: between tool calls, narrate at most one short line — the ledger and the tool results carry the record.

Continuous execution: Do not pause to check in with your human partner between tasks. Execute all tasks from the plan without stopping. The only reasons to stop are the four named below, or all tasks complete. "Should I continue?" prompts and progress summaries waste their time — they asked you to execute the plan, so execute it.

Rulings, not stalls. A running plan does not wait on a human. Conflicts, ambiguities, plan defects, a cap you would have asked to exceed — decide them. The spec is the binding authority, the plan is its argument, and your judgment settles what neither answers. Record every decision in the ledger as

Ruling: <what you decided> — <why> — <what it costs if wrong>

, and keep going. A wrong ruling costs rework your human partner can see and undo; a session parked on a question costs their whole day and buys nothing.

Four things stop you, and only these: an irreversible or destructive operation; a security-sensitive action; a side effect outside this worktree that norms say you ask about first (a merge, a push to a shared branch, a publish); and a plan so broken that every path forward is a guess. For those, stop and ask.

通过为每个任务分派一个全新的实现者subagent、在每个任务完成后进行任务评审（规范合规性+代码质量），以及在最后进行全面的全分支评审来执行计划。

为何使用subagent： 你将任务委派给拥有独立上下文的专业化agents。通过精准设计它们的指令和上下文，确保它们专注于任务并成功完成。它们绝不应继承你的会话上下文或历史记录——你要为它们构建恰好需要的内容。这也能为你的协调工作保留自身的上下文。

核心原则： 每个任务使用全新subagent + 任务评审（规范+质量）+ 全面最终评审 = 高质量、快速迭代

叙述要求： 在工具调用之间，最多叙述一行简短内容——分类账和工具结果会记录相关信息。

持续执行： 任务之间无需暂停与人类合作者确认。执行计划中的所有任务，无需停顿。唯一需要停止的情况为以下四种，或所有任务完成。“是否继续？”的提示和进度总结会浪费他们的时间——他们要求你执行计划，所以直接执行即可。

果断决策，而非停滞。 正在执行的计划无需等待人类。冲突、歧义、计划缺陷、需要突破的限制——自行决策。规范是约束性权威，计划是其论据，你的判断可解决两者都未回答的问题。将每个决策记录在分类账中，格式为

Ruling: <你的决策内容> — <决策原因> — <决策错误的代价>

，并持续执行。错误的决策会导致返工，人类合作者可以看到并撤销；而因问题停滞的会话会浪费他们一整天的时间，却毫无收获。

仅在以下四种情况下停止执行：不可逆或破坏性操作；安全敏感型操作；超出本工作树范围且按规范需先询问的副作用（如合并、推送到共享分支、发布）；以及计划完全失效，所有前进路径均为猜测。遇到这些情况时，停止执行并询问。

When to Use

使用场景

dot

digraph when_to_use {
    "Have implementation plan?" [shape=diamond];
    "Tasks mostly independent?" [shape=diamond];
    "Stay in this session?" [shape=diamond];
    "sp-subagent-driven-development" [shape=box];
    "sp-executing-plans" [shape=box];
    "Manual execution or brainstorm first" [shape=box];

    "Have implementation plan?" -> "Tasks mostly independent?" [label="yes"];
    "Have implementation plan?" -> "Manual execution or brainstorm first" [label="no"];
    "Tasks mostly independent?" -> "Stay in this session?" [label="yes"];
    "Tasks mostly independent?" -> "Manual execution or brainstorm first" [label="no - tightly coupled"];
    "Stay in this session?" -> "sp-subagent-driven-development" [label="yes"];
    "Stay in this session?" -> "sp-executing-plans" [label="no - parallel session"];
}

vs. Executing Plans (parallel session):

Same session (no context switch)
Fresh subagent per task (no context pollution)
Review after each task (spec compliance + code quality), broad review at the end
Faster iteration (no human-in-loop between tasks)

dot

digraph when_to_use {
    "Have implementation plan?" [shape=diamond];
    "Tasks mostly independent?" [shape=diamond];
    "Stay in this session?" [shape=diamond];
    "sp-subagent-driven-development" [shape=box];
    "sp-executing-plans" [shape=box];
    "Manual execution or brainstorm first" [shape=box];

    "Have implementation plan?" -> "Tasks mostly independent?" [label="yes"];
    "Have implementation plan?" -> "Manual execution or brainstorm first" [label="no"];
    "Tasks mostly independent?" -> "Stay in this session?" [label="yes"];
    "Tasks mostly independent?" -> "Manual execution or brainstorm first" [label="no - tightly coupled"];
    "Stay in this session?" -> "sp-subagent-driven-development" [label="yes"];
    "Stay in this session?" -> "sp-executing-plans" [label="no - parallel session"];
}

与执行计划（并行会话）的对比：

同一会话（无上下文切换）
每个任务使用全新subagent（无上下文污染）
每个任务完成后进行评审（规范合规性+代码质量），最后进行全面评审
迭代速度更快（任务之间无需人工介入）

The Process

执行流程

dot

digraph process {
    rankdir=TB;

    subgraph cluster_per_task {
        label="Per Task";
        "Dispatch implementer subagent (./implementer-prompt.md)" [shape=box];
        "Implementer asks questions?" [shape=diamond];
        "Answer questions, provide context" [shape=box];
        "Implementer implements, tests, commits, self-reviews" [shape=box];
        "Generate review package, dispatch task reviewer (./task-reviewer-prompt.md)" [shape=box];
        "Spec ✅ and quality approved?" [shape=diamond];
        "Finding conflicts with plan text?" [shape=diamond];
        "Rule on the conflict, ledger the ruling" [shape=box];
        "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model" [shape=box];
        "Dispatch scoped re-review (./re-review-prompt.md)" [shape=box];
        "All findings addressed?" [shape=diamond];
        "R = 5?" [shape=diamond];
        "Adjudicate each open finding" [shape=box];
        "Any load-bearing finding?" [shape=diamond];
        "Rule and continue; stop only if every path forward is a guess" [shape=box];
        "Park findings in ledger with rulings" [shape=box];
        "Append completion to ledger, mark todo complete" [shape=box];
    }

    "Setup: worktree, ledger check, read plan, pre-flight review" [shape=box];
    "More tasks remain?" [shape=diamond];
    "Dispatch final code reviewer (../sp-requesting-code-review/code-reviewer.md)" [shape=box];
    "Final findings? ONE fix dispatch, one scoped re-review, adjudicate residuals" [shape=box];
    "Final review clean: delete this plan's workspace" [shape=box];
    "Use superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];

    "Setup: worktree, ledger check, read plan, pre-flight review" -> "Dispatch implementer subagent (./implementer-prompt.md)";
    "Dispatch implementer subagent (./implementer-prompt.md)" -> "Implementer asks questions?";
    "Implementer asks questions?" -> "Answer questions, provide context" [label="yes"];
    "Answer questions, provide context" -> "Implementer implements, tests, commits, self-reviews";
    "Implementer asks questions?" -> "Implementer implements, tests, commits, self-reviews" [label="no"];
    "Implementer implements, tests, commits, self-reviews" -> "Generate review package, dispatch task reviewer (./task-reviewer-prompt.md)";
    "Generate review package, dispatch task reviewer (./task-reviewer-prompt.md)" -> "Spec ✅ and quality approved?";
    "Spec ✅ and quality approved?" -> "Append completion to ledger, mark todo complete" [label="yes"];
    "Spec ✅ and quality approved?" -> "Finding conflicts with plan text?" [label="no"];
    "Finding conflicts with plan text?" -> "Rule on the conflict, ledger the ruling" [label="yes"];
    "Rule on the conflict, ledger the ruling" -> "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model";
    "Finding conflicts with plan text?" -> "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model" [label="no"];
    "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model" -> "Dispatch scoped re-review (./re-review-prompt.md)";
    "Dispatch scoped re-review (./re-review-prompt.md)" -> "All findings addressed?";
    "All findings addressed?" -> "Append completion to ledger, mark todo complete" [label="yes"];
    "All findings addressed?" -> "R = 5?" [label="no"];
    "R = 5?" -> "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model" [label="no - next round"];
    "R = 5?" -> "Adjudicate each open finding" [label="yes - breaker trips"];
    "Adjudicate each open finding" -> "Any load-bearing finding?";
    "Any load-bearing finding?" -> "Rule and continue; stop only if every path forward is a guess" [label="yes"];
    "Any load-bearing finding?" -> "Park findings in ledger with rulings" [label="no"];
    "Park findings in ledger with rulings" -> "Append completion to ledger, mark todo complete";
    "Append completion to ledger, mark todo complete" -> "More tasks remain?";
    "More tasks remain?" -> "Dispatch implementer subagent (./implementer-prompt.md)" [label="yes"];
    "More tasks remain?" -> "Dispatch final code reviewer (../sp-requesting-code-review/code-reviewer.md)" [label="no"];
    "Dispatch final code reviewer (../sp-requesting-code-review/code-reviewer.md)" -> "Final findings? ONE fix dispatch, one scoped re-review, adjudicate residuals";
    "Final findings? ONE fix dispatch, one scoped re-review, adjudicate residuals" -> "Final review clean: delete this plan's workspace";
    "Final review clean: delete this plan's workspace" -> "Use superpowers:finishing-a-development-branch";
}

dot

digraph process {
    rankdir=TB;

    subgraph cluster_per_task {
        label="Per Task";
        "Dispatch implementer subagent (./implementer-prompt.md)" [shape=box];
        "Implementer asks questions?" [shape=diamond];
        "Answer questions, provide context" [shape=box];
        "Implementer implements, tests, commits, self-reviews" [shape=box];
        "Generate review package, dispatch task reviewer (./task-reviewer-prompt.md)" [shape=box];
        "Spec ✅ and quality approved?" [shape=diamond];
        "Finding conflicts with plan text?" [shape=diamond];
        "Rule on the conflict, ledger the ruling" [shape=box];
        "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model" [shape=box];
        "Dispatch scoped re-review (./re-review-prompt.md)" [shape=box];
        "All findings addressed?" [shape=diamond];
        "R = 5?" [shape=diamond];
        "Adjudicate each open finding" [shape=box];
        "Any load-bearing finding?" [shape=diamond];
        "Rule and continue; stop only if every path forward is a guess" [shape=box];
        "Park findings in ledger with rulings" [shape=box];
        "Append completion to ledger, mark todo complete" [shape=box];
    }

    "Setup: worktree, ledger check, read plan, pre-flight review" [shape=box];
    "More tasks remain?" [shape=diamond];
    "Dispatch final code reviewer (../sp-requesting-code-review/code-reviewer.md)" [shape=box];
    "Final findings? ONE fix dispatch, one scoped re-review, adjudicate residuals" [shape=box];
    "Final review clean: delete this plan's workspace" [shape=box];
    "Use superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];

    "Setup: worktree, ledger check, read plan, pre-flight review" -> "Dispatch implementer subagent (./implementer-prompt.md)";
    "Dispatch implementer subagent (./implementer-prompt.md)" -> "Implementer asks questions?";
    "Implementer asks questions?" -> "Answer questions, provide context" [label="yes"];
    "Answer questions, provide context" -> "Implementer implements, tests, commits, self-reviews";
    "Implementer asks questions?" -> "Implementer implements, tests, commits, self-reviews" [label="no"];
    "Implementer implements, tests, commits, self-reviews" -> "Generate review package, dispatch task reviewer (./task-reviewer-prompt.md)";
    "Generate review package, dispatch task reviewer (./task-reviewer-prompt.md)" -> "Spec ✅ and quality approved?";
    "Spec ✅ and quality approved?" -> "Append completion to ledger, mark todo complete" [label="yes"];
    "Spec ✅ and quality approved?" -> "Finding conflicts with plan text?" [label="no"];
    "Finding conflicts with plan text?" -> "Rule on the conflict, ledger the ruling" [label="yes"];
    "Rule on the conflict, ledger the ruling" -> "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model";
    "Finding conflicts with plan text?" -> "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model" [label="no"];
    "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model" -> "Dispatch scoped re-review (./re-review-prompt.md)";
    "Dispatch scoped re-review (./re-review-prompt.md)" -> "All findings addressed?";
    "All findings addressed?" -> "Append completion to ledger, mark todo complete" [label="yes"];
    "All findings addressed?" -> "R = 5?" [label="no"];
    "R = 5?" -> "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model" [label="no - next round"];
    "R = 5?" -> "Adjudicate each open finding" [label="yes - breaker trips"];
    "Adjudicate each open finding" -> "Any load-bearing finding?";
    "Any load-bearing finding?" -> "Rule and continue; stop only if every path forward is a guess" [label="yes"];
    "Any load-bearing finding?" -> "Park findings in ledger with rulings" [label="no"];
    "Park findings in ledger with rulings" -> "Append completion to ledger, mark todo complete";
    "Append completion to ledger, mark todo complete" -> "More tasks remain?";
    "More tasks remain?" -> "Dispatch implementer subagent (./implementer-prompt.md)" [label="yes"];
    "More tasks remain?" -> "Dispatch final code reviewer (../sp-requesting-code-review/code-reviewer.md)" [label="no"];
    "Dispatch final code reviewer (../sp-requesting-code-review/code-reviewer.md)" -> "Final findings? ONE fix dispatch, one scoped re-review, adjudicate residuals";
    "Final findings? ONE fix dispatch, one scoped re-review, adjudicate residuals" -> "Final review clean: delete this plan's workspace";
    "Final review clean: delete this plan's workspace" -> "Use superpowers:finishing-a-development-branch";
}

Setup

准备工作

Ensure the work happens in an isolated workspace: use superpowers:using-git-worktrees to create one or verify the existing one. Never start implementation on a main/master branch without your human partner's explicit consent.

Conversation memory does not survive compaction. In real sessions, controllers that lost their place have re-dispatched entire completed task sequences — the single most expensive failure observed. Track progress in a ledger file, not only in todos.

Each plan owns a workspace: at skill start, run this skill's
```
scripts/sdd-workspace PLAN_FILE
```
— it prints the plan's git-ignored directory (
```
<repo-root>/.superpowers/sdd/<plan-basename>/
```
), home to every artifact for THIS plan: ledger, briefs, reports, review packages. Another plan's directory is never yours to read or write.
Check for this plan's ledger at
```
<workspace>/progress.md
```
. If its first line names your plan file, tasks with a
```
Task <N>: complete
```
line are DONE — do not re-dispatch them; resume at the first task without one. A task whose last line is a fix round is mid-loop: resume the loop at the next round. A ledger whose first line names a different plan file — or a stray ledger at the old flat path
```
.superpowers/sdd/progress.md
```
— is another plan's progress: leave it in place and start your own, fresh.
Create the ledger with its identity as the first line:
```
# SDD ledger — plan: <plan file path>
```
.
The ledger is your recovery map: the commits it names exist in git even when your context no longer remembers creating them. After compaction, trust the ledger and
```
git log
```
over your own recollection.
```
git clean -fdx
```
will destroy the workspace (it's git-ignored scratch); if that happens, recover from
```
git log
```
.

Read the plan once, note its context and Global Constraints, and create a todo per task. If the plan names a Spec, read that too: the spec is the authority the plan argues from, and conflicts inside the plan resolve against it. A plan with no reachable spec gets a ledger note saying so — rulings made without one are provisional.

Before dispatching Task 1, scan the plan once for conflicts, writing down what you checked as you check it:

tasks that contradict each other or the plan's Global Constraints
anything the plan explicitly mandates that the review rubric treats as a defect (a test that asserts nothing, verbatim duplication of a logic block)

The scan's output is a table, not a verdict. One row for every pair of tasks that share a file or an interface: the two tasks, what one produces against what the other consumes, and what you found. One row for every task: whether its own text agrees with itself — the tests it specifies against the code it specifies, the files it creates against the files it later touches. "The scan is clean" without those rows is not a scan you ran.

Write the table to the ledger. Rule on everything you find before execution begins — each finding against the plan text that mandates it — and record each ruling in the ledger. If the scan is clean, proceed without comment. Rule on each conflict it surfaces — the spec is the binding authority, the plan is its argument — record the ruling beside its row, and dispatch Task 1. The review loop remains the net for conflicts that only emerge from implementation.

确保工作在独立工作区进行：使用superpowers:using-git-worktrees创建一个工作区，或验证现有工作区。未经人类合作者明确同意，绝不要在main/master分支上开始实施工作。

对话记忆无法在压缩后保留。在实际会话中，丢失进度的控制器会重新分派整个已完成的任务序列——这是观察到的代价最高的故障。在分类账文件中跟踪进度，而不仅仅是待办事项。

每个计划拥有一个工作区：在技能启动时，运行本技能的
```
scripts/sdd-workspace PLAN_FILE
```
——它会打印计划的git忽略目录（
```
<repo-root>/.superpowers/sdd/<plan-basename>/
```
），该目录是本计划所有工件的存放地：分类账、摘要、报告、评审包。绝不要读取或写入其他计划的目录。
检查
```
<workspace>/progress.md
```
是否存在本计划的分类账。如果第一行是你的计划文件名，带有
```
Task <N>: complete
```
行的任务已完成——不要重新分派；从第一个没有该标记的任务开始恢复。最后一行是修复轮次的任务处于循环中：在下一轮次恢复循环。第一行是其他计划文件名的分类账——或位于旧的扁平化路径
```
.superpowers/sdd/progress.md
```
的零散分类账——属于其他计划的进度：保留其位置，创建全新的分类账。
创建分类账，第一行标识身份：
```
# SDD ledger — plan: <plan file path>
```
。
分类账是你的恢复地图：即使你的上下文不再记得创建过这些提交，分类账中命名的提交仍存在于git中。压缩后，信任分类账和
```
git log
```
，而非你自己的记忆。
```
git clean -fdx
```
会销毁工作区（它是git忽略的临时目录）；如果发生这种情况，从
```
git log
```
恢复。

通读计划一次，记录其上下文和全局约束，并为每个任务创建待办事项。如果计划指定了规范，也要阅读该规范：规范是计划的论据基础，计划内部的冲突需根据规范解决。无法获取规范的计划需在分类账中注明——无规范依据的裁决是临时的。

在分派任务1之前，扫描计划一次以查找冲突，检查时记录你所检查的内容：

相互矛盾或与计划全局约束冲突的任务
计划明确要求但评审规则视为缺陷的内容（如无断言的测试、逻辑块的完全重复）

扫描输出为表格，而非结论。每一行对应共享文件或接口的一对任务：两个任务、一个任务的产出与另一个任务的输入、以及你发现的问题。每一行对应一个任务：其文本是否自洽——指定的测试与指定的代码、创建的文件与后续修改的文件。没有这些行的“扫描无问题”并非真正的扫描。

将表格写入分类账。在执行开始前对所有发现的问题做出裁决——每个与计划文本要求冲突的发现——并将每个裁决记录在分类账中。如果扫描无问题，直接继续。对扫描发现的每个冲突做出裁决——规范是约束性权威，计划是其论据——在对应行旁记录裁决，然后分派任务1。评审循环仍会捕捉仅在实施过程中出现的冲突。

Model Selection

模型选择

Use the least powerful model that can handle each role to conserve cost and increase speed.

Mechanical implementation tasks (isolated functions, clear specs, 1-2 files): use a fast, cheap model. Most implementation tasks are mechanical when the plan is well-specified.

Integration and judgment tasks (multi-file coordination, pattern matching, debugging): use a standard model.

Architecture and design tasks: use the most capable available model. The final whole-branch review is one of these — dispatch it on the most capable available model, not the session default.

Review tasks: choose the model with the same judgment, scaled to the diff's size, complexity, and risk. A small mechanical diff does not need the most capable model; a subtle concurrency change does. Scoped re-reviews of small fix diffs take a cheap-to-mid tier.

Fix-loop escalation (rounds 4-5): use a model at least one tier above the implementer that got stuck.

Always specify the model explicitly when dispatching a subagent. An omitted model inherits your session's model — often the most capable and most expensive — which silently defeats this section.

Turn count beats token price. Wall-clock and context cost scale with how many turns a subagent takes, and the cheapest models routinely take 2-3× the turns on multi-step work — costing more overall. Use a mid-tier model as the floor for reviewers and for implementers working from prose descriptions. For a reviewer, the turn count follows the assignment, not the diff: a reviewer told to check one changed file against twenty others is doing a twenty-file reading, and will take the turns to match. When the task's plan text contains the complete code to write, the implementation is transcription plus testing: use the cheapest tier for that implementer. Single-file mechanical fixes also take the cheapest tier.

Task complexity signals (implementation tasks):

Touches 1-2 files with a complete spec → cheap model
Touches multiple files with integration concerns → standard model
Requires design judgment or broad codebase understanding → most capable model

使用能够处理每个角色的最低性能模型，以节约成本并提高速度。

机械实施任务（独立函数、明确规范、1-2个文件）：使用快速、低成本的模型。当计划规范明确时，大多数实施任务都是机械性的。

集成与判断任务（多文件协调、模式匹配、调试）：使用标准模型。

架构与设计任务：使用可用的最强大模型。最终的全分支评审属于此类——使用可用的最强大模型分派，而非会话默认模型。

评审任务：根据差异的大小、复杂度和风险，选择具备相应判断能力的模型。小型机械性差异无需最强大的模型；微妙的并发变更则需要。小型修复差异的范围化重新评审使用中低成本模型。

修复循环升级（第4-5轮）：使用比陷入困境的实现者模型至少高一个层级的模型。

分派subagent时始终明确指定模型。 省略模型会继承你的会话模型——通常是最强大、最昂贵的模型——这会无声地违背本节要求。

轮次数量比令牌价格更重要。 时钟时间和上下文成本与subagent的轮次数量成正比，最便宜的模型在多步骤工作中通常需要2-3倍的轮次——总体成本更高。将中端模型作为评审者和基于 prose描述工作的实现者的最低层级。对于评审者，轮次数量取决于任务分配，而非差异：被要求检查一个修改文件与其他二十个文件的评审者需要读取二十个文件，轮次数量也会相应增加。当任务的计划文本包含完整的待编写代码时，实施工作是转录加测试：为此类实现者使用最便宜的层级。单文件机械修复也使用最便宜的层级。

任务复杂度信号（实施任务）：

涉及1-2个文件且规范完整 → 低成本模型
涉及多个文件且存在集成问题 → 标准模型
需要设计判断或广泛的代码库理解 → 最强大模型

The Task Loop

任务循环

Batch small same-shape work. When the plan lists several tasks that are each a small, independent edit of the same kind — the same one-line fix, constant change, or field addition repeated across files — do not dispatch one subagent per task. Compose ONE dispatch brief listing every file and its change, send the whole batch to a single subagent, and review its diff as one unit. Reserve one-dispatch-per-task for work that needs its own judgment, its own tests, or its own review surface.

Everything you paste into a dispatch prompt — and everything a subagent prints back — stays resident in your context for the rest of the session and is re-read on every later turn. Hand artifacts over as files.

Waiting on dispatched subagents: never poll a wait interface with short timeouts, and never sit in one silent, open-ended wait either. While you have local work — ledger updates, packaging the next review, reading reports — keep working; child results arrive on their own. When you are genuinely idle, wait in bounded stretches (five to ten minutes, where your platform allows), and between stretches post one line of status and reconcile your live children: list them, and chase any that finished without reporting. A bounded stretch keeps nearly all of a long wait's efficiency while guaranteeing a stuck or lost child is noticed within minutes, not at the end of the session.

批量处理小型同类工作。 当计划列出多个小型、独立的同类编辑任务——相同的单行修复、常量更改或跨文件重复的字段添加——不要为每个任务分派一个subagent。撰写一个包含所有文件及其变更的分派摘要，将整个批量任务发送给单个subagent，并将其差异作为一个单元进行评审。仅为需要独立判断、独立测试或独立评审面的工作保留“一个任务一个分派”的模式。

你粘贴到分派提示中的所有内容——以及subagent返回的所有内容——会在会话剩余时间内保留在你的上下文中，并在后续每个轮次中重新读取。通过文件传递工件。

等待已分派的subagent： 永远不要用短超时轮询等待接口，也不要一直处于无限制的静默等待状态。当你有本地工作时——更新分类账、打包下一次评审、阅读报告——继续工作；子任务结果会自行返回。当你确实空闲时，进行有界等待（平台允许的话，5到10分钟），在等待间隔之间发布一行状态并核对活跃的子任务：列出它们，追踪任何已完成但未报告的子任务。有界等待既保留了长时间等待的效率，又能确保在几分钟内发现卡住或丢失的子任务，而非在会话结束时。

1. Dispatch the implementer

1. 分派实现者

Record BASE (

git rev-parse HEAD

) before dispatching — the review package and fix-round diffs need it.

Task brief: before dispatching an implementer, run this skill's
```
scripts/task-brief PLAN_FILE N
```
— it extracts the task's full text to a uniquely named file and prints the path. Compose the dispatch so the brief stays the single source of requirements. Your dispatch should contain: (1) one line on where this task fits in the project; (2) the brief path, introduced as "read this first — it is your requirements, with the exact values to use verbatim"; (3) interfaces and decisions from earlier tasks that the brief cannot know; (4) your resolution of any ambiguity you noticed in the brief; (5) the report-file path and report contract. Exact values (numbers, magic strings, signatures, test cases) appear only in the brief. Never make a subagent read the whole plan file.
Report file: name the implementer's report file after the brief (brief
```
…/task-N-brief.md
```
→ report
```
…/task-N-report.md
```
) and put it in the dispatch prompt. The implementer writes the full report there and returns only status, commits, a one-line test summary, and concerns.
A dispatch prompt describes one task, not the session's history. Do not paste accumulated prior-task summaries ("state after Tasks 1-3") into later dispatches — a real session's dispatch hit 42k chars of which 99% was pasted history. A fresh subagent needs its task, the interfaces it touches, and the global constraints. Nothing else.
The dispatch carries the no-subagents contract (it is in the implementer template): the implementer never dispatches subagents — not helpers, and never a reviewer. Review arrives from you, after the report. In real sessions, every reviewer a worker spawned duplicated the task review the controller dispatched anyway — a full extra review seat per task.
If an earlier task parked a finding in the area this task touches, carry a pointer to that ledger entry in the dispatch.
Record the implementer's agent identity from the dispatch result — fix-loop rounds 1-3 resume this agent.
Never dispatch multiple implementation subagents in parallel (conflicts).

Template: implementer-prompt.md

在分派前记录BASE（

git rev-parse HEAD

）——评审包和修复轮次差异需要它。

任务摘要： 在分派实现者之前，运行本技能的
```
scripts/task-brief PLAN_FILE N
```
——它会将任务的完整文本提取到一个唯一命名的文件中并打印路径。撰写分派内容，使摘要成为需求的唯一来源。你的分派应包含：(1) 一行说明该任务在项目中的位置；(2) 摘要路径，说明为“先阅读此内容——这是你的需求，包含要直接使用的精确值”；(3) 摘要无法知晓的早期任务的接口和决策；(4) 你对摘要中发现的任何歧义的解决方案；(5) 报告文件路径和报告约定。精确值（数字、魔法字符串、签名、测试用例）仅出现在摘要中。绝不要让subagent读取整个计划文件。
报告文件： 以摘要命名实现者的报告文件（摘要
```
…/task-N-brief.md
```
→ 报告
```
…/task-N-report.md
```
），并将其放入分派提示中。实现者在该文件中撰写完整报告，仅返回状态、提交记录、一行测试摘要和关注点。
分派提示描述一个任务，而非会话历史。不要将之前任务的累积摘要（“任务1-3后的状态”）粘贴到后续分派中——实际会话中的分派曾达到42k字符，其中99%是粘贴的历史记录。全新的subagent需要其任务、涉及的接口和全局约束。无需其他内容。
分派包含no-subagents约定（在实现者模板中）：实现者永远不要分派subagent——不要助手，也不要评审者。评审由你在报告后发起。在实际会话中，工作者生成的每个评审者都会重复控制器已分派的任务评审——每个任务额外占用一个评审席位。
如果早期任务在当前任务涉及的领域中停放了一个发现，在分派中包含指向该分类账条目的指针。
从分派结果中记录实现者的agent身份——修复循环第1-3轮恢复此agent。
永远不要并行分派多个实现者subagent（避免冲突）。

模板：implementer-prompt.md

2. Handle the report

2. 处理报告

Implementer subagents report one of four statuses. Handle each appropriately:

DONE: Generate the review package (

scripts/review-package PLAN_FILE BASE HEAD

, from this skill's directory — it prints the unique file path it wrote; BASE is the commit you recorded before dispatching the implementer — never

HEAD~1

, which silently drops all but the last commit of a multi-commit task), then dispatch the task reviewer with the printed path.

DONE_WITH_CONCERNS: The implementer completed the work but flagged doubts. Read the concerns before proceeding. If the concerns are about correctness or scope, address them before review. If they're observations (e.g., "this file is getting large"), note them and proceed to review.

NEEDS_CONTEXT: The implementer needs information that wasn't provided. Provide the missing context and re-dispatch.

BLOCKED: The implementer cannot complete the task. Assess the blocker:

If it's a context problem, provide more context and re-dispatch with the same model
If the task requires more reasoning, re-dispatch with a more capable model
If the task is too large, break it into smaller pieces
If the plan itself is wrong, rule on the correction, ledger it, and re-dispatch with the ruling carried in the dispatch

Never ignore an escalation or force the same model to retry without changes. If the implementer said it's stuck, something needs to change.

If the implementer asks questions — before starting or mid-task — answer clearly and completely, provide additional context if needed, and don't rush it into implementation.

实现者subagent会报告四种状态之一。分别进行处理：

DONE： 生成评审包（

scripts/review-package PLAN_FILE BASE HEAD

，从本技能目录运行——它会打印写入的唯一文件路径；BASE是你在分派实现者之前记录的提交——绝不要使用

HEAD~1

，它会无声地丢弃多提交任务中除最后一个提交外的所有内容），然后使用打印的路径分派任务评审者。

DONE_WITH_CONCERNS： 实现者已完成工作，但标记了疑问。在继续之前阅读这些疑问。如果疑问涉及正确性或范围，在评审前解决。如果是观察结果（如“此文件变得过大”），记录下来并继续评审。

NEEDS_CONTEXT： 实现者需要未提供的信息。提供缺失的上下文并重新分派。

BLOCKED： 实现者无法完成任务。评估阻塞原因：

如果是上下文问题，提供更多上下文并使用相同模型重新分派
如果任务需要更多推理，使用更强大的模型重新分派
如果任务过大，将其拆分为更小的部分
如果计划本身有误，对修正做出裁决，记录在分类账中，并在分派中携带裁决内容重新分派

绝不要忽略升级请求，或在未做更改的情况下强制同一模型重试。如果实现者表示已卡住，就需要做出改变。

如果实现者在开始前或任务中提出问题——清晰完整地回答，必要时提供额外上下文，不要急于进入实施阶段。

3. Review the task

3. 任务评审

Per-task reviews are task-scoped gates. The broad review happens once, at the final whole-branch review. Never skip the task review, and never accept a report missing either verdict — spec compliance AND task quality are both required. Implementer self-review never replaces the task review; both are needed.

Hand the reviewer its diff as a file: run this skill's
```
scripts/review-package PLAN_FILE BASE HEAD
```
and pass the reviewer the file path it prints (or, without bash:
```
git log --oneline
```
,
```
git diff --stat
```
, and
```
git diff -U10
```
for the range, redirected to one uniquely named file). The output never enters your own context, and the reviewer sees the commit list, stat summary, and full diff with context in one Read call. Use the BASE you recorded before dispatching the implementer — never
```
HEAD~1
```
, which silently truncates multi-commit tasks. Never dispatch a task reviewer without a diff file.
Reviewer inputs: the task reviewer gets three paths — the same brief file, the report file, and the review package — plus the global constraints that bind the task.
The global-constraints block you hand the reviewer is its attention lens. Copy the binding requirements verbatim from the plan's Global Constraints section or the spec: exact values, exact formats, and the stated relationships between components ("same layout as X", "matches Y"). The reviewer's template already carries the process rules (YAGNI, test hygiene, review method) — the constraints block is for what THIS project's spec demands.
Do not add open-ended directives like "check all uses" or "run race tests if useful" without a concrete, task-specific reason
Do not ask a reviewer to re-run tests the implementer already ran on the same code — the implementer's report carries the test evidence
Do not pre-judge findings for the reviewer — never instruct a reviewer to ignore or not flag a specific issue. If you believe a finding would be a false positive, let the reviewer raise it and adjudicate it in the review loop. If the prompt you are writing contains "do not flag," "don't treat X as a defect," "at most Minor," or "the plan chose" — stop: you are pre-judging, usually to spare yourself a review loop. The task reviewer may report "⚠️ Cannot verify from diff" items — requirements that live in unchanged code or span tasks. These do not block the rest of the review, but you must resolve each one yourself before marking the task complete: you hold the plan and cross-task context the reviewer lacks. If you confirm an item is a real gap, treat it as a failed spec review — it enters the fix loop with the other findings.

Template: task-reviewer-prompt.md

每个任务的评审是任务范围的关卡。全面评审仅在最后进行一次全分支评审。绝不要跳过任务评审，也不要接受缺少任一结论的报告——规范合规性和任务质量都是必需的。实现者的自我评审永远无法替代任务评审；两者都需要。

将差异作为文件交给评审者：运行本技能的
```
scripts/review-package PLAN_FILE BASE HEAD
```
，并将打印的文件路径传递给评审者（或不使用bash：
```
git log --oneline
```
、
```
git diff --stat
```
和
```
git diff -U10
```
获取范围，重定向到一个唯一命名的文件）。输出永远不会进入你自己的上下文，评审者通过一次读取操作即可看到提交列表、统计摘要和带有上下文的完整差异。使用你在分派实现者之前记录的BASE——绝不要使用
```
HEAD~1
```
，它会无声地截断多提交任务。永远不要在没有差异文件的情况下分派任务评审者。
评审者输入： 任务评审者会获得三个路径——相同的摘要文件、报告文件和评审包——以及约束任务的全局约束。
你交给评审者的全局约束块是其关注重点。从计划的全局约束部分或规范中逐字复制约束性要求：精确值、精确格式、组件之间的明确关系（“与X布局相同”、“匹配Y”）。评审者模板已包含流程规则（YAGNI、测试卫生、评审方法）——约束块用于指定本项目规范的要求。
不要添加开放式指令，如“检查所有用法”或“如有必要运行竞争测试”，除非有具体的任务相关理由
不要要求评审者重新运行实现者已在同一代码上运行过的测试——实现者的报告已包含测试证据
不要为评审者预先判断发现——永远不要指示评审者忽略或不标记特定问题。如果你认为某个发现是误报，让评审者提出并在评审循环中裁决。如果你正在编写的提示包含“不要标记”、“不要将X视为缺陷”、“最多Minor”或“计划已选择”——停止：你正在预先判断，通常是为了避免评审循环。任务评审者可能会报告“⚠️ Cannot verify from diff”项——存在于未修改代码或跨任务的需求。这些不会阻碍评审的其余部分，但你必须在标记任务完成前自行解决每个问题：你拥有评审者缺乏的计划和跨任务上下文。如果你确认某一项是真实的差距，将其视为规范评审失败——它会与其他发现一起进入修复循环。

模板：task-reviewer-prompt.md

4. The fix loop

4. 修复循环

The loop triggers when the review reports spec ❌, any Critical or Important finding, or a ⚠️ item you confirmed as a real gap.

Before the loop starts, two routes leave it immediately:

Record Minor findings in the progress ledger as you go (
```
Task <N>: minor (deferred): <one-liner>
```
), and point the final whole-branch review at that list so it can triage which must be fixed before merge. A roll-up nobody reads is a silent discard. Minor findings never enter the loop.
A finding labeled plan-mandated — or any finding that conflicts with what the plan's text requires — is yours to rule on: weigh the finding against the plan text, decide with the spec as the binding authority, and ledger the ruling before you act on it. Do not dismiss the finding because the plan mandates it, and do not dispatch a fix that contradicts the plan without a recorded ruling. Everything else enters the loop. A fix round is one fix dispatch plus one scoped re-review. Five rounds maximum per task:

Rounds 1-3 — resume the original implementer. Send it the open findings verbatim. Its context is intact: it knows the task, the code, and its own choices. If your harness cannot send another message to a live subagent, dispatch a fresh implementer carrying the brief path, the report-file path, and the findings — the report file is the persistent memory either way.

Rounds 4-5 — dispatch a fresh implementer on a more capable model (per Model Selection), with the brief path, the report-file path, the open findings, and this framing: "A prior implementer attempted this task [N] times; you own it now. Read the report file for what was tried." A loop that survives three resumes usually means the implementer cannot see its own problem — fresh eyes and a capability bump in one move.

Every round, either way: the implementer fixes, re-runs the tests covering the amended code, appends its fix report to the same report file, and returns the short contract. Before re-dispatching the reviewer, confirm the fix report contains the covering tests, the command run, and the output; dispatch the re-review once all three are present. Name the covering test files in the fix message — a one-line fix does not need the whole suite.

The re-review is scoped. Run

scripts/review-package PLAN_FILE FIX_BASE HEAD

where FIX_BASE is the head the previous review saw, and dispatch re-review-prompt.md with the findings list, the brief, the report file, and the printed diff path. The re-reviewer verdicts each finding ADDRESSED or NOT ADDRESSED and flags new breakage in the fix diff only. New Critical/Important breakage in the fix diff joins the open findings list. Out-of-scope observations go to the ledger as deferred minors — they never extend the loop.

After each round, append to the ledger:

Task <N>: fix round <R>/5 (<X> addressed, <Y> open — <finding one-liners>; commits <a7>..<b7>)

Never fix findings yourself in the controller session — your context stays clean for coordination, and controller fixes skip review.

The breaker. When round 5's re-review still leaves findings open, stop dispatching. Adjudicate each open finding yourself — you hold the plan and the cross-task context the reviewer lacks:

The reviewer is wrong, or the point is contestable: park it —
```
Task <N>: parked — <finding> — Ruling: <why the code stands>
```
. The final review sees both sides.
Real, but nothing downstream builds on it: park it the same way, with a ruling that says it's real and deferred.
Real and load-bearing — a later task builds on it, or it reveals a plan defect: rule on the smallest change that unblocks the dependent work, ledger it as
```
Task <N>: Ruling: <finding> — <what you decided and why>
```
, and carry it into the next task's dispatch. Parking a structural failure silently lets every dependent task build on it. Stop only when the defect leaves every path forward a guess.

Adjudicate only at the cap. Adjudicating earlier to end a loop is pre-judging with a different name. Every adjudication is a ledger entry — a silent discard is forbidden.

当评审报告规范❌、任何Critical或Important发现，或你确认为真实差距的⚠️项时，触发循环。

循环开始前，有两种情况可直接退出：

随时在进度分类账中记录Minor发现（
```
Task <N>: minor (deferred): <一行描述>
```
），并让最终的全分支评审指向该列表，以便它能筛选出合并前必须修复的内容。无人阅读的汇总等同于静默丢弃。Minor发现永远不会进入循环。
标记为plan-mandated的发现——或任何与计划文本要求冲突的发现——由你裁决：权衡发现与计划文本，以规范为约束性权威做出决策，并在采取行动前将裁决记录在分类账中。不要因为计划要求而驳回发现，也不要在未记录裁决的情况下分派与计划冲突的修复。其他所有内容进入循环。一个修复轮次包含一次修复分派和一次范围化重新评审。每个任务最多五轮：

第1-3轮——恢复原始实现者。 将未解决的发现逐字发送给它。它的上下文完整：了解任务、代码和自己的选择。如果你的工具无法向活跃的subagent发送另一条消息，分派一个全新的实现者，携带摘要路径、报告文件路径和发现——报告文件是持久化的记忆。

第4-5轮——使用更强大的模型分派全新的实现者（根据模型选择），携带摘要路径、报告文件路径、未解决的发现，以及以下框架：“之前的实现者尝试此任务[N]次；现在由你负责。阅读报告文件了解已尝试的内容。” 三轮恢复后仍未解决的循环通常意味着实现者无法发现自身问题——全新的视角和性能提升可一举解决。

无论哪种情况，每一轮： 实现者进行修复，重新运行覆盖修改代码的测试，将修复报告追加到同一报告文件中，并返回简短约定。重新分派评审者前，确认修复报告包含覆盖测试、运行的命令和输出；三者齐全后再分派重新评审。在修复消息中命名覆盖测试文件——单行修复无需整个测试套件。

重新评审是范围化的。 运行

scripts/review-package PLAN_FILE FIX_BASE HEAD

，其中FIX_BASE是上一次评审看到的提交头，并使用发现列表、摘要、报告文件和打印的差异路径分派re-review-prompt.md。重新评审者会判定每个发现为ADDRESSED或NOT ADDRESSED，并仅标记修复差异中的新问题。修复差异中的新Critical/Important问题会加入未解决发现列表。范围外的观察结果会作为延迟Minor记录到分类账中——它们永远不会延长循环。

每一轮后， 追加到分类账：

Task <N>: fix round <R>/5 (<X> addressed, <Y> open — <发现一行描述>; commits <a7>..<b7>)

永远不要在控制器会话中自行修复发现——你的上下文需保持清洁以进行协调，控制器修复会跳过评审。

终止机制。 当第5轮重新评审仍有未解决发现时，停止分派。自行裁决每个未解决的发现——你拥有评审者缺乏的计划和跨任务上下文：

评审者错误，或存在争议： 停放该发现——
```
Task <N>: parked — <发现内容> — Ruling: <代码保留的原因>
```
。最终评审会看到双方的观点。
真实但下游无依赖： 以相同方式停放，裁决说明其真实且延迟修复。
真实且具有承载性——后续任务依赖于它，或揭示了计划缺陷：裁决最小的变更以解除依赖工作的阻塞，记录在分类账中为
```
Task <N>: Ruling: <发现内容> — <你的决策及原因>
```
，并将其带入下一个任务的分派中。静默停放结构性故障会让所有依赖任务基于错误内容构建。仅当缺陷导致所有前进路径均为猜测时才停止。

仅在达到上限时进行裁决。提前裁决以结束循环只是换了个名字的预先判断。每个裁决都是分类账条目——静默丢弃是被禁止的。

5. Complete the task

5. 完成任务

When the review comes back clean — or every open finding is parked with a ruling at the cap — append the completion line to the ledger in the same message as your other bookkeeping:

Task <N>: complete (commits <base7>..<head7>, review clean)

Task <N>: complete (commits <base7>..<head7>, <K> parked)

after a tripped breaker

Then mark the todo complete and move on. Never move to the next task while the review has open Critical/Important issues that are neither fixed nor parked-with-ruling at the cap.

当评审结果干净——或所有未解决发现都已在达到上限时停放并附带裁决——在同一消息中将完成行追加到分类账中，与其他记账内容一起：

Task <N>: complete (commits <base7>..<head7>, review clean)

触发终止机制后：

Task <N>: complete (commits <base7>..<head7>, <K> parked)

然后标记待办事项完成并继续。当评审存在未解决的Critical/Important问题且既未修复也未在达到上限时停放并附带裁决时，永远不要进入下一个任务。

Final Review

最终评审

The final whole-branch review gets a package too: run

scripts/review-package PLAN_FILE MERGE_BASE HEAD

(MERGE_BASE = the commit the branch started from, e.g.

git merge-base main HEAD

) and include the printed path in the final review dispatch, so the final reviewer reads one file instead of re-deriving the branch diff with git commands. Dispatch on the most capable available model (see Model Selection), using sp-requesting-code-review's code-reviewer.md. Point it at the ledger's deferred-minor and parked lines so it can triage which must be fixed before merge.

If the final whole-branch review returns findings, dispatch ONE fix subagent with the complete findings list — not one fixer per finding. Per-finding fixers each rebuild context and re-run suites; a real session's final-review fix wave cost more than all its tasks combined. Then run exactly one scoped re-review of the fix wave (

scripts/review-package PLAN_FILE FIX_BASE HEAD

over the fix range, re-review-prompt.md). Adjudicate any residual findings as in the task loop's breaker: park with rulings, or rule on the load-bearing ones and ledger what you decided. Only the four classes above stop you here. There is no second fix wave — residual load-bearing findings surface to your human partner when finishing-a-development-branch presents the options.

最终的全分支评审也需要一个包：运行

scripts/review-package PLAN_FILE MERGE_BASE HEAD

（MERGE_BASE = 分支起始的提交，例如

git merge-base main HEAD

），并将打印的路径包含在最终评审分派中，这样最终评审者只需读取一个文件，而非通过git命令重新推导分支差异。使用可用的最强大模型分派（见模型选择），使用sp-requesting-code-review的code-reviewer.md。让它指向分类账中的延迟Minor和停放条目，以便它能筛选出合并前必须修复的内容。

如果最终的全分支评审返回发现，分派一个修复subagent，携带完整的发现列表——不要为每个发现分派一个修复者。每个发现一个修复者会重新构建上下文并重新运行测试套件；实际会话中的最终评审修复阶段成本超过所有任务的总和。然后对修复阶段运行一次范围化重新评审（

scripts/review-package PLAN_FILE FIX_BASE HEAD

获取修复范围，使用re-review-prompt.md）。按照任务循环终止机制中的方式裁决任何剩余发现：停放并附带裁决，或裁决具有承载性的发现并记录在分类账中。仅上述四类情况会让你在此处停止。没有第二次修复阶段——剩余的具有承载性的发现会在finishing-a-development-branch呈现选项时告知人类合作者。

Finish

收尾

Before you delete anything, collect every ledger line containing

Ruling:

— preflight rulings, parked findings, breaker adjudications, all of them — into your final message under "Rulings I made", in the order you made them, each with what it costs if wrong. The list is exhaustive: if the ledger holds a ruling, the list holds it. That list is the only place the decisions you took on your human partner's behalf reach them — they read it and rework whatever you got wrong. A ruling that dies with the workspace was a decision made in secret.

When the final whole-branch review is clean and its fixes are merged, delete this plan's workspace (

rm -rf <workspace>

) — the git history is the record now. Sibling directories belong to other plans; leave them alone.

Use superpowers:finishing-a-development-branch.

在删除任何内容之前，收集分类账中所有包含

Ruling:

的行——预检裁决、停放的发现、终止机制裁决等——按做出的顺序放入你的最终消息中“我做出的裁决”部分，每行包含错误决策的代价。列表必须详尽：如果分类账中有裁决，列表中必须包含。该列表是你代表人类合作者做出的决策传达给他们的唯一途径——他们会阅读并修正你出错的地方。随工作区消失的裁决等同于秘密做出的决策。

当最终的全分支评审干净且修复已合并后，删除本计划的工作区（

rm -rf <workspace>

）——git历史现在是记录。兄弟目录属于其他计划；不要触碰它们。

使用superpowers:finishing-a-development-branch。

Common Rationalizations

常见合理化借口

Excuse	Reality
"Close enough on spec compliance"	Reviewer found spec gaps = not done. Fix or hit the cap and adjudicate — those are the only exits.
"I'll fix it myself, dispatching is overhead"	Controller fixes pollute your context and skip review. Resume the implementer.
"One more round will converge"	Past the cap, rounds don't converge — the failure is structural. Adjudicate and route.
"The reviewer will just find something new anyway"	Scoped re-reviews verify fixes; they cannot wander. New findings on untouched code go to the ledger, not the loop.
"This finding is obviously wrong, I'll drop it"	You adjudicate only at the cap, and every ruling is a ledger entry. Silent discards are forbidden.
"The fix was small, skip the re-review"	Unreviewed fixes are how regressions land. Every round ends with a scoped re-review.
"Reviews slow the loop down"	The loop without reviews is just unverified churn. Reviews are the loop's brakes and steering.
"Ledger bookkeeping is overhead"	The ledger is what survives compaction. Controllers without one have re-dispatched entire completed task sequences.
"The implementer spawned its own reviewer — free extra assurance"	It's a duplicate seat reviewing the same diff; the task review is the gate. A worker-spawned reviewer is a defect to flag, not rigor.

借口	实际情况
"规范合规性差不多就行"	评审者发现规范差距 = 未完成。修复或达到上限后裁决——只有这两种退出方式。
"我自己修复，分派太麻烦"	控制器修复会污染你的上下文并跳过评审。恢复实现者。
"再一轮就会解决"	超过上限后，轮次无法解决问题——故障是结构性的。裁决并路由。
"评审者反正会发现新问题"	范围化重新评审仅验证修复；不会偏离主题。未修改代码上的新发现会记录到分类账，而非进入循环。
"这个发现明显错误，我忽略它"	你仅在达到上限时进行裁决，每个裁决都是分类账条目。静默丢弃是被禁止的。
"修复很小，跳过重新评审"	未评审的修复是回归问题的来源。每一轮都以范围化重新评审结束。
"评审会减慢循环速度"	没有评审的循环只是未经验证的混乱。评审是循环的刹车和方向盘。
"分类账记账太麻烦"	分类账是压缩后保留的内容。没有分类账的控制器会重新分派整个已完成的任务序列。
"实现者自己生成了评审者——免费的额外保证"	这是对同一差异的重复评审；任务评审才是关卡。工作者生成的评审者是需要标记的缺陷，而非严谨性。

Example Workflow

示例工作流

You: I'm using Subagent-Driven Development to execute this plan.

[Setup: worktree verified]
[Read plan file once: docs/superpowers/plans/feature-plan.md]
[Resolve workspace: scripts/sdd-workspace docs/superpowers/plans/feature-plan.md — no ledger inside, fresh start]
[Create todos for all tasks]

Task 1: Hook installation script

[Run task-brief for Task 1; dispatch implementer with brief + report paths + context]

Implementer: "Before I begin - should the hook be installed at user or system level?"

You: "User level (~/.config/superpowers/hooks/)"

Implementer: [Later]
  - Implemented install-hook command
  - Added tests, 5/5 passing
  - Self-review: Found I missed --force flag, added it
  - Committed

[Run review-package PLAN_FILE BASE HEAD; dispatch task reviewer with the printed path]
Task reviewer: Spec ✅ - all requirements met, nothing extra.
  Issues: None. Ready to merge: Yes. Task quality: Approved.

[Ledger: Task 1: complete (commits a1b2c3d..d4e5f6a, review clean)]

Task 2: Recovery modes

[Run task-brief for Task 2; dispatch implementer with brief + report paths + context]

Implementer: [No questions]
  - Added verify/repair modes
  - 8/8 tests passing
  - Committed

[Run review-package PLAN_FILE BASE HEAD; dispatch task reviewer with the printed path]
Task reviewer: Spec ❌:
  - Missing: Progress reporting (spec says "report every 100 items")
  Issues (Important): Magic number (100)

[Fix round 1: resume the implementer with both findings]
Implementer: Added progress reporting, extracted PROGRESS_INTERVAL constant.
  Re-ran test/recovery.test.js — 10/10 passing. Fix report appended.

[Run review-package PLAN_FILE FIX_BASE HEAD; dispatch scoped re-review]
Re-reviewer: Missing progress reporting — ADDRESSED (src/recovery.js:41).
  Magic number — ADDRESSED (src/recovery.js:7). New breakage: none.
  Verdict: all findings addressed.

[Ledger: Task 2: fix round 1/5 (2 addressed, 0 open; commits d4e5f6a..b7c8d9e)]
[Ledger: Task 2: complete (commits d4e5f6a..b7c8d9e, review clean)]

...

[After all tasks]
[Run review-package PLAN_FILE MERGE_BASE HEAD; dispatch final code-reviewer, most capable model]
Final reviewer: All requirements met. Deferred minors triaged: none block merge.

[Delete this plan's workspace — the record now lives in git]

Done! Using superpowers:finishing-a-development-branch.

你：我将使用Subagent驱动开发来执行此计划。

[准备工作：验证工作区]
[通读计划文件：docs/superpowers/plans/feature-plan.md]
[解析工作区：scripts/sdd-workspace docs/superpowers/plans/feature-plan.md — 内部无分类账，全新开始]
[为所有任务创建待办事项]

任务1：钩子安装脚本

[为任务1运行task-brief；使用摘要+报告路径+上下文分派实现者]

实现者："开始之前 - 钩子应安装在用户级别还是系统级别？"

你："用户级别 (~/.config/superpowers/hooks/)"

实现者：[稍后]
  - 实现了install-hook命令
  - 添加了测试，5/5通过
  - 自我评审：发现遗漏了--force标志，已添加
  - 提交

[运行review-package PLAN_FILE BASE HEAD；使用打印的路径分派任务评审者]
任务评审者：规范 ✅ - 满足所有要求，无额外内容。
  问题：无。可合并：是。任务质量：已批准。

[分类账：Task 1: complete (commits a1b2c3d..d4e5f6a, review clean)]

任务2：恢复模式

[为任务2运行task-brief；使用摘要+报告路径+上下文分派实现者]

实现者：[无问题]
  - 添加了verify/repair模式
  - 8/8测试通过
  - 提交

[运行review-package PLAN_FILE BASE HEAD；使用打印的路径分派任务评审者]
任务评审者：规范 ❌:
  - 缺失：进度报告（规范要求“每100个项目报告一次”）
  问题（Important）：魔法数字（100）

[修复轮次1：将两个发现发送给实现者恢复任务]
实现者：添加了进度报告，提取了PROGRESS_INTERVAL常量。
  重新运行test/recovery.test.js — 10/10通过。修复报告已追加。

[运行review-package PLAN_FILE FIX_BASE HEAD；分派范围化重新评审]
重新评审者：缺失进度报告 — ADDRESSED (src/recovery.js:41)。
  魔法数字 — ADDRESSED (src/recovery.js:7)。新问题：无。
  结论：所有发现已解决。

[分类账：Task 2: fix round 1/5 (2 addressed, 0 open; commits d4e5f6a..b7c8d9e)]
[分类账：Task 2: complete (commits d4e5f6a..b7c8d9e, review clean)]

...

[所有任务完成后]
[运行review-package PLAN_FILE MERGE_BASE HEAD；使用最强大模型分派最终代码评审者]
最终评审者：满足所有要求。延迟Minor已筛选：无阻碍合并的内容。

[删除本计划的工作区 — 记录现在存储在git中]

完成！使用superpowers:finishing-a-development-branch。