delegating-tasks-with-review-gates

Overview

Execute a plan by dispatching one fresh subagent per task, gate each one with a two-stage review before the next task starts, and close with one broader review across the whole branch. A subagent that inherits your session's transcript inherits its dead ends and abandoned approaches along with it — construct exactly what each task needs instead, and nothing it doesn't, so its judgment goes into the task rather than into making sense of a conversation it never joined. The same discipline protects your own context: tracking what's done, ruling on conflicts, holding the cross-task picture no single subagent has reason to hold — that coordination work is what the controller session is for, and it stays clean only if the tasks themselves happen somewhere else.

When to use

• A plan exists — typically written by structuring-an-implementation-plan — and it's ready to execute task by task in the current session.
• Each task should go to a subagent that starts with none of the session's accumulated history: clean judgment instead of a growing transcript to make sense of.
• A task's work needs an independent check — against what it was asked to build and against how well it was built — before the next task is safe to build on top of it.
• Not for: deciding what a delegate may settle on its own when it cannot ask, and what must stop the run instead — bounding-autonomous-work owns the bounds a task is dispatched with; this skill owns the review gates it comes back through.
• Not for: two or more tasks that are genuinely independent of each other and can run concurrently, with nothing gating one on another's result (see fanning-out-independent-work).
• Not for: running a plan's tasks inline in the current session's main thread, with no fresh subagent per task (see working-a-plan-task-by-task).

Before task one

Do this work in an isolated workspace — a worktree or a feature branch, never a shared trunk directly (see isolating-work-with-worktrees for setting one up).

Read the plan once. If it names a spec, read that too: the spec is the authority the plan argues from, and where the two disagree, the spec wins. A plan with no reachable spec still runs, but treat every ruling you make under it as provisional.

Scan the plan once for problems before dispatching task one: tasks that contradict each other or the plan's own global constraints, and anything the plan explicitly mandates that would itself be a defect under review — a test asserting nothing, a logic block duplicated verbatim. Rule on whatever the scan turns up and write down what you decided; a scan that finds nothing is still worth stating, not just skipping in silence.

Keep a running written record outside your own context, updated after every task and every fix round: which tasks are closed, which commits closed them, and every ruling made along the way. If this loop is one phase of a larger run, that record already exists and has a shape — orchestrating-work-end-to-end defines it, and a second file competing with it is two accounts of progress that will disagree. Tick the plan's own - [ ] checkboxes as tasks close, too — a plan written by structuring-an-implementation-plan carries them for exactly this, and letting them drift out of step with your record leaves two accounts of progress that disagree. Compaction erases what you remember; it does not erase that file or git log. Recovering from a lost context means trusting the record and the log over your own recollection — a controller that trusts its memory instead re-dispatches work that's already done, which is the single most expensive mistake this loop can make.

Decide, don't stall

This loop runs to completion without pausing to check in between tasks — that's the point of keeping it in one session instead of routing every step through a person. Conflicts, ambiguities, a plan silent on some edge case: decide them against the spec (the plan is the spec's argument, not the reverse), write down what you decided and why in a line or two, and keep going. A wrong call costs rework someone can see in the record and undo; a session parked on a question it could have answered itself costs the whole session and buys nothing.

A short list of things actually justify stopping to ask: an irreversible or destructive operation, anything security-sensitive, a side effect that reaches outside this workspace — a push to a shared branch, a merge, a publish — or a plan broken enough that every path forward is a guess. Outside that list, rule and continue.

Choosing a model for each role

Use the least capable model that can do the role well, and say which model explicitly every time you dispatch. An unspecified model quietly inherits the session's own, which is usually the most expensive one available and defeats the point.

Role	Default tier
Implementer, task has a complete spec and touches 1-2 files	Cheapest tier — the work is transcription plus testing
Implementer, multi-file integration or real judgment calls	Standard tier
Implementer, architectural or design decisions	Most capable available
Reviewer, any task	Scaled to the diff's size and risk, not fixed to the implementer's tier
Scoped re-review of a small fix	Cheapest-to-mid tier
Fresh implementer after a stuck fix loop	At least one tier above whichever model got stuck
Final whole-branch review	Most capable available, always

Turn count costs as much as per-token price: cheap models routinely take two or three times the turns on multi-step work, which can cost more overall than a mid-tier model would have. Treat mid-tier as the real floor for anything reasoning from prose rather than transcribing an already-fully-specified change.

Dispatch the implementer

Record the commit the task starts from before dispatching. You'll need it as the base of the diff you eventually hand the reviewer — never assume a task's work is one commit and diff against its parent, which silently drops everything but the last commit of a multi-commit task.

Give the subagent exactly what this task needs and nothing else:

• its own requirements, as a self-contained brief — exact values, signatures, and test cases belong here verbatim, not paraphrased into the dispatch prompt
• the interfaces or decisions earlier tasks produced that the brief itself has no way to know about
• a pointer to any earlier parked or deferred finding that touches the same area, so the implementer doesn't reintroduce it
• the global constraints that bind every task
• where to write its report, and the short status contract it should return with

Never the rest of the plan, and never a summary of the session so far — a dispatch describes one task, not the controller's history. Hand over the brief and the report as file paths, not pasted text: anything pasted into a dispatch, or printed back by a subagent, stays resident in your own context for the rest of the session and gets re-read on every later turn.

Dispatch one implementer at a time. Two working the same tree at once is a conflict waiting to resolve itself badly. Invite questions before it starts work and answer them completely — an implementer that guesses instead of asking is a defect in the dispatch, not in the implementer. The implementer never spawns subagents of its own, and especially never a reviewer of its own: the review seat is already scheduled, dispatched by you once the report lands, and a self-spawned second opinion duplicates it at full cost while counting for nothing.

If several tasks in the plan are the same small edit repeated across files — the same constant, the same one-line fix — compose one dispatch listing every file and its change rather than one subagent per task, and review the batch as a single diff. Save one-dispatch-per-task for work that actually needs its own judgment, its own tests, or its own review.

Template: reference/implementer-prompt.md

Where the harness lists this plugin's agent types (Claude Code and Copilot CLI offer tbaguette-atelier:implementer, tbaguette-atelier:reviewer and tbaguette-atelier:investigator), dispatch the role by its type rather than a general-purpose agent. Each type already carries its template's standing discipline, from "You Do Not Dispatch Subagents" on, so the dispatch holds only the task-specific part. The reviewer and investigator have no edit or write tool, but they keep a shell, so that limits their tools rather than guaranteeing they cannot write. None pins a model, so name one in every dispatch, per "Choosing a model for each role" above.

Handle what comes back

Status	What it means	What you do
DONE	Work complete, self-reviewed, committed	Move to review
DONE_WITH_CONCERNS	Complete, but the implementer has doubts	Read the concerns first — resolve anything about correctness or scope before review; note-only observations can wait for review
NEEDS_CONTEXT	Missing information blocked progress	Supply what's missing, re-dispatch
BLOCKED	Cannot complete as given	Diagnose why, then act
no status at all	The run was ended by a ceiling — turns, output size, timeout, crash — before it could report	Treat as incomplete of unknown extent; re-dispatch for the remainder. Never as DONE

Four of those rows are statuses a delegate chose. The fifth is the absence of a choice, and it is the one that costs the most, because it is the only outcome the delegate cannot tell you about. Every delegation system has ceilings — a turn limit, an output-size limit, a wall-clock timeout, a cut stream, a crash, a process killed from outside — and a run that hits one ends mid-sentence. What arrives is the work done so far plus whatever prose happened to be in flight, which frequently reads like a summary of a finished task, because the delegate believed it was going to finish.

That failure is invisible at exactly the point it should be caught. Route it as DONE and the task-scoped reviewer gets the diff and the brief, finds the half that exists to be correct, and has nothing to notice the missing half with — reviewers check what is in front of them against the task, and a truncated diff is internally consistent. So the check belongs upstream of review, and it is mechanical rather than interpretive: the dispatch record is the authority on whether all of it came back, not the delegate's closing prose. Compare what was asked for against what the diff actually contains, item by item, before anything else looks at it. A delegate that stopped without a status re-dispatches for the remainder; it does not get read charitably.

A BLOCKED report is a signal to change something, not a cue to retry unchanged: more context if the gap is understanding, a stronger model if the task needs more reasoning than the current one has, a smaller task if it's simply too large, or a correction — ruled on and recorded — if the plan itself is wrong. Forcing the same model to retry a task it already called too hard wastes the round and tells you nothing new.

If the implementer asks questions, mid-task or before starting, answer in full before it continues. Don't rush a subagent into work it flagged as unclear.

Why the gate below is structural, and what that means when you want to skip it

The row above is about a run that was cut off. The more expensive case is a run that finished, checked its own work, and reported DONE about something it did not do — and the useful thing to know about it is that it does not respond to instructing the delegate more firmly.

What moves it is whether anything other than the delegate can observe the end state. Where the delegate's own account is the only channel, a substantial share of its failures come back labelled as successes; where a second party can look at the result independently, that share drops sharply. The effect is much larger than the difference between a careful delegate and a sloppy one, and there is no sign of it shrinking as delegates improve. That is the whole reason the two-stage review below is written as a fresh reviewer against the diff rather than as a stronger instruction to self-review: the gate is doing structural work, not diligence work, and trimming it to save a round removes the only mechanism here that is known to move the number.

So when the gate is inconvenient, the substitution to refuse is "have the implementer check more carefully". The substitution to reach for is any other observer of the same end state — a test the work must actually make pass, an artifact someone else inspects, a system whose state visibly changed.

One forensic tell is worth carrying into the review itself, because it is cheap and the existing dispatch-record check does not cover it. Judging a completion claim by how it is written is close to guessing: assurance is a property of prose and varies independently of whether the work happened, so a confident report reads better than a truthful one. What separates them sits on a different channel. A false completion is characteristically a record of looking — reads, searches, inspections — with nothing in it that could have caused the effect being claimed. Before weighing the summary, find the actions in the trace that changed something. A run claiming a fix with no write, no commit, and no command that mutates has answered the question already.

The two-stage review

Every task gets a fresh reviewer against its diff before the next task starts — never the implementer that built it, and never a reviewer the implementer spawned itself. This is a task-scoped gate, not the broad review; that happens once, at the end, across the whole branch.

The reviewer returns two verdicts, and both are required. Neither substitutes for the other, and the implementer's own self-review substitutes for neither:

• Spec compliance — does the diff match what the task asked for: nothing missing, nothing extra, nothing solved the wrong way.
• Code quality — is it well-built: clean separation, real error handling, tests that verify behavior rather than mocks, no file quietly outgrowing its one job.

Give the reviewer a real scope, not an open-ended one: the diff and the brief, plus the global constraints copied verbatim from the plan or spec — exact values, exact formats, the relationships between components the plan actually states. It should read the diff and the implementer's report, not crawl the wider codebase or re-run a suite the implementer already ran and reported on; a focused check is warranted only against a specific, named doubt. Never pre-judge a finding for it — "don't flag X" or "at most Minor" is you grading the work in advance, which is exactly what the second reviewer exists to avoid.

The reviewer may flag a requirement it cannot verify from the diff alone — something that lives in unchanged code or spans several tasks. That doesn't block anything by itself, but it's yours to resolve, not the reviewer's: you hold the cross-task context it doesn't. Confirm it one way or the other; a confirmed gap is a failed spec review and enters the fix loop like any other finding.

Template: reference/reviewer-prompt.md, full-review mode.

An approval that does not name what it approved is a bearer token

A gate split across two exchanges — approve here, act there — has to carry the approval between them, and the carrier travels through the very party the gate exists to constrain. That part is unavoidable. What is avoidable is a carrier recording only that approval happened.

The actor here is you, holding a person's yes — not a delegate holding a clearance, which is bounding-autonomous-work's territory and not this skill's. It bites at the places Decide, don't stall already stops to ask: an irreversible or destructive operation, a push to a shared branch, a merge, a publish. An approval reduced to a flag is a bearer credential for the next one of those, of any shape. A plan approved in one turn is executed in another after the plan moved; a resumed run presents an approval obtained before the parameters it now holds. Nothing has to be adversarial for this to bite — the ordinary case is a run that sincerely believes it is still doing the approved thing.

So the load-bearing content of an approval is a digest of what was approved — the actual parameters, paths, or diff, never a description of them — scoped by something that can go stale on its own. The base commit the dispatch record already names does that job: when it moves, the approval is spent. At the point of action, re-read the digest and compare it field by field against what you are about to do, rather than acting on what the session currently believes those fields are. A mismatch stops the operation.

checkpointing-long-runs names the version that crosses a context boundary: a verdict recorded against a role rather than against content re-binds on restore to whatever now occupies that role. Same defect, different transport.

A gate has a throughput, past which a yes carries no information

Most gates above are answered by a dispatched reviewer, and what those cost is tokens and turns — the model-choice section already prices them. A few are answered by a person: the list in Decide, don't stall, plus every approval this skill asks you to carry. Those are a different resource, and the one that is never budgeted. An oversight gate answered by a human is a channel with a finite capacity, and a design raising one wherever a stop might help is not being careful — it is overdrawing the account the gates that matter are also drawn against.

Three effects compound, and the middle one is the counter-intuitive half:

• Past some rate, an approver stops evaluating and starts pattern-matching. The reading is not skipped deliberately — the answer simply arrives before the reading does, and it is almost always yes, because it almost always should be.
• The better the delegate performs, the less scrutiny each approval receives. A long run of correct proposals is exactly what trains the reflex, so the rare wrong one arrives at the moment of least attention. Reliability does not make oversight cheaper; it makes it weaker, and it does so silently.
• The costs are asymmetric in the wrong direction. Approving costs a keystroke, and rejecting costs a conversation, a delay, and being the person who slowed it down. That gradient does not need anyone to be careless to bend the outcomes.

The failure is invisible from inside, because a saturated gate and a healthy one produce the same artifact — a run of approvals. Nothing distinguishes an approver who read forty diffs from one who acknowledged forty, and neither the log nor the delegate can tell them apart.

So spend the budget deliberately:

• Stratify by blast radius, not by felt uncertainty. Uncertainty is the delegate's own estimate and it is the thing under test. What is irreversible, outward-facing, or expensive is a property of the action, and it is the honest axis to gate on.
• Ask once per coherent change, not once per fragment. Eleven prompts about one decision get acknowledged eleven times; the decision gets read once. Dispatch the implementer already applies this to the same small edit repeated across files — one dispatch, reviewed as a single diff — and the reason there is the reason here. Note the boundary: the per-task gate above is deliberately one review per task, and it is exempt because a machine answers it. Fragmenting is only free where nobody is paying attention for it.
• *The checkable rule: if you cannot say what a no would change, it is not a gate.* It is a notification wearing a gate's interface, and it is spending the same attention. Turn it into a line in the report.

When review finds problems: the fix loop

Two kinds of finding leave the loop before it starts:

• Minor findings get noted in the running record and deferred to the final review, which decides what actually needs fixing before merge. They never trigger a round.
• A finding that conflicts with what the plan's text actually mandates is yours to rule on, the same way any plan conflict is: weigh it against the spec, decide, write down why. Don't dismiss the finding just because the plan called for it, and don't dispatch a fix that overrides the plan without a recorded ruling either.

Everything else enters the loop. One round is one fix dispatch plus one scoped re-review:

• Early rounds resume the implementer that did the work. It still has the task, the code, and its own reasoning intact — hand it the open findings verbatim.
• A loop that survives a couple of rounds with the same implementer is usually telling you it can't see its own problem, not that it needs one more try. Move to a fresh implementer with no sunk cost in the current approach, on a model at least one tier stronger, and say plainly that a prior attempt is written up in the report file for it to read.
• Every round ends the same way. The implementer fixes, re-runs the tests that cover the amended code, and appends a fix report: what changed, which tests, the command, the output. Then a re-review, scoped to exactly two questions — was each finding actually addressed, and did the fix itself break something new. Anything the re-reviewer notices outside that scope goes to the deferred list, not back into the loop. Template: reference/reviewer-prompt.md, scoped-re-review mode.

Give the loop a small, fixed cap rather than letting it run open-ended. A loop that hasn't converged in a handful of rounds is a structural problem, and more rounds spent hoping is not a strategy. At the cap, stop dispatching and adjudicate every open finding yourself:

• Wrong, or genuinely arguable: park it, with the reasoning recorded, so the final review sees both sides.
• Real, but nothing later depends on it: park it too, with a ruling that says it's real and deliberately deferred.
• Real and load-bearing — a later task builds on it, or it reveals a defect in the plan itself: rule on the smallest change that unblocks what depends on it, record what you decided, and carry that ruling into the next task's dispatch.

Every adjudication is a recorded ruling. A finding dropped with no line explaining why is a defect that will resurface later with no memory of why it was let go.

Close the task once its review is clean, or once every remaining finding is parked or ruled at the cap — never earlier, and never move to the next task while a Critical or Important finding sits neither fixed nor resolved.

When a finding points backward, not forward

Most findings are about the task just reviewed. Occasionally one isn't — Task 6's review reveals that Task 2's interface choice, already closed and built on by three tasks since, was wrong. This is worse than an ordinary load-bearing finding, because the damage isn't pending, it's already shipped: don't fold it into Task 6's fix loop as though Task 6 caused it. Stop, name which earlier task the finding actually belongs to and what's been built on top of it since, and treat it the way a load-bearing finding at the cap is treated — surfaced to your human partner, not silently absorbed into whichever task happened to be open when it was noticed. The running record you've kept since before task one is what makes this findable at all: without it, "Task 2 was wrong" has no way to become "and Tasks 3 through 5 inherited it," because nothing recorded what those tasks actually depended on.

The final review

Once every task is done, dispatch one review across the whole branch — not per-task scope this time, and on the most capable model available regardless of what individual tasks used. Compose that dispatch the way handing-off-for-review describes: what was built, what it should do, the exact range, and the shape you want the findings back in. Hand it the running list of deferred minors and parked findings too, so it triages what actually blocks merge instead of rediscovering all of it from nothing.

If it finds something, fix the whole list in one dispatch — not one fixer per finding, which rebuilds context and reruns the suite for each one at a cost that can exceed every task that came before it — then run exactly one scoped re-review of that fix. Adjudicate whatever's left the same way the task loop's cap works: park it or rule on it, and record which. There's no second fix wave; anything load-bearing left after that surfaces to whoever owns the branch next.

Once the final review is clean, this skill's job is done. How the branch actually lands — merge, pull request, or something else — belongs to landing-a-finished-branch, not here.

Common mistakes

Symptom	Real cause
A task marked complete with an open spec gap	"Close enough" stood in for a clean verdict — a failed spec check is not done, only fixed or parked-with-a-ruling
The controller edits code directly mid-review	Fixing in the controller session skips the review gate it's supposed to protect, and pollutes the context that's supposed to stay clean
A fix round runs six, seven, eight times on the same task	No fixed cap — rounds kept being spent hoping instead of adjudicating a structural failure
A fix ships with no re-review because it "was small"	Small fixes regress too; skipping the re-review is how they land unseen
The next task dispatches before this one's review is clean or parked	The task loop's gate was treated as optional under time pressure
A dispatch prompt balloons with several tasks' worth of pasted history	Session history got pasted in instead of handed over as an interface the brief states plainly
The implementer's self-review stands in for the task review	Self-review and independent review catch different things; one was skipped, not just deferred
An implementer spawns its own reviewer and the controller treats that as covered	A duplicate review seat, not a second opinion — the real review still has to run
A defect traced back to an earlier, already-closed task	Treated as the current task's finding instead of raised against the task that actually owns it
An approval given early authorizes a wider action much later	The approval recorded that a yes happened, not what it was a yes to
A delegate reported DONE and nothing it claimed had happened	Its own account was the only channel the end state was observable through

Red flags

• Answering a leaky review gate by asking for a more careful reader of reports.
• "The self-review already looked thorough, I'll skip the task review this once."
• "One more fix round will probably converge" — said again, past the point where it already didn't.
• "I'll just fix this myself instead of dispatching, it's faster."
• "This finding is obviously wrong, I'll drop it" — with nothing written down about why.
• "Should I continue?" surfacing after a task that closed clean, with nothing that called for a stop.
• A dispatch prompt that includes "here's everything that happened in the tasks before this one."
• Reviewing this task's diff with the previous task's context still doing the judging.

Dispatch a fresh subagent:
  description: "Implement Task N: [task name]"
  model: [MODEL — REQUIRED: choose per SKILL.md's "Choosing a model for each role" table. An
         unspecified model silently inherits the session's own, usually the
         most expensive one available.]
  prompt: |
    You are implementing Task N: [task name]

    ## Task Description

    Read your task brief first: [BRIEF_FILE]
    It contains the full task text from the plan.

    ## Context

    [Scene-setting: where this fits, dependencies, architectural context]

    ## Before You Begin

    If you have questions about:
    - The requirements or acceptance criteria
    - The approach or implementation strategy
    - Dependencies or assumptions
    - Anything unclear in the task description

    **Ask them now.** Raise any concerns before starting work.

    ## Your Job

    Once you're clear on requirements:
    1. Implement exactly what the task specifies
    2. Write tests (following TDD if the task says to)
    3. Verify the implementation works
    4. Commit your work
    5. Self-review (see below)
    6. Report back

    Work from: [directory]

    **While you work:** if you encounter something unexpected or unclear,
    ask questions. It's always OK to pause and clarify — don't guess or
    make assumptions.

    While iterating, run the focused test for what you're changing; run the
    full suite once before committing, not after every edit.

    ## You Do Not Dispatch Subagents

    Do all of this task's work yourself. Never spawn a subagent to
    implement part of the task, and above all never spawn a reviewer to
    check your work. Self-review (below) means reading your own diff.
    Review is the controller's job: after you report, it dispatches a
    fresh reviewer against your diff. A reviewer you spawn duplicates
    that review at full cost, and its approval counts for nothing in
    the process. If you catch yourself thinking "an independent review
    would strengthen my report," that review is already scheduled —
    report instead.

    ## Code Organization

    You reason best about code you can hold in context at once, and your
    edits are more reliable when files are focused. Keep this in mind:
    - Follow the file structure the plan defines
    - Each file should have one clear responsibility with a well-defined interface
    - If a file you're creating is growing beyond the plan's intent, stop and
      report it as DONE_WITH_CONCERNS — don't split files on your own without
      plan guidance
    - If an existing file you're modifying is already large or tangled, work
      carefully and note it as a concern in your report
    - In an existing codebase, follow its established patterns. Improve code
      you're touching the way a good developer would, but don't restructure
      things outside your task.

    ## When You're in Over Your Head

    It is always OK to stop and say "this is too hard for me." Bad work is
    worse than no work. You will not be penalized for escalating.

    **STOP and escalate when:**
    - The task requires architectural decisions with multiple valid approaches
    - You need to understand code beyond what was provided and can't find clarity
    - You feel uncertain about whether your approach is correct
    - The task involves restructuring existing code in ways the plan didn't anticipate
    - You've been reading file after file trying to understand the system without progress

    **How to escalate:** report back with status BLOCKED or NEEDS_CONTEXT.
    Describe specifically what you're stuck on, what you've tried, and what
    kind of help you need. The controller can provide more context,
    re-dispatch with a more capable model, or break the task into smaller
    pieces.

    ## Before Reporting Back: Self-Review

    Review your work with fresh eyes. Ask yourself:

    **Completeness:**
    - Did I fully implement everything in the spec?
    - Did I miss any requirements?
    - Are there edge cases I didn't handle?

    **Quality:**
    - Is this my best work?
    - Are names clear and accurate (matching what things do, not how they work)?
    - Is the code clean and maintainable?

    **Discipline:**
    - Did I avoid overbuilding (YAGNI)?
    - Did I only build what was requested?
    - Did I follow existing patterns in the codebase?

    **Testing:**
    - Do tests actually verify behavior, not just mock behavior?
    - Did I follow TDD if required?
    - Are tests comprehensive?
    - Is the test output pristine — no stray warnings or noise?

    If you find issues during self-review, fix them now, before reporting.
    Self-review is real and worth doing, but it does not replace the task
    review that follows — a second, independent reviewer is still coming.

    ## After Review Findings

    If the task review finds issues, you will be resumed with the findings.
    Fix them, re-run the tests that cover the amended code, and append a fix
    report to your report file: what you changed, the covering tests you
    ran, the command, and the output. The reviewer will not re-run tests for
    you — your report is the test evidence. Then reply with the same short
    status contract as your first report.

    ## Report Format

    Write your full report to [REPORT_FILE]:
    - What you implemented (or what you attempted, if blocked)
    - What you tested and the test results
    - **TDD evidence** (if TDD was required for this task):
      - RED: command run, the relevant failing output before implementation,
        and why that failure was expected
      - GREEN: command run and the relevant passing output after implementation
    - Files changed
    - Self-review findings, if any
    - Any issues or concerns

    Then report back with ONLY the following (under 15 lines — the detail
    lives in the report file):
    - **Status:** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
    - Commits created (short SHA + subject)
    - One-line test summary (e.g. "14/14 passing, output pristine")
    - Your concerns, if any
    - The report file path

    If BLOCKED or NEEDS_CONTEXT, put the specifics in the final message
    itself — the controller acts on it directly.

    Use DONE_WITH_CONCERNS if you completed the work but have doubts about
    correctness. Use BLOCKED if you cannot complete the task. Use
    NEEDS_CONTEXT if you need information that wasn't provided. Never
    silently produce work you're unsure about.

Your review is read-only on this checkout. Do not mutate the working tree,
the index, HEAD, or branch state in any way.

## You Do Not Dispatch Subagents

Do all of this review yourself. Never spawn a subagent to review part of
the diff, and never spawn another reviewer for a second opinion. This
process already provides every review seat the work gets; a reviewer you
spawn duplicates one of them at full cost, and its verdict counts for
nothing. If the diff feels too large for one pass, review it in passes
yourself and say so in your report.

## Do Not Trust the Report

Treat the implementer's report as unverified claims about the code, not as
fact. It may be incomplete, inaccurate, or optimistic — verify every claim
against the diff. A stated rationale for a design choice is a claim too:
"kept it simple deliberately," "left it per YAGNI," or any other
justification is the implementer grading its own work, and on its own it
never downgrades a finding's severity.

## Tests

Do not re-run the suite to confirm what's reported. Run a focused test
only when reading the code raises a specific doubt that no existing run
answers, and then a single focused test — never a package-wide suite, a
race-detector run, or a repeated/high-count loop. If heavy validation
seems warranted, recommend it in your report instead of running it
yourself. If you cannot run commands in this environment, name the test
you would run.

Warnings or other noise in reported test output are findings in
themselves — test output should be pristine.

Evidence you cannot see is not evidence that doesn't exist. If a report or
its test evidence looks truncated, or you can't locate results it claims,
re-read the file at its stated path before concluding it's genuinely
missing. Re-running something to regenerate what you failed to read is not
verification, and illegible evidence is not invalidated evidence.

## Calibration

Categorize every finding by actual severity. Not everything is Critical.
Important means the work cannot be trusted until this is fixed: incorrect
or fragile behavior, a missed requirement, or maintainability damage you'd
block a merge over — verbatim duplication of a logic block, a swallowed
error, a test that asserts nothing. Broader-coverage suggestions and
polish are Minor.

If the brief or plan explicitly mandates something this discipline calls a
defect, that is still a finding — report it as Important, labeled
plan-mandated. The plan's own authorship does not grade its own work.

Acknowledge what was done well before listing problems. Accurate praise is
part of what makes the rest of the feedback worth trusting.

Dispatch a fresh subagent:
  description: "Review Task N (spec + quality)"
  model: [MODEL — REQUIRED: choose per SKILL.md's "Choosing a model for each role" table,
         scaled to this diff's size and risk.]
  prompt: |
    You are reviewing one task's implementation: first whether it matches
    its requirements, then whether it is well-built. This is a
    task-scoped gate, not a merge review — a broad whole-branch review
    happens separately once every task is complete.

    ## What Was Requested

    Read the task brief: [BRIEF_FILE]

    Global constraints from the spec or plan that bind this task:
    [GLOBAL_CONSTRAINTS]

    ## What the Implementer Claims They Built

    Read the implementer's report: [REPORT_FILE]

    ## Diff Under Review

    **Base:** [BASE_SHA]
    **Head:** [HEAD_SHA]
    **Diff file:** [DIFF_FILE]

    Read the diff file once — it holds the commit list, a stat summary,
    and the full diff with surrounding context, and it is your view of
    the change. The diff's context lines ARE the changed files: do not
    read a changed file separately unless a hunk you must judge is cut
    off mid-function, and say so in your report if that happens. Do not
    crawl the broader codebase. Inspect code outside the diff only to
    evaluate a concrete risk you can name — one focused check per named
    risk, naming both the risk and what you checked. Cross-cutting
    changes are legitimate named risks: if the diff changes lock
    ordering, a function or API contract, or shared mutable state,
    checking the call sites is the right method.

    [SHARED REVIEWER DISCIPLINE — insert the block from this file's
    "Shared reviewer discipline" section, verbatim]

    ## Part 1: Spec Compliance

    Compare the diff against What Was Requested:

    - **Missing:** requirements skipped, missed, or claimed without being
      implemented
    - **Extra:** features that weren't requested, over-engineering,
      unneeded "nice to haves"
    - **Misunderstood:** the right feature built the wrong way, or the
      wrong problem solved

    If the brief lists several files each with its own change (a batched
    dispatch), check the diff against that list file by file: every
    listed file must have its corresponding hunk. A listed file the diff
    never touches is a Missing finding, no matter how clean the rest of
    the batch looks.

    If a requirement cannot be verified from this diff alone — it lives
    in unchanged code, or spans tasks — report it as a flagged item
    instead of broadening your search.

    ## Part 2: Code Quality

    **Code quality:**
    - Clean separation of concerns?
    - Proper error handling?
    - DRY without premature abstraction?
    - Edge cases handled?

    **Tests:**
    - Do the new and changed tests verify real behavior, not mocks?
    - Are the task's edge cases covered?

    **Structure:**
    - Does each file have one clear responsibility with a well-defined interface?
    - Are units decomposed so they can be understood and tested independently?
    - Does the implementation follow the file structure the plan set out?
    - Did this change create new files that are already large, or grow
      existing ones significantly? (Don't flag pre-existing file sizes —
      focus on what this change contributed.)

    Point at evidence: give a file:line reference for every finding, and
    for any check you'd otherwise answer with a bare "yes."

    Your final message is the report itself: begin directly with the
    spec-compliance verdict. Every line is a verdict, a finding with
    file:line, or a check you ran — no preamble, no process narration, no
    closing summary.

    ## Output Format

    ### Spec Compliance

    - Compliant, or issues found: [what's missing/extra/misunderstood,
      with file:line references]
    - Cannot verify from diff: [requirements you could not verify from
      the diff alone, and what the controller should check — report this
      alongside the compliant/issues verdict for everything you could
      verify]

    ### Strengths
    [What's well done? Be specific.]

    ### Issues

    #### Critical (Must Fix)
    #### Important (Should Fix)
    #### Minor (Nice to Have)

    For each issue: file:line, what's wrong, why it matters, and how to
    fix it if that's not obvious.

    ### Assessment

    **Task quality:** [Approved | Needs fixes]

    **Reasoning:** [1-2 sentence technical assessment]

Dispatch a fresh subagent:
  description: "Re-review Task N fix round R"
  model: [MODEL — REQUIRED: choose per SKILL.md's "Choosing a model for each role" table.
         Scoped re-reviews of small fix diffs usually take a
         cheap-to-mid tier.]
  prompt: |
    You are re-reviewing one task's fix round. A previous review produced
    findings; an implementer has attempted to fix them. Your job is to
    verdict each finding and inspect the fix diff — nothing else.

    ## The Task

    Read the task brief: [BRIEF_FILE]

    ## The Findings Under Verification

    [FINDINGS]

    ## The Fix

    Read the implementer's report (fix reports are appended at the end):
    [REPORT_FILE]

    **Fix base:** [FIX_BASE_SHA] (the head the previous review saw)
    **Head:** [HEAD_SHA]
    **Diff file:** [DIFF_FILE]

    Read the diff file once — it holds the fix commits, a stat summary,
    and the fix diff with surrounding context.

    [SHARED REVIEWER DISCIPLINE — insert the block from this file's
    "Shared reviewer discipline" section, verbatim]

    ## Scope

    Your scope is the findings list and the fix diff. Verdict every
    finding. Inspect the fix diff for new problems the fix itself
    introduced. Do not re-review code the fix did not touch: if you
    notice an issue entirely outside the fix diff, report it under
    Out-of-Scope Observations — it does not block this task and does not
    extend the loop. A broad whole-branch review happens once every task
    is complete.

    ## Output Format

    Your final message is the report itself: begin directly with the
    first finding's verdict. Every line is a verdict, a finding with
    file:line, or a check you ran — no preamble, no process narration.

    ### Finding Verdicts

    For each finding in The Findings Under Verification, in order:
    - **[finding one-liner]** — Addressed or Not addressed, with
      file:line evidence. Attempted is not addressed: the specific
      defect must no longer exist.

    ### New Breakage in the Fix Diff

    Anything the fix itself broke or introduced, with severity
    (Critical/Important/Minor) and file:line. "None" if clean.

    ### Out-of-Scope Observations

    Issues noticed entirely outside the fix diff. Non-blocking; the
    controller carries these into the final review. "None" if none.

    ### Verdict

    **Fix round:** [All findings addressed, no new Critical/Important
    breakage | Findings remain open] — list the open ones.

git log --oneline BASE..HEAD
git diff --stat BASE..HEAD
git diff -U10 BASE..HEAD