Revdiff

revdiff - TUI Diff Review

Review diffs with inline annotations using revdiff TUI in a terminal overlay. Works in git, hg, and jj repos (auto-detected).

Activation Triggers

• "revdiff", "review diff", "review changes", "annotate diff"
• "revdiff HEAD~1", "revdiff main"
• "hg review with revdiff", "review jj change"
• "revdiff all files", "review all files", "browse all files"
• "revdiff all files exclude vendor"
• "revdiff README.md", "revdiff docs/plan.md", "revdiff /tmp/notes.txt" — single-file review (--only mode)
• "review this file", "annotate this file", "review file with revdiff"
• "open this review in revdiff", "show review in revdiff", "review in revdiff" — open an in-session review (preload mode)

Answering Questions

If the user asks a question about revdiff (configuration, themes, keybindings, installation, usage) rather than requesting a review session, consult the reference files in references/ and answer directly. Do NOT launch the TUI for informational questions.

• references/install.md — installation methods and plugin setup
• references/config.md — config file, options, colors, chroma themes
• references/usage.md — examples, key bindings, output format

Using Existing Review History

If the user says things like "locate my review", "use my latest revdiff annotations", "pull up the review I just did in another terminal", or "what did I annotate earlier" — the user ran revdiff outside this plugin flow and wants Claude to process the stored annotations. Read the most recent file from the persistent history directory via the helper script, then process the annotations through Step 3.5 classification as if they had come from a fresh launcher call:

${CLAUDE_SKILL_DIR}/scripts/read-latest-history.sh

The script resolves the history dir from $REVDIFF_HISTORY_DIR (default ~/.config/revdiff/history), finds the repo subdir via VCS root basename (jj/git/hg), and prints the newest .md file found. Each history file contains a header (path, refs, and — when available — a git commit hash), the annotations in ## file:line (type) format, and the raw git diff for annotated files. The commit: line and diff block are captured from git only; in hg/jj repos the diff block will be empty and no commit hash is recorded. See references/usage.md "Review History" section for directory layout, stdin/only handling, and override options.

The history file is also the recovery path when a review is cut short by a lost connection: on signal termination (a SIGHUP from a dropped SSH/tmux client, or a SIGTERM) revdiff saves the current annotations to history — never the -o output — so read-latest-history.sh still recovers them.

Opening an In-Session Review

When the user asks to open an in-session review in revdiff (the conversation already contains review comments produced earlier in the session), write those comments to a temp file (e.g. /tmp/revdiff-review-XXXXXX.md) using the format documented in references/usage.md ("Output Format" section), then run the normal launcher flow (Step 1 ref detection, Step 2 invocation) with --annotations=<temp-path> appended. Step 3 onward handles the curated annotations as usual.

Reviewing a Diff That Lives Outside the Working Tree

Some review targets are not the current repo state: a GitHub PR diff, a patch file on disk, or git format-patch -1 --stdout output. Pipe the unified diff into revdiff --stdin and the input is parsed as a real multi-file diff (one tree entry per file, hunk navigation, per-file annotations) instead of a context-only buffer. revdiff auto-detects the unified-diff signature; on a malformed patch the input falls back silently to raw-text mode.

Use this instead of the normal launcher flow when:

• the user asks to "review PR #N", "review this patch", "review gh pr diff output", or supplies a patch URL/path
• the diff describes commits that are not checked out locally (e.g. someone else's branch on a remote-only PR)
• the user pastes a unified diff and asks for a review of that diff, not the working tree

Example invocations (route through the same launcher resolver as the normal flow):

gh pr diff 123 | "$("${CLAUDE_SKILL_DIR}/scripts/resolve-launcher.sh" launch-revdiff.sh "${CLAUDE_PLUGIN_DATA}")" --stdin
git format-patch -1 --stdout | "$("${CLAUDE_SKILL_DIR}/scripts/resolve-launcher.sh" launch-revdiff.sh "${CLAUDE_PLUGIN_DATA}")" --stdin
cat /tmp/feature.patch | "$("${CLAUDE_SKILL_DIR}/scripts/resolve-launcher.sh" launch-revdiff.sh "${CLAUDE_PLUGIN_DATA}")" --stdin

--stdin is mutually exclusive with refs, --staged, --only, --all-files, --include, --exclude, and --annotations, so do not combine with the Step 1 ref detection — go directly to Step 3 once the launcher returns. Annotations come back keyed by the real file paths from the diff (not by --stdin-name).

How It Works

1. Launch revdiff in a terminal overlay (agterm full-pane overlay, tmux popup, Zellij floating pane, herdr tab, kitty overlay, wezterm/Kaku split-pane, cmux split, ghostty split+zoom, iTerm2 split pane, or Emacs vterm frame)
2. User navigates the diff, adds annotations on specific lines
3. On quit, annotations are captured from stdout
4. Claude reads annotations and addresses each one
5. Loop: re-launch revdiff to verify fixes, user can add more annotations
6. Done when user quits without annotations

Workflow

Step 1: Determine Review Mode

All-files mode: If $ARGUMENTS matches "all files", "all-files", or "browse all files" (with optional "exclude <prefix>" parts), use all-files mode:

• Pass --all-files to the launcher
• If user mentions exclude patterns (e.g., "exclude vendor", "exclude vendor and mocks"), pass each as --exclude=<prefix>
• Skip ref detection entirely, go directly to Step 2
• Example: "all files exclude vendor" → --all-files --exclude=vendor

File review mode: If $ARGUMENTS is a single token that points at a file on disk (e.g., docs/plans/feature.md, /tmp/notes.txt, README.md, main.go, file.blah), treat it as file review:

• Decide with test -f "$ARGUMENTS" — if the file exists, it's file review mode
• Also treat as file review if the token starts with / or ./, or contains / and has a file extension (e.g., src/app.go), even when the file is not yet reachable from the current directory
• Skip ref detection entirely
• Go directly to Step 2 with --only=<filepath> (no ref argument)
• Works both inside and outside a VCS repo — revdiff reads the file from disk as context-only
• Ambiguous token (e.g., main — both a branch name and a potential filename without extension) → prefer ref mode; ask the user only if neither test -f nor git rev-parse --verify resolves

Ref mode: If $ARGUMENTS contains explicit ref(s) (e.g., HEAD~1, main, or main feature for two-ref diff), use as-is.

Auto-detect: If no ref provided, run the smart detection script:

${CLAUDE_SKILL_DIR}/scripts/detect-ref.sh

The script outputs structured fields:

• branch, main_branch, is_main, has_uncommitted, has_staged_only
• suggested_ref — the ref to pass to revdiff (empty = uncommitted changes)
• use_staged — if true, pass --staged to the launcher (staged-only changes detected)
• needs_ask — if true, ask the user before proceeding

When use_staged: true, pass --staged to the launcher. This means all changes are in the index (staged) with nothing unstaged — without --staged, revdiff would show an empty diff.

When needs_ask: true (on a feature branch with uncommitted changes), use AskUserQuestion:

• "Uncommitted only" — pass no ref (review just working changes)
• "Branch vs {main_branch}" — pass main_branch as ref (full branch diff including uncommitted)

When needs_ask: false, use suggested_ref directly:

• On main + uncommitted → no ref (uncommitted changes)
• On main + staged only → no ref + --staged (staged changes)
• On main + clean → HEAD~1 (last commit)
• On feature branch + clean → main branch name (full branch diff)

Step 2: Launch Review

When you are launching revdiff for the user (e.g., right after a refactor or analysis), pass --description="..." so the info popup (i key) explains what the change is and what to look at — markdown is supported. For longer prose, write the markdown to a temp file and pass --description-file=/tmp/revdiff-desc-XXXXXX.md. The two flags are mutually exclusive; both are optional. Skip when there's no useful context to add.

When the recent change likely created new untracked files (new packages, new test files, new docs, new scripts that haven't been git add-ed yet), pass --untracked so those files appear in the tree. Use this in working-tree mode (no ref, no --staged); skip it for ref-to-ref reviews where untracked files are not part of the historical diff.

Pass --start-at-change only when the user explicitly asks for that cursor preference; never infer it automatically.

Pass --filter-unreviewed only when the user asks for the tree limited to files not marked reviewed; never infer it automatically. The F key toggles the same filter during the review.

Pass --cross-file-motion only when the user explicitly asks for cursor motion to continue into adjacent files; never infer it automatically.

Run the launcher through the override-chain resolver:

"$("${CLAUDE_SKILL_DIR}/scripts/resolve-launcher.sh" launch-revdiff.sh "${CLAUDE_PLUGIN_DATA}")" [base] [against] [--staged] [--untracked] [--filter-unreviewed] [--cross-file-motion] [--only=file1] [--all-files] [--exclude=prefix] [--description=text|--description-file=path]

The resolver and launcher MUST run in the same bash invocation — the resolver runs as a sub-shell substitution so the resolved path is consumed immediately as the executable. The resolver checks user → bundled (see references/install.md for override paths) and prints the first-found absolute path. Fall-through to the bundled launcher is the default when no overrides exist.

Failure mode: if the resolver fails (no launcher in any layer), the command substitution produces an empty string and bash reports : command not found with exit 127. The resolver's stderr (error: launcher not found in override chain: launch-revdiff.sh) is preserved on the same output stream — check it to confirm the override path is correct (executable bit set, file present in one of the two layers).

IMPORTANT — long-running command: The launcher blocks until the user finishes reviewing in the TUI overlay, which can exceed the default bash tool timeout on many harnesses. Set the bash timeout parameter to the maximum your harness allows (e.g. 1800000 or higher on OpenCode). The resolver itself returns in milliseconds — the timeout cap applies to the launcher only. Do NOT use run_in_background for this — background-task handling is unreliable for interactive TUI launchers (processes may be killed unprompted, and polling loops can leave the session idle after the review finishes). If the review outlasts the timeout cap, the fallback in Step 3 handles it.

Disconnect-resilient tmux window mode: when running under tmux, prefix the launcher with REVDIFF_TMUX_WINDOW=1 to open revdiff in a persistent, server-owned tmux window instead of a client-owned display-popup. The review then survives a dropped SSH or tmux client — reattach and it is still there. This is a launcher environment variable, not a revdiff flag.

Pane-scoped overlay (herdr): when running under herdr, REVDIFF_HERDR_PANE=1 opens revdiff in a zoomed split of the agent's own pane instead of a new fullscreen tab, keeping the agent pane one keypress away. The user sets it in the environment; it falls back to the tab overlay on an older herdr CLI. This is a launcher environment variable, not a revdiff flag.

Pane-scoped overlay (agterm): when running in an agterm split, REVDIFF_AGTERM_PANE=1 opens revdiff in the agent's own pane instead of over the whole session, leaving the sibling pane live and visible. The user sets it in the environment; it is ignored outside a split. This is a launcher environment variable, not a revdiff flag.

The script:

• Detects available terminal (agterm → tmux → Zellij → herdr → kitty → wezterm/Kaku → cmux → ghostty → iTerm2 → Emacs vterm)
• Launches revdiff in an overlay
• Captures annotation output to a temp file
• Prints captured annotations to stdout

The bundled launcher sets REVDIFF_EXIT_CODE_ON_ANNOTATIONS; exit 10 means annotations were captured and is not a launcher failure. Treat other nonzero statuses as failures. On those failures the launcher relays revdiff's own stderr — report that text verbatim instead of guessing which argument was at fault.