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 RepoPrompt, 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 cognitive-aid body 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, since review rounds are usually where a run’s wall clock goes. host is the middle setting: the gate stays, the second CLI goes. What each setting keeps running is priced in What each layer costs.

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; the verdict is binary (SHIP / NEEDS_WORK) with itemized findings.

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.

Loop until SHIP

The fix → review loop continues until the backend returns SHIP or the user stops. Re-reviews stay in the same session so the reviewer sees the deltas, not the full diff again.

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.

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...
Review round 2: SHIP
Receipt: .flow/review-receipts/fn-12-export-json-flag.json (introduced findings: 0)

The loop is the mechanism: fix and re-review until SHIP, 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>