Execute the plan by dispatching a fresh implementation subagent for each task: after each task completes, do a task review (spec compliance + code quality), and after all tasks are done, do one broad review covering the entire branch.
Why use subagents: You delegate tasks to specialized agents with isolated context. By carefully designing their instructions and context, you ensure they stay focused and complete the task successfully. 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 principles: One fresh subagent per task + task review (spec + quality) + broad review at the end = high quality, fast iteration
Narration: Say at most one short line of narration between tool calls—the progress ledger and tool results are the record themselves.
Continuous execution: Do not stop between tasks to check in with your human partner. Execute all tasks in the plan without interruption. The only reasons to stop are: a BLOCKED state you cannot resolve, ambiguity that genuinely prevents progress, or all tasks being complete. Questions like "should I continue?" and progress summaries waste their time—they told you to execute the plan, so execute it.
Make rulings, don't stall. A running plan waits for no one. Conflicts, ambiguities, plan flaws, limits you were going to ask to exceed—you decide. The spec is the binding authority, the plan is its argument, and whatever neither can answer is settled by your judgment. Record every decision in the ledger with Ruling: <你决定了什么> — <为什么> — <如果错了代价是什么> , then continue. A wrong ruling costs rework your human partner can see and undo; a session stalled on a question costs them an entire day and buys nothing.
Only four things make you stop, and only these four: irreversible or destructive operations; security-related actions; side effects outside this worktree that by convention warrant asking first (merging, pushing to a shared branch, releasing); and a plan so bad that every path forward requires guessing. When you hit these four, stop and ask.
When to use
digraph when_to_use {
"有实现计划?" [shape=diamond];
"任务基本独立?" [shape=diamond];
"伙伴选了内联执行，或没有子智能体工具?" [shape=diamond];
"subagent-driven-development" [shape=box];
"executing-plans" [shape=box];
"手动执行或先头脑风暴" [shape=box];
"有实现计划?" -> "任务基本独立?" [label="是"];
"有实现计划?" -> "手动执行或先头脑风暴" [label="否"];
"任务基本独立?" -> "伙伴选了内联执行，或没有子智能体工具?" [label="是"];
"任务基本独立?" -> "手动执行或先头脑风暴" [label="否 - 紧密耦合"];
"伙伴选了内联执行，或没有子智能体工具?" -> "executing-plans" [label="是"];
"伙伴选了内联执行，或没有子智能体工具?" -> "subagent-driven-development" [label="否"];
}
Compared with Executing Plans (inline execution):
- One fresh subagent per task (no context contamination), rather than one context handling all tasks
- A review after each task (spec compliance + code quality), rather than reviewing only at the end
- The cost is one fresh context per task and per review; inline execution's cost is one context plus one final reviewer
- Both run in the current session, share the same plan workspace and ledger, and do not pause between tasks
Process
digraph process {
rankdir=TB;
subgraph cluster_per_task {
label="每个任务";
"分派实现子智能体 (./implementer-prompt.md)" [shape=box];
"实现者有疑问?" [shape=diamond];
"回答问题，提供上下文" [shape=box];
"实现者实现、测试、提交、自审" [shape=box];
"生成审查包，分派任务审查者 (./task-reviewer-prompt.md)" [shape=box];
"规格 ✅ 且质量通过?" [shape=diamond];
"发现与计划原文冲突?" [shape=diamond];
"对冲突作出裁决, 把裁决记进账本" [shape=box];
"第 R/5 轮修复: R≤3 唤回原实现者; R≥4 换全新实现者 + 更强模型" [shape=box];
"分派定向复审 (./re-review-prompt.md)" [shape=box];
"所有发现都已解决?" [shape=diamond];
"R = 5?" [shape=diamond];
"逐条裁定未解决的发现" [shape=box];
"存在承重的发现?" [shape=diamond];
"裁决并继续; 只有每条路都靠猜时才停" [shape=box];
"把发现连同裁定搁置进账本" [shape=box];
"往账本追加完成行，标记待办完成" [shape=box];
}
"准备: 工作树、查账本、读计划、起飞前审查" [shape=box];
"还有任务?" [shape=diamond];
"分派最终代码审查者 (../requesting-code-review/code-reviewer.md)" [shape=box];
"最终审查有发现? 一次修复分派、一次定向复审、裁定残留项" [shape=box];
"最终审查干净: 删除本计划的工作区" [shape=box];
"使用 finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];
"准备: 工作树、查账本、读计划、起飞前审查" -> "分派实现子智能体 (./implementer-prompt.md)";
"分派实现子智能体 (./implementer-prompt.md)" -> "实现者有疑问?";
"实现者有疑问?" -> "回答问题，提供上下文" [label="是"];
"回答问题，提供上下文" -> "实现者实现、测试、提交、自审";
"实现者有疑问?" -> "实现者实现、测试、提交、自审" [label="否"];
"实现者实现、测试、提交、自审" -> "生成审查包，分派任务审查者 (./task-reviewer-prompt.md)";
"生成审查包，分派任务审查者 (./task-reviewer-prompt.md)" -> "规格 ✅ 且质量通过?";
"规格 ✅ 且质量通过?" -> "往账本追加完成行，标记待办完成" [label="是"];
"规格 ✅ 且质量通过?" -> "发现与计划原文冲突?" [label="否"];
"发现与计划原文冲突?" -> "对冲突作出裁决, 把裁决记进账本" [label="是"];
"对冲突作出裁决, 把裁决记进账本" -> "第 R/5 轮修复: R≤3 唤回原实现者; R≥4 换全新实现者 + 更强模型";
"发现与计划原文冲突?" -> "第 R/5 轮修复: R≤3 唤回原实现者; R≥4 换全新实现者 + 更强模型" [label="否"];
"第 R/5 轮修复: R≤3 唤回原实现者; R≥4 换全新实现者 + 更强模型" -> "分派定向复审 (./re-review-prompt.md)";
"分派定向复审 (./re-review-prompt.md)" -> "所有发现都已解决?";
"所有发现都已解决?" -> "往账本追加完成行，标记待办完成" [label="是"];
"所有发现都已解决?" -> "R = 5?" [label="否"];
"R = 5?" -> "第 R/5 轮修复: R≤3 唤回原实现者; R≥4 换全新实现者 + 更强模型" [label="否 - 进入下一轮"];
"R = 5?" -> "逐条裁定未解决的发现" [label="是 - 熔断触发"];
"逐条裁定未解决的发现" -> "存在承重的发现?";
"存在承重的发现?" -> "裁决并继续; 只有每条路都靠猜时才停" [label="是"];
"存在承重的发现?" -> "把发现连同裁定搁置进账本" [label="否"];
"把发现连同裁定搁置进账本" -> "往账本追加完成行，标记待办完成";
"往账本追加完成行，标记待办完成" -> "还有任务?";
"还有任务?" -> "分派实现子智能体 (./implementer-prompt.md)" [label="是"];
"还有任务?" -> "分派最终代码审查者 (../requesting-code-review/code-reviewer.md)" [label="否"];
"分派最终代码审查者 (../requesting-code-review/code-reviewer.md)" -> "最终审查有发现? 一次修复分派、一次定向复审、裁定残留项";
"最终审查有发现? 一次修复分派、一次定向复审、裁定残留项" -> "最终审查干净: 删除本计划的工作区";
"最终审查干净: 删除本计划的工作区" -> "使用 finishing-a-development-branch";
}
Preparation
Ensure the work happens in an isolated workspace: create one with using-git-worktrees, or verify the existing one. Never begin implementation on the main/master branch without your human partner's explicit consent.
Session memory cannot survive context compaction. In real sessions, controllers that lost their place have re-dispatched an entire already-completed sequence of tasks—this is the most expensive observed failure. Record progress in a ledger file, not just in a todo list.
- Each plan has its own workspace: When the skill starts, run this skill's
bash scripts/sdd-workspace PLAN_FILE—it prints this plan's dedicated, git-ignored directory (located under<repo-root>/.superpowers/sdd/),this plan'sall artifacts go there: the ledger, briefs, reports, review packages. Other plans' directories are not yours; do not read or write them. - Go to
<工作区>/progress.mdto check this plan's ledger. If its first line names your plan file, then tasks with aTask <N>: completeline arecompleted—do not reassign them; continue from the first task without that line. If a task's last line is a round of fixes, it means it is stuck in a fix loop: continue from the next round. If the ledger's first line namesanotherplan file—or you find a stray ledger at the old flat path.superpowers/sdd/progress.md—that is someone else's progress: leave it in place and start your own new ledger. - When creating the ledger, write its identity on the first line:
# SDD ledger — plan: <计划文件路径>。 - This ledger is your recovery map: the commits it names really do exist in git, even if your context no longer remembers creating them. After compaction, trust the ledger and
git log, not your own memory. git clean -fdxwill destroy this workspace (it is a git-ignored temporary file); if that happens, recover fromgit log.
Read the planthrough once, note its context and global constraints, and create a todo for each task. If the plan names a spec (Spec), read the spec too: the spec is the authority the plan argues from, and conflicts within the plan must be adjudicated against it. If no reachable spec can be found in the plan, record a note in the ledger—any ruling made without a spec is provisional.
Before dispatching task 1, scan the plan once for conflicts, and as you check, write down what you checked:
- Tasks that contradict each other, or that contradict the plan's "global constraints"
- Things the plan explicitly requires but that the review standard would judge as defects (for example, a test that asserts nothing, or a verbatim copy of an entire block of logic)
The output of this scan is atable, not a one-line conclusion. Each pair of tasks that share a file or interface gets one row: the two tasks, one's output against the other's input, and what you found. Each task also gets one row: whether its own text is self-consistent—the tests it specifies against the code it specifies, the files it creates against the files it later touches. "The scan is clean" without these rows does not count as having actually scanned.
Write this table into the ledger. Before execution begins, rule on every item you found—each finding alongside the passage of the plan that requires it—and record each ruling in the ledger. If the scan is clean, do not say more; just start. Rule on every conflict it turns up—the spec is the binding authority, the plan is its argument—record the ruling next to that row, then dispatch task 1. The review loop remains the safety net for those conflicts that surface only during implementation.
Model selection
Provided it is competent, choose the weakest model for each role, to save cost and improve speed.
Mechanical implementation tasks(Isolated functions, clear specifications, 1-2 files): use a fast and cheap model. When the plan is well written, most implementation tasks are mechanical.
Integration and judgment tasks(cross-file coordination, pattern matching, debugging): use a standard model.
Architecture and design tasks: use the strongest model available. The final review covering the entire branch falls into this category—dispatch it with the strongest model available, not the session default model.
Review tasks: use the same judgment to choose the model, and scale it according to the diff's size, complexity, and risk. A small mechanical diff does not need the strongest model; a subtle concurrency change does. For targeted re-review of small fix diffs, a cheap-to-mid tier is sufficient.
Escalation for fix loops (rounds 4-5): use a model at least one tier higher than the implementer that got stuckat least one tier highermodel.
Always explicitly specify the model when dispatching subagents. Omitting the model inherits your session's model—often the strongest and most expensive one—which silently nullifies all the effort in this section.
Round count matters more than token unit price. Wall-clock time and context cost grow with how many rounds a subagent spends, and the cheapest model often takes 2-3x the rounds on multi-step work—making the total bill more expensive instead. Reviewers, and implementers working from prose descriptions, have a mid-tier model as their floor. When the task's plan text already contains the complete code to be written, implementation is copying plus testing: use the cheapest tier for that implementer. Use the cheapest tier for single-file mechanical fixes as well.
Task complexity signals (implementation tasks):
- Involves 1-2 files with complete specifications → cheap model
- Involves multiple files with integration considerations → standard model
- Requires design judgment or broad understanding of the codebase → strongest model
Task loop
Bundle small work of the same shape. When the plan lists several tasks, each a small change of the same kind—the same one-line fix, the same constant replacement, the same field addition, just scattered across different files—do not dispatch one subagent per task. Writeonedispatch brief listing each file and its change, hand the whole batch to the same subagent, and review its diff as a single unit. Reserve one dispatch per task for work that needs its own judgment, its own tests, 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 subsequent round.Hand off artifacts using files.
Waiting for a dispatched subagent: Never poll and wait on an interface with a short timeout, and never just sit in a single silent, unbounded wait. As long as you still have local work to do—updating the ledger, packaging the next review, reading reports—keep doing it; the subagent's results will arrive on their own. When you are truly idle, wait in segments, each with a bound (within what your platform allows, five to ten minutes), send a one-line status between segments, and reconcile the subagents you have that are still alive: list them, and chase down those that finished but did not report. Segmented waiting preserves almost all the efficiency of a long wait while ensuring that a stuck or lost subagent is discovered within minutes rather than dragging on until the end of the session.
1. Dispatch the implementer
Before dispatching, record BASE (git rev-parse HEAD)—the review package and the diffs for each round of fixes will all use it.
- Task brief: Before dispatching the implementer, run this skill's
bash scripts/task-brief PLAN_FILE N—it extracts the task's full text into a uniquely named file and prints the path. Organize your dispatch so that this brief remains the single source of requirements. Your dispatch should contain: (1) one line explaining where this task fits in the project; (2) the brief path, introduced with "read this first—it is your requirements, and it contains the exact values to use verbatim"; (3) interfaces and decisions from prior tasks that the brief cannot know about; (4) your rulings on any ambiguities you noticed in the brief; (5) the report file path and the report contract. Exact values (numbers, magic strings, signatures, test cases) appear only in the brief.Neverhave a subagent read the entire plan file. - Report file: The implementer's report file is named after the brief (brief
…/task-N-brief.md→ report…/task-N-report.md), and is written into the dispatch prompt. The implementer writes the full report there and returns only the status, the commit, a one-line test summary, and concerns. - A dispatch prompt describesone task, not the history of the session. Do not paste accumulated summaries of prior tasks ("state after tasks 1-3") into later dispatches—in a real session there was a 42k-character dispatch, 99% of which was pasted history. What a brand-new subagent needs is: its task, the interfaces it will touch, and the global constraints. Nothing else.
- If some earlier task set aside a finding in the area this task will touch, include in the dispatch a pointer to that ledger entry.
- The dispatch itself carries the contract ofnot dispatching subagents(it is written right in the implementer template): the implementer must never dispatch subagents—no helpers, and certainly no reviewers. Review is delivered by you after the report. In a real session, every reviewer that a worker dispatched on its own was duplicating the task review that the controller would have dispatched anyway—a full extra review seat wasted on every task.
- Record the implementer's agent identity from the dispatch result—rounds 1-3 of fixes need to recall this agent.
- Never dispatch multiple implementer subagents in parallel (they will conflict).
Template:implementer-prompt.md
2. Handle the report
The implementer subagent will return one of four statuses. Handle each accordingly:
DONE： Generate the review package (run bash scripts/review-package PLAN_FILE BASE HEADin this skill's directory—it prints the unique file path it wrote; BASE is the commit you recorded before dispatching the implementer—Never use HEAD~1, that would silently drop all but the last commit in a multi-commit task), then hand the printed path to the task reviewer for dispatch.
DONE_WITH_CONCERNS： The implementer finished the work but raised concerns. Read these concerns before continuing. If a concern is about correctness or scope, resolve it before review. If it is just an observation (e.g. "this file got bigger"), note it and proceed to review.
NEEDS_CONTEXT： The implementer needs information that was not provided. Supply the missing context and re-dispatch.
BLOCKED： The implementer cannot complete the task. Evaluate this blocker:
- If it is a context problem, supply context and re-dispatch with the same model
- If the task needs more reasoning, re-dispatch with a stronger model
- If the task is too large, split it into smaller chunks
- If the plan itself is wrong, adjudicate this correction, record it in the ledger, and carry the adjudication into the re-dispatch prompt
Neverignore an escalation, andneverforce the same model to retry without changing anything. If the implementer says it is stuck, then something must change.
If the implementer asks a question—whether before starting or mid-task—answer it clearly and completely, supply context as needed, and do not rush it into implementation.
3. Review the task
Per-task review isa task-scoped gate. Broad-scope review is done only once, at the final whole-branch review. Never skip task review, and never accept a report missing either conclusion—spec complianceandtask quality must both be present. The implementer's self-review can never replace task review; both are required.
- Hand the diff to the reviewer as a file: run this skill's
bash scripts/review-package PLAN_FILE BASE HEAD, and hand the file path it prints to the reviewer (if there is no bash: rungit log --oneline、git diff --stat、git diff -U10for that range, redirecting to a uniquely named file). These outputs never enter your own context, and the reviewer can see the commit list, stat summary, and full diff with context in a single Read call. Use the BASE you recorded before dispatching the implementer—never useHEAD~1, that would silently truncate a multi-commit task.Neverdispatch a task reviewer without a diff file. - Reviewer's input: The task reviewer gets three paths—the same brief file, the report file, and the review package—plus the global constraints that constrain the task.
- The global constraints block you hand to the reviewer is itsattention lens. From the plan's "Global Constraints" section or the spec,verbatimcopy down the binding requirements: exact values, exact formats, and explicitly specified 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 holding whatthis project's spec requires.
- Do not add open-ended instructions such as "check all usages" or "run a race test if useful" without a concrete, task-specific reason
- Do not make the reviewer rerun tests that the implementer has already run on the same code—the implementer's report carries the test evidence
- Do not pre-judge findings for the reviewer—never instruct the reviewer to ignore or not flag a specific issue. If you believe a finding would be a false positive, let the reviewer raise it, then adjudicate it in the review loop. If a prompt you are writing contains "do not flag", "do not treat X as a defect", "at most handle it as Minor", "the plan chose"—stop: you are pre-judging, and usually to spare yourself one round of the review loop.
The task reviewer may report items marked "⚠️ cannot be verified from the diff"—those that live in unchanged code, or requirements that span tasks. These do not block the rest of the review, but before marking the task completeyou must resolve them one by one yourself: you hold the plan and cross-task context that the reviewer lacks. If you confirm that one of them is a real gap, handle it as a spec review failure—it enters the fix loop along with the other findings.
Template:task-reviewer-prompt.md
4. Fix loop
The loop triggers when the review reports a spec ❌, any Critical or Important finding, or a ⚠️ item that you confirm is a real gap.
Before the loop begins, two paths leave it immediately:
- Minor findingsjot them into the progress ledger (
Task <N>: minor (deferred): <一句话>), and point the final whole-branch review at that list, letting it triage which ones must be fixed before merge.A summary no one reads is a silent discard. Minor findings never enter the loop. - Findings marked "required by the plan"—or any finding that conflicts with what the plan text requires—are yours to adjudicate: weigh the finding next to the plan text, decide with the spec as the binding authority, and record the ruling in the ledger before acting on it. Do not dismiss the finding just because the plan requires it, and do not dispatch a fix that contradicts the plan without a recorded ruling.
Everything else enters the loop.One fix round = one fix dispatch + one targeted re-review. At most five rounds per task.
Rounds 1-3—recall the original implementer (resume). Send the unresolved findingsverbatimto it. Its context is complete: it knows the task, knows the code, knows the choices it made. If your runtime cannot send another message to a live subagent, dispatch a brand-new implementer with the brief path, the report file path, and those findings—either way, the report file is the persistent memory.
Rounds 4-5—dispatch a brand-new implementer with a stronger model(per "Model selection"), with the brief path, the report file path, the unresolved findings, and a framing like this: "a previous implementer attempted this task [N] times; now it is yours. Read the report file to learn what has already been tried." A loop that survives three recalls usually means the implementer cannot see its own problem—fresh eyes plus a capability boost, in one step.
Each round, whichever path is taken: the implementer fixes, reruns the tests covering the changed code, and appends the fix report tothe sameReport file, send back that short contract. Before reassigning the reviewer, first confirm the fix report contains the covering tests, the commands run, and the output; only when all three are complete should you assign the re-review. Name the covering test files in the fix message—a one-line fix does not need the whole package suite.
Re-review is targeted. Run bash scripts/review-package PLAN_FILE FIX_BASE HEAD, where FIX_BASE is the head that the previous review saw, then use re-review-prompt.md to assign, attaching the findings list, the brief, the report file, and the printed diff path. The reviewer gives an ADDRESSED or NOT ADDRESSED conclusion for each finding, andonlyflags new breakage in the fix diff. New Critical/Important breakage in the fix diff is added to the unresolved findings list. Out-of-scope observations go into the ledger as deferred Minor items—they never extend the loop.
After each roundappend to the ledger:
Task <N>: fix round <R>/5 (<X> addressed, <Y> open — <发现的一句话概括>; commits <a7>..<b7>)
Never fix findings yourself in the controller session—your context must stay clean for coordination, and the controller's fixes would skip review.
Circuit breaker. When round 5's re-review still leaves unresolved findings,stop assigning. You adjudicate these unresolved findings one by one yourself—you hold the plan and cross-task context that the reviewers lack:
- The reviewer is wrong, or this point is debatable: set it aside—
Task <N>: parked — <发现> — Ruling: <为什么代码可以维持原样>. The final review will see both sides' accounts. - It is real, but nothing downstream builds on it: also set it aside, with a ruling stating that it is real and deferred.
- Real and load-bearing—later tasks build on it, or it reveals a plan defect: rule on thesmallest change that can unblock the follow-on work, record it in the ledger as
Task <N>: Ruling: <发现> — <你决定了什么，以及为什么>, and carry it into the next task's assignment. Quietly setting aside a structural failure makes every task that depends on it build on top of it. Stop only when this defect leaves every path forward with nothing but guesswork.
Adjudicate only when the cap is reached. Adjudicating early to end the loop is just \"pre-judging\" under another name. Every ruling is a ledger record—silent discarding is forbidden。
5. Complete the task
When the review returns clean—or when the cap is reached and every unresolved finding has been set aside with a ruling—in the same message where you do your other bookkeeping, append the completion line to the ledger:
Task <N>: complete (commits <base7>..<head7>, review clean)- If the circuit breaker was triggered:
Task <N>: complete (commits <base7>..<head7>, <K> parked)
Then mark the todo complete and move on to the next one.Nevermove on to the next task while the review still has unresolved Critical/Important issues that have been neither fixed nor set aside with a ruling at the cap.
Final review
The final review covering the entire branch also gets a review package: run bash scripts/review-package PLAN_FILE MERGE_BASE HEAD(MERGE_BASE = the commit at the branch start, e.g. git merge-base main HEAD), put the printed path into the final review's assignment, so the final reviewer only needs to read one file instead of re-deriving the entire branch diff with git commands. Assign with the strongest available model (see \"Model selection\"), using requesting-code-review's code-reviewer.md. Point it at the ledger's "deferred Minor" and "shelved" rows and have it triage which ones must be fixed before merge.
If the final whole-branch review returns findings, dispatchonefix subagent carrying thecompletefindings list—not one fixer per finding. One fixer per finding means each one rebuilds context and re-runs the test suite; in real sessions, a single final-review fix wave costs more than all of its tasks combined. Then runexactly onetargeted re-review on that fix wave (run bash scripts/review-package PLAN_FILE FIX_BASE HEADon the fix range, with re-review-prompt.md). Residual findings are adjudicated per the task-loop circuit breaker: shelve with a ruling, or make a ruling on the load-bearing ones and record your decision in the ledger. Only the four categories above stop you here.No second fix wave—residual load-bearing findings surface to your human partner when finishing-a-development-branch presents the options.
Wrap-up
Before you delete anything, collect every ledger entry containing Ruling: —preflight rulings, shelved findings, circuit-breaker adjudications, all of them—in the order you made them, into the "Rulings I Made" section of your final message, each with the cost if it was wrong. This list is exhaustive: rulings in the ledger must be in the list. This list is the only place the decisions you made on behalf of your human partner can reach them—they read it and rework what you got wrong. A ruling that disappears along with the workspace is a decision made in the dark.
When the final whole-branch review is clean and its fixes are merged, deletethis plan'sworkspace (rm -rf <工作区>)—git history is the record now. Sibling directories belong to other plans; don't touch them.
Use finishing-a-development-branch.
Common Rationalizations
| Excuse | Reality |
|---|---|
| "Close enough on spec compliance" | A reviewer found spec gaps = not done. Fix them, or go to the cap to adjudicate—those are the only two exits. |
| "I'll just fix it myself, dispatching is extra overhead" | The controller's fixes pollute your context and skip review. Recall the implementer. |
| "One more round will converge" | Past the cap, rounds don't converge—that failure is structural. Adjudicate and route. |
| "The reviewer will always find something new anyway" | A targeted re-review only verifies fixes; it can't wander around. New findings on unchanged code go to the ledger, not the loop. |
| "This finding is obviously wrong, I'll just drop it" | You only adjudicate at the cap, and every adjudication is a ledger record. Silent discards are forbidden. |
| "The fix is small, skip the re-review" | Unreviewed fixes are exactly how regressions happen. Every round ends with a targeted re-review. |
| "Review slows the loop down" | A loop without review is just unverified spinning. Review is the loop's brakes and steering wheel. |
| "The ledger is extra overhead" | A ledger is what survives compaction. No ledger's controller has ever reassigned a fully completed task sequence. |
| "The implementer assigned itself a reviewer—a free extra safeguard" | That would be a duplicate seat, reviewing the same diff at full price, and its ruling wouldn't count. Review is assigned by the controller. |
Example Workflow
你：我正在用子智能体驱动开发来执行这个计划。
[准备：工作树已核实]
[把计划文件读一遍：docs/superpowers/plans/feature-plan.md]
[解析工作区：bash scripts/sdd-workspace docs/superpowers/plans/feature-plan.md —— 里面没有账本，全新开始]
[为所有任务创建待办]
任务 1：Hook 安装脚本
[对任务 1 运行 task-brief；分派实现者，附带简报 + 报告路径 + 上下文]
实现者："开始之前——这个 hook 应该装在用户级还是系统级？"
你："用户级（~/.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 里]
搞定！使用 finishing-a-development-branch。