Reviewing changes

The dock

Open it with Ctrl Shift F or from the transcript header. It splits into two sections on one edge, divided by a handle you can drag:

• The explorer is the project tree. Folders holding an edit carry a count; a changed file carries its status letter.
• The viewer shows whatever you opened. An unchanged file shows its contents; a changed file shows its diff.

Keeping them separate is the point. The tree holds its place while the viewer changes under it, so opening a second file does not lose you the first. Either half can be closed for a full height version of the other. Ctrl F searches inside the file you are reading.

Diffs

Diffs render with additions and removals marked, with a per file summary of how many lines moved each way. The change list comes from git, so it is the same set of files git status would show you on that machine, including changes made in a terminal while the chat was idle.

This works on a phone. Reviewing what an agent did on the train is one of the things Termdeck is actually for.

Browsing the project

The explorer browses the real folder on the real machine, read only. It is confined to the folder the chat was opened in and cannot walk above it, which is enforced on both ends of the connection rather than in the interface.

Nothing from your repository is ever rendered as markup. Every file, and every line of every diff, is built as document nodes, so a file that happens to contain HTML is text and stays text.

Checkpoint restore Starter

Claude Code snapshots the files it is about to edit before each turn. Termdeck reads those snapshots and turns them into a row in the transcript at each prompt boundary, showing how many files that turn touched.

Restore files puts every tracked file back to its state before that prompt ran. If a turn produced several separate snapshots, which is what the interactive CLI does, restore takes the earliest backup of each file, so rolling a prompt back genuinely means the state before the prompt rather than a partial undo.

The button asks for confirmation and lists exactly what it will write. If the snapshots for a checkpoint cannot be resolved, it refuses rather than guessing, and says nothing was found.

Branch from here

Next to restore sits Branch from here, which starts a new chat from that point in the conversation. It only ever writes a new transcript, so it needs no confirmation and cannot lose anything. A checkpoint is usually exactly the point you would want to try a different approach from.

Opening a pull request

When the work is ready, Create PR pushes the branch and opens a pull request using the GitHub CLI on that machine, under your own GitHub identity.

It is a modal with a confirmation step rather than a button that fires as a side effect of a panel being open, because it is an outward facing action. It needs gh installed and authenticated on the machine.

Recap

Open a chat's menu and choose Recap for a factual account of what it did: elapsed time, number of turns, files touched, commands run, and cost. It is derived from the transcript rather than generated by a model, so it is instant, free, and cannot be wrong about which files were edited.

It reads the whole transcript rather than the part currently loaded on screen, so a recap of a three hour chat describes three hours.

A review pass that works

1. Open the dock and read the change list first. The shape of a change usually tells you more than the transcript does.
2. Open anything surprising and read the diff, not the agent's description of the diff.
3. Use Recap if you were away and want the commands it ran.
4. Wrong direction? Restore the checkpoint at the prompt where it went wrong, or branch from there and try a different instruction.
5. Happy? Create the PR from here, or take over in a terminal with claude --resume.