The reviewer

The agent that spent forty steps writing a patch is the worst judge of it. It remembers why each line looked right as it typed them.

The reviewer carries none of that. No transcript, no plan it defended, no memory of the argument. It opens the files that changed, reads them cold, and closes with one line your tooling can act on:

VERDICT: PASS — [what was verified]
VERDICT: FAIL — [file:line, what is wrong]
VERDICT: PARTIAL — [what could not be verified and why]

One agent, three doors: /review runs it once, /goal runs it after every round of its loop, and --review turns the verdict into a CI exit code.

Ask for one

/review
/review check the error paths, not the happy path

The brief is optional. Write one and your words become the setpoint it judges against first. Leave it empty and it judges correctness over whatever your lane touched.

Empryo blocks a review while work is in flight: a streaming turn, a background agent still writing files, a goal loop that owns the lane. A judge reading a tree that keeps moving reports on a state that no longer exists by the time you read it. The button tells you which one is holding it, and lights again when the lane settles.

Type while it judges and your line reaches the reviewer at its next step. Those notes stay out of the transcript. The coder reads that transcript back on its next turn, and instructions meant for a judge would land as instructions for it.

What lands in scope

Empryo takes the first rung that has files in it:

With four tabs open, each /review judges its own lane. Nothing on any rung ends the run before a model starts, so a clean tree costs you nothing.

Scope caps at 30 files, and every verdict names the rung behind it. You can tell "the four files this lane wrote" from "whatever is uncommitted" without reading the file list.

Rungs 1 and 2 carry +N/−M per file, measured against the content captured before the session's first edit of it. Those snapshots live in the process. Restart, and a restored lane drops to the git rung, which the report tells you.

Deleted files stay in scope, marked. The reviewer never tries to open one; it checks what used to import or call it, because a removal that leaves callers behind is the regression you wanted caught.

Acting on a verdict

Apply stays manual. A verdict that feeds itself back to the coder is a loop, and `/goal` already runs that loop with an escalation ladder and a stop condition.

Each tab keeps its last 8 verdicts with their reports, through a reload and a session restore. A re-review seeds the previous report as *context to verify, not truth*, so the second judge re-earns every claim the first one made.

In CI

empryo --headless --review
empryo --headless --review "check the migration for data loss"
empryo --headless --review --json

- name: Review the diff
  run: empryo --headless --review --quiet

A clean tree reports verdict: null, never PASS. Nothing was judged, and a green tick there would tell your pipeline the code had been checked.

Which model judges

The task router's review slot, falling back to goalReview, then to the model your lane already runs. Spend the money here: a judge that misses the bug costs more than the tokens it saved. Reviewer spend lands in the tab's totals like any other side agent, so you can see what each verdict cost (cost tracking).

Typecheck and tests

/review skips both so a manual verdict lands in seconds. The goal loop runs them between rounds, where a slower and stricter judge pays for itself.