Impl Review

/flow-next:impl-review runs an adversarial code review on the work currently on your branch.

Like /flow-next:plan-review, the host agent coordinates and the actual review comes from Codex CLI, GitHub Copilot CLI, Cursor CLI, Claude Code CLI, or a host-native fresh-context subagent (host). The output is a review receipt that travels with the branch.

When to use it

Run impl-review on a branch after /flow-next:work has shipped one or more tasks, before /flow-next:make-pr opens the PR. The reviewer sees the diff against base and the spec it implements - code-quality findings surface here; spec-coverage gaps belong to /flow-next:spec-completion-review.

Specifically:

After a batch of tasks lands and you want a second model to catch what your own session missed.
Before opening a PR for a high-stakes change (auth, migrations, public APIs).
When the diff is large enough that the make-pr PR briefing alone won’t surface every concern.

Worker subagents inside /flow-next:work can run impl-review per task via --review=<backend>. Use this skill directly when you want to review the whole branch as a unit instead.

Backend selection

Same resolution as plan-review; the full ladder is in Review backends. Per-task overrides: flowctl task set-backend.

With review.backend none as the standing default this skill exits cleanly without a round, which is a reasonable choice when you read every diff yourself. Attended runs hand the result back first and review in the background, so review rarely holds you up. host is the middle setting: the gate stays, the second CLI goes.

What the reviewer is asked to do

Surface bugs, race conditions, and security issues.
Flag code that contradicts the spec or the repo’s existing conventions.
Distinguish nits from blockers, with itemized findings. The verdict is SHIP, NEEDS_WORK, MAJOR_RETHINK (the approach is wrong: the run stops with BLOCKED: DESIGN_CONFLICT), or NEEDS_HUMAN (the reviewer’s question goes to you).

On a spec with a single task, the review also judges the project’s standing criteria in .flow/criteria.md, because that spec skips completion review. A violated criterion is a finding like any other. Without a criteria file the review runs as before.

To point the reviewers at what matters to you, name the focus when you ask for the review (“review fn-3, focus on concurrency and error handling”), or state a standing review focus in your project’s instructions, such as “reviews focus on over-engineering and YAGNI”. Every reviewer gets the focus, on a single task or the whole branch, the receipt records it, and the re-review keeps it. A focus you name replaces the standing one for that review. Work and flow --auto start their reviews without naming one, so those reviews use the standing focus. Codex reviewers run without your AGENTS.md, so this is how a project’s review focus reaches them.

A focus tells the reviewers where to look harder, and every other check still runs. A standing criterion is a requirement, and a violated one is a finding.

Impl-review does not verify that every acceptance criterion in the spec is satisfied - that is a separate question answered by /flow-next:spec-completion-review. A clean impl-review on incomplete work is possible and expected.

Receipts

Every run writes to .flow/review-receipts/<branch>.json. The receipt records the verdict, findings, file references, and the backend that produced it. /flow-next:make-pr reads these receipts when assembling the PR body so the reviewer’s findings are visible upstream.

Review by risk, then one scoped re-review

Review follows the risk of the change, not its size. A change that touches persisted or shared state, concurrency, security, data layout or migrations, or a multi-file feature, gets three reviewers from another model family; any other change gets one. The panel is the same on every backend and every harness, and the three reviewers’ findings merge into one fix pass. A small local fix to output, wording or display is not reviewed at all, and the run records the skip and its reason.

On NEEDS_WORK the author makes one fix pass, fixing only findings that show the change does the wrong thing, and lists the rest (hardening, broader refactors, problems that predate the change) as follow-ups with a Declined #<n>: <reason> line each in the fix commit. Then one re-review runs: it resumes the reviewer’s session and looks only at the fixes.

Attended, that re-review’s verdict is final. You get the result first, the review runs in the background, and its verdict lands when it is done.
Unattended (flow --auto, with or without --until=merge), or when you ask to “review until SHIP”, the fix and scoped re-review repeat until SHIP, with the round cap and the stall check as the backstop. The stall check stops the loop only after the reviewer marks the same finding not-fixed in three consecutive rounds, and it never refuses a round whose committed fix has not been reviewed yet. When the reviewer keeps only findings the author declined as hardening, scope creep or pre-existing, all below Major, the author may end the loop and records each disagreement, with both sides’ reasons, in the Decisions list and the pull request. A finding that shows a stated requirement broken is always fixed. The verdict in the receipt stays the reviewer’s.

Where it stops

Not a spec-completion check - that’s /flow-next:spec-completion-review. Impl-review can pass code that does not actually satisfy the spec; completion-review is the gate that catches that.
Not a CI substitute. The reviewer reads code; CI runs tests. Both matter.
A review that returns no verdict prints the reviewer CLI’s own last message after CLI message:. When that message reports a usage, credit or spend limit, the review stops with it instead of retrying; top up or switch backend, then run it again. See Troubleshooting.

Worked example

/flow-next:impl-review fn-12-export-json-flag.1

Review round 1 (cross-model backend): NEEDS_WORK
  [Major] introduced: serializer drops rows with a null owner (src/export/json.ts:41)
Fixing finding, re-reviewing the fix...
Re-review: SHIP
Receipt: .flow/review-receipts/fn-12-export-json-flag.json (introduced findings: 0)

One review, one fix pass, one re-review scoped to the fix, with the receipt on disk as the terminal artifact.

Dynamic usage

Recipes that compose with impl-review in the cookbook:

Model routing - pin the review backend per task (review: value) or per run (--review=<backend>).
Evidence-first - the receipt is queryable state; gate your own scripts on it.
Prompt into a stage - “review only the migration files hard” steers the reviewer without changing the contract.

Next step

/flow-next:spec-completion-review <spec-id>
/flow-next:make-pr <spec-id>