Skip to content
NAVIDIFF DOCUMENTATION

Reviewing a PR

What it does

  1. Triage — resolves the PR's real base (never assumes dev), fetches refs/pull/N/head so fork PRs work, diffs from the merge-base, and buckets every file MUST / JUDGE / SKIM / SKIP. The rules are a 1:1 port of the skill's awk; server/parity.ts proves it against the script.
  2. Coherence checks — cross-file rules over the changed-file set. No model, no tokens: migration without metadata, DDL without regenerated types, logic without a spec, i18n drift, schema without a migration, deleted-but-still-imported.
  3. Judge — on demand, one batched Claude session streaming a verdict per file (above 40 files it samples per directory and says what it skipped). Verdicts land live over the WebSocket.
  4. Suspicions — a verdict's suspicions are stored, not just streamed, and each has a pin button that turns it into a review comment anchored to the file's first changed line.
  5. Viewed state — read from GitHub's own per-file checkbox over GraphQL, so it's identical in both diff views. Toggling here writes back to GitHub; "unviewed only" hides what you've signed off.
  6. Understand one fileexplain walks a file's change hunk by hunk with risks and hand-checks after reading its history and callers; review judges just that file; ask works on a whole file.
  7. Review — pin findings on lines, edit or delete them, then save one review. It's a pending draft by default: nothing reaches the author until you press Submit on GitHub. Every finding is marked 🤖.

Where to start

A fresh session shows one strip under the header with the next thing to press — guide, claim vs diff, judge, read the MUST files, submit — one step at a time, each labelled with what it costs. Prepare this review runs all three model passes on one press (guide → claim vs diff → judge), sequential because they share one rate window. The run belongs to the session, not your tab: a refresh or a second tab picks the progress bar back up where it is.

The diff itself

The patch says which lines differ. Everything here is the part it doesn't say:

  • What became what — inside a hunk each deleted line is matched to the added line that replaced it by similarity, not position, and the differing words are marked (server/pair.ts).
  • Moved code, across files — a block deleted in one file and added in another is detected over the whole PR, tinted, and labelled with where it came from — click to jump (server/moves.ts).
  • No-op hunks folded — a reindent, a reworded comment, reordered imports, a rename applied throughout, shown as a one-line summary (server/classify.ts); n folded reveals them.
  • Where you are — a sticky breadcrumb from a real tree-sitter parse follows the scroll.
  • Changed signatures are called out above the hunks — they break callers not in the diff.
  • Blast radius per symbol — exported symbols this diff touches, and how many uses live outside the PR.
  • Line age — a gutter bar shows how old the surrounding unchanged code is.
  • Since your last pass — after a force-push, git range-diff reports what actually changed.

Keyboard

j/k move · n next unviewed MUST · g guide order · [/] guide section · 14 re-bucket · r mark opened · v mark viewed on GitHub · h hide viewed · a ask about this file · e explain it · R review just it · p pin every suspicion on it · m hide the panels · ⌘↵ submit · ? the full list. Pinning one line is a click in the diff, not a key.

Ready to review a real change?

Open Navidiff