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 rawgit 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 asX / 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.
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 — taggedfix, 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
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.- 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.
- 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-queueskill teaches it the steps). It fixes in its own environment and callsmark_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. - 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.