> ## Documentation Index
> Fetch the complete documentation index at: https://reikon.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Review

> The diff viewer, inline annotations, and the human↔agent review loop.

# Tour: Review

**Review is the wheel's third stage — judge the act.** Your uncommitted work, staged and
unstaged, with a diff viewer built for review rather than a raw `git diff` dump. This is
where the human↔agent loop lives: you and your coding agent annotate the same diff, reply,
resolve — and you **dispatch** fixes back. Press `3` to jump here.

## Diff viewer

Toggle between staged and unstaged, unified or split view. Files are grouped by
directory in the sidebar. Binary and submodule files auto-collapse on load so they
don't clutter the view.

## Working vs branch

The toolbar has two lenses. **Working** is your uncommitted tree (staged / unstaged).
**Branch** reviews everything on the current branch since it diverged from its base —
`base...HEAD`, the same scope a pull request would show, but resolved entirely from
local git (no remote, no PR). Pick the base from the dropdown (Reikon defaults to
`main`, then `master`, then `develop`); the `↑ahead ↓behind` count tells you how the
branch sits relative to it. Same diff viewer, same inline annotations — so you can
flag and dispatch on branch changes exactly as on working ones.

Either lens **skips files you've gitignored** — including ones you committed before adding
to `.gitignore` (those stay tracked, so git would otherwise keep showing them). Review
stays focused on the code you actually want to judge.

The Working lens also shows **brand-new (untracked) files** — ones nothing has staged yet —
as all-addition diffs under Unstaged. So when you dispatch a fix and your agent *creates*
files (e.g. splitting a large module into new ones), the new code shows up for review with
no manual `git add`.

## Tracking your review

The file sidebar shows a checkbox next to each filename. Check it to mark a file
reviewed; the header counter shows your progress as `X / Y`. Progress is per-session —
it resets when you refresh the diff, matching how Review works in practice: each time
you pull or stage new work, you start fresh.

To move through annotations without scrolling, use `[` and `]` to jump to the
previous and next open annotation in diff order. The toolbar shows how many open
annotations remain (`2 open`, `3 / 5` when navigating); the same prev/next buttons
are also there if you prefer clicking.

## Before you commit (staged view)

Two banners appear above the file list whenever you're viewing staged changes,
computed from data Reikon already tracks — no extra setup:

* **Diff health score** — a one-line summary: how many touched files are
  high-complexity, whether average complexity is trending up or down in this commit,
  and how many bus-factor (single-ownership) files are involved. Turns emerald when
  nothing's flagged, amber when something is.
* **Who should review this?** — based on ownership and churn history, the people who
  know this code best. If the person who knows it best has gone quiet (no commits in
  30+ days), that's called out as a separate note instead of naming them as the
  reviewer — a recommendation to ask someone who's actually still around.

Neither of these requires AI — they're pure reuse of ownership, churn, and complexity
data already computed elsewhere in the app.

## After you commit (watch mode)

With watch mode on, a toast appears after a real commit lands if the commit
meaningfully changed complexity or touched a bus-factor file — comparing the commit
against the previous one, not just restating the staged-view banner. Quiet commits
don't trigger a toast at all; this is signal, not a notification for every commit.

## Annotations

Leave inline notes on any line or hunk — tagged `fix`, `explain`, or `review`. Notes
persist across restarts and survive line-number drift (anchored to the hunk's content,
not its line numbers) — and when the flagged code itself is edited (your agent's fix,
your own follow-up, a rebase), the note **follows the code** to the reshaped hunk.
A collapsible side panel groups the active notes by file.

Resolving or dismissing a note doesn't delete it. It moves into the panel's **History**
(the clock toggle in the panel header) — a durable record of what was raised and decided
here, kept past commit. That's the same record your agent reads through
`get_annotation_history`, so a settled point doesn't get re-litigated next cycle.

Notes are tagged with the lens they were made in. A note left in **Working** is cleared
once its hunk leaves the working diff (you commit or revert the change) — so review TODOs
don't linger past the commit they were about. A note left in **Branch** sticks to its
hunk for the life of the branch, even after that hunk gets committed.

To reply to a note, type directly in the compact text field at the bottom of each
annotation card and press `⌘↵` (or `Ctrl+↵`) to send. Press `Escape` to clear the
draft without losing the annotation.

If you're using an MCP-connected agent, it can reply to your notes and mark them
resolved after addressing them — and, within strict limits, proactively flag a hunk it
notices crosses a real risk threshold (never its own unverified judgment of "risky").
See the [MCP tool reference](../../reference/mcp-tools#write-tools--scoped-to-annotation-state-only)
for exactly what an agent can and can't do here.

## Dispatch — hand a fix back to your agent

Reviewing isn't only commenting. From any note you can **Copy prompt** — the loop's outbound
verb. Copy *is* the request: one act both marks the note for a fix and gives you the prompt to
hand off.

1. You hit **Copy prompt** on a note. Reikon composes a kickoff prompt — the file, the hunk, your
   reason — previews it, and on copy marks the note **fix-requested** (so it's tracked and your
   agent can return it). The toolbar's **Copy all** does the same for every actionable note at
   once.
2. Hand it off: **paste** the prompt into your own agent, or — if your agent has Reikon's MCP
   connected — just tell it to *"work Reikon's dispatch queue"* and it pulls the fix-requested
   notes itself (the [`reikon-queue` skill](../../guides/mcp-claude-code) teaches it the steps).
   It fixes **in its own environment** and calls `mark_fix_returned` — which only succeeds if the
   flagged file actually changed in your working tree. No diff, no advance: the lifecycle can't
   reach "review this fix" against an empty change.
3. The returned diff lands back in Review for your verdict. **Accept** resolves the note;
   **Send back** reopens it with your reason attached, which the agent reads on its next try.

Reikon emits the instruction and reviews what comes back — it never runs or applies the fix
itself (a cockpit, not an editor). If a returned fix touched files beyond the one you flagged, the
card says so, so you review the whole change, not just the hunk. The [Dashboard](./dashboard)
keeps a small dispatch ledger of what's out, returned, and pending — across every open repo.