Code Review
A fleet of agents opens pull requests faster than a person can read them. Review is the new bottleneck. Lattis makes review a first-class part of the workspace: the branch diff, your draft comments, an optional agent pass, and the verdict all live in one window.
Review works on any branch with a checkout. It is most useful on the pull requests your team asks you to read.
Open the Review layout
Section titled “Open the Review layout”Two paths open a review:
- From the toolbar — pick Layouts › Review. The layout puts the Review view in the large left pane, Assist and Files in the top-right pane, and Context and Spend in the bottom-right pane.
- From the queue — click a row in PENDING REVIEWS in the sidebar. Lattis opens the branch and applies the Review layout for you.
The Review layout starts no agent session. The agent pass runs on demand, and Auto Fix launches its agents in the background.
You can also add a Review tab to any pane with the pane’s + menu. The view is off by default, like the Session view.
The pending review queue
Section titled “The pending review queue”PENDING REVIEWS is a sidebar section between Conversations and Projects. It lists every open pull request where GitHub asked you for a review. Lattis refreshes it about once a minute, and immediately after every in-app pull-request action.
Each row shows the pull-request icon, the branch, the age of the request, the pull-request number, who asked you, and the churn. Rows group by project and sort oldest request first, so the request that waited longest sits at the top.
The queue only lists repositories you registered as Lattis projects. Register a project later and its requests appear on the next refresh.
Click a row and Lattis lands you on the branch, ready to read:
- It creates a git worktree for the branch when you have no checkout. It fetches
the branch from
originfirst, then checks it out. - It applies the Review layout.
- It loads the branch diff.
A worktree that Lattis creates this way stays out of the Projects tree while the request is live. Your own branches keep their rows.
When a new request arrives, a modal announces it. Begin Review opens the oldest new request. Every new request joins the sidebar list either way.
Read the branch
Section titled “Read the branch”The Review view renders the whole branch as one diff against the merge base with its base branch. The header carries the branch name, the diff scope, the churn totals, and your progress.
The file rail
Section titled “The file rail”The rail lists the changed files in Guided order: code first, by churn, and low-signal files such as lockfiles last. It groups them into chapters — Core changes, Tests, and Low signal. Switch to Path order when you want to find one known file.
Viewed marks
Section titled “Viewed marks”Mark a file viewed and the rail strikes it through. A mark records the file’s blob id, so it goes stale exactly when the file’s content changes. A stale mark shows a hint row and counts as unviewed again. Marks survive a restart.
Two diff bases
Section titled “Two diff bases”The header’s scope chip picks what you read:
| Base | What it shows |
|---|---|
| Branch | Everything past the merge base. The default. |
| Since pass | Only what changed since your last recorded pass. |
Since pass is the incremental read. Come back to a branch that got new commits, and it shows you the new work alone. Your viewed marks are kept.
The diff body
Section titled “The diff body”The diff renders split by default — old on the left, new on the right — and switches to unified from the header. Text wraps at the panel border. Runs of ten or more unchanged lines fold to three above and three below; a thread anchored in a run blocks its fold. Drag the rail boundary and the split seam to resize them. Both widths persist.
Draft comment threads
Section titled “Draft comment threads”Click any diff line, or its hover + chip, to open the composer. Give the comment a kind — issue, question, nit, or praise — write the body, and save it.
Saved threads render under the line they describe. Resolve, reopen, and delete them from the thread itself. Threads are drafts: they stay on your machine until you post a verdict, so nothing reaches GitHub before you decide. They survive a restart.
Review Assist
Section titled “Review Assist”Assist is the optional agent companion to Review. It runs one read-only pass over the branch and returns a triage queue of findings. It never writes to your repository, and it never touches your threads: a finding becomes a draft thread only when you accept it.
Run a pass
Section titled “Run a pass”Press Start and pick an agent. The menu lists every agent with a read-only one-shot mode, with its binary already resolved — Sawyer, Claude, Codex, Pi, and OpenCode. Re-run keeps the agent that ran last. Stop ends the pass.
The pass gets the branch range diff, read-only file tools, and no shell. It reports each finding through a tool call, so findings stream into the pane as the agent finds them.
The five lenses
Section titled “The five lenses”Every finding carries one dimension:
| Lens | Question it asks |
|---|---|
| Correctness | What happens on the unhappy path — empty, huge, malformed, or duplicate input? |
| Design | Does new code live where its dependencies say it should, and follow a pattern the codebase already has? |
| Compatibility | Will this behave the same on every platform the project ships to? |
| CI / release | Would this survive the project’s own gate — formatters, linters, tests, pins? |
| Tests / docs | Does new branching logic have a test? Did this change invalidate a doc? |
Findings land on a severity ladder: critical, high, medium, low, and nit. Filter the queue by severity to read the worst first.
Anchors you can trust
Section titled “Anchors you can trust”Each finding quotes the exact line it describes. Lattis resolves the path against the files the range changed, and corrects the line number against the file’s own text. Click a finding to jump to its row. A finding Lattis cannot place lands in a labelled tail section instead of on the wrong line.
Triage
Section titled “Triage”Every finding takes one of two actions:
- Accept → draft mints an attributed draft thread at the finding’s anchor. It then behaves like a thread you wrote.
- Dismiss drops it.
The header counts the signal: how many findings you accepted, out of how many you triaged.
What the agent is doing
Section titled “What the agent is doing”An activity card sits above the queue. It shows the pass phase, the agent, a round counter, the elapsed time, a bar per model round, and a ticker of tool calls as they complete. Its Output tab streams the agent’s own stdout, line by line.
The card carries no tokens, cost, or model on purpose. The Context pane below it reports all of those for the same pass session. Context answers what the pass costs. Assist answers what it is doing.
Auto Fix
Section titled “Auto Fix”Auto Fix turns your open draft threads into work. It compiles them into one numbered fix-task prompt and launches the agent you pick on this worktree, in the background. The threads flip to sent and keep a lifecycle chip, so you can see what you already handed off.
Auto Fix needs at least one open draft thread.
Finish the review
Section titled “Finish the review”Finish review posts to the branch’s pull request. Four verdicts:
| Verdict | What it does |
|---|---|
| Approve only | Records the verdict. Merge stays a manual step. |
| Approve and merge (squash) | Waits for the gate check. It never merges red. |
| Request changes | Posts your draft threads as unresolved, with the verdict. |
| Post comments | Posts your draft threads, with no verdict. |
Lattis splits your threads instead of flattening them. A thread on a new-file line posts as a line comment on the right side of the diff. A thread on a removed line posts on the left side, on the whole-branch base only. A thread with no line rides in the review body, because GitHub takes no file-level comment at review creation.
The review pins to the revision you read. A push that lands mid-pass therefore cannot shift your comments onto other lines.
GitHub validates the whole batch at once. If it rejects one anchor, Lattis retries the review once as a plain body with no comments, and shows a warning strip in the pane. You keep the pass. Read the strip as “the comments are in the body, not on the lines”.
A branch with no open pull request tells you so: verdicts need a pull request. Open one from the branch menu first.
After the verdict
Section titled “After the verdict”A posted verdict clears the review request on GitHub. Lattis then removes the worktree it created for that review. A checkout you opened yourself is never touched, and a checkout with uncommitted changes asks you first.
Keyboard
Section titled “Keyboard”| Key | Action |
|---|---|
j / k | Previous and next file in the reading order. |
x | Mark viewed, then advance. |
c | Comment on the selected file’s first changed line. |
esc | Close the composer or the open menu. |
Utilities
Section titled “Utilities”The ⋮ menu holds the utilities, never an outcome:
- Copy pass as Markdown — your threads and marks, for an issue or a chat.
- Discard draft threads — drops the drafts. Viewed marks stay.
- Refresh — reloads the branch diff.
Ask for a review
Section titled “Ask for a review”The other half of the loop is asking. Lattis prompts you when you open a pull request that nobody has been asked to review, and the branch menu and the command palette both carry Request Review. The picker ranks candidates by who wrote the code you changed. See Pull Requests & CI.
Limits
Section titled “Limits”- Review verdicts and the pending queue need a connected GitHub account, and repositories on github.com. See Pull Requests & CI.
- The pull-request half needs a pull request. The diff, the threads, and the agent pass all work on a branch without one.
- An agent pass needs an agent. Sawyer ships with Lattis, so a fresh install can run one.
- Pull Requests & CI — open, request, and merge.
- Stoplights & Status — find the branch that needs a review.
- Changes & Spend — what the branch produced, and what it cost.