# Impl Review

Source: https://flow-next.dev/skills/impl-review/

Carmack-level review of implementation changes on the current branch.

`/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](https://flow-next.dev/skills/plan-review/#backend-selection); the full ladder is in [Review backends](https://flow-next.dev/reference/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](https://flow-next.dev/understand/what-each-layer-costs/#turning-the-dial-none-and-host).

## 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

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

```text
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.

* Only *introduced* findings count toward the verdict - the reviewer classifies pre-existing issues separately, so legacy debt cannot hold your diff hostage.
* Pick the reviewer from a different model family than the writer; uncorrelated blind spots are the entire point of cross-model review.
* The loop is capped deterministically (default 8 cumulative rounds since 3.13.3); hitting the cap is an escalation signal, not a retry prompt - see [Troubleshooting](https://flow-next.dev/reference/troubleshooting/#review-loop-stalls-repeats-unchanged-work-or-runs-away).

## Dynamic usage

Recipes that compose with impl-review in the [cookbook](https://flow-next.dev/guides/cookbook/):

* [Model routing](https://flow-next.dev/guides/cookbook/#model-routing) - pin the review backend per task (`review:` value) or per run (`--review=<backend>`).
* [Evidence-first](https://flow-next.dev/guides/cookbook/#evidence-first) - the receipt is queryable state; gate your own scripts on it.
* [Prompt into a stage](https://flow-next.dev/guides/cookbook/#prompt-into-a-stage) - “review only the migration files hard” steers the reviewer without changing the contract.

## Next step

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