Docs · Diff review

Review the whole file, then send the notes back.

ctrl+r on a session opens a full-screen review of its repo: changed files with +/− counts on the left, the whole file on the right with syntax highlighting and changed lines tinted, so every edit reads in full context. The diff refreshes as the agent keeps editing.

Fig. 3ctrl+r · review

Comments go back to the agent

c writes a note on any line and d drops one. Comments stay on the review screen until you send them: C flattens every one into a single prompt, asks you to confirm, and delivers it into the agent's pane, so the agent starts addressing your notes while you watch the diff update.

Keys

• ↑↓ / j kScroll the file. ctrl+d and ctrl+u move half a page, g and G jump to the ends.
• J / KPrevious and next file. tab and shift+tab do the same.
• n / NJump between changes.
• uToggle unified and side by side, holding the cursor on the same source line.
• sCycle the scope: uncommitted, versus target, last commit, staged.
• rPick the repo when the session's directory holds several. Type to filter.
• bPick the branch from the repo's worktrees.
• BPick the target the "versus target" scope compares against.
• spaceMark a file reviewed.
• c / dWrite, drop a line comment.
• CSend every comment to the agent as one review prompt.
• esc / qClose the review.

Each changeable value in the header wears its own key, so the scope, layout, repo and target pills read as s, u, r, B legends at a glance.

Which repo it opens

A session's working directory is often an umbrella folder holding many repos, so review cannot simply guess. An agent that knows which repo it is in says so by calling the review_repo tool (or running agent-manager review-repo <path>). The path is checked to be inside a git repo and resolved to the repo root, so a declaration is a fact rather than a guess.

Review resolves its target in a fixed order: a repo you picked by hand with r or b wins for as long as the manager runs, then the agent's declared repo, then the ranking, which puts dirty working trees first and then the most recent commit. Linked worktrees are discovered wherever they live on disk, so one declaration names both the repo and the branch under review.

Fig. 4side by side