Code review
Review the actual diff line by line, from a browser, the desktop app, the Mac, or your phone.
A gate note is fine for "looks good" or a paragraph of direction. When you want to review the diff itself, line by line, Peractor has a proper review on every surface.
Start a review
Open Review changes on a run — it appears once the run has commits. Peractor fetches the run's branch and diffs it.
Comment on the diff
You get every changed file you can open, as a flat list or a tree, and a diff for each one — a file in a folder closed to you is left out. Add a comment on any line.
| Part of a comment | What it means |
|---|---|
| The line, and its side | A removed line 6 and an added line 6 are two different lines. A comment is anchored to both. |
| Text | What you want to say. |
| Attachments | Files belong to the comment, not the review — the screenshot sits with the remark it illustrates. The agent gets them staged into its workspace with the paths named under your note. |
There is also a review summary: a comment about the whole change rather than any one line, reached from the review screen's menu. It leads the note the agent receives.
Per surface
- Browser and desktop — the diff opens as a sheet from the run, per edit or across the whole branch, with the comment box inline.
- Mac — the same review in a window of its own, beside the transcript.
- iPhone and Android — the full review, with per-line comments and attachments. Leaving a review with unsent comments asks first.
Submit
Submit review bundles every comment into one "request changes". You can do this at any point in a run's life:
- Parked at a gate — the rework starts immediately.
- Still working — the review is queued and applies automatically the next time a phase parks.
- Already finished — the final phase re-opens as a continuation and applies your notes to the finished branch.
Reviews are attributed to your signed-in identity. A review asks for changes, like Request changes at a gate: on your own run that takes Start runs, and on somebody else's Manage runs — unless the gate's approver rules name you, since reviewing is then your job. Approving the phase is still what its approver policy decides.
Opening a file where you work
From a run's changed file, Open in… opens it at its first changed line in the editor you actually use — VS Code and its forks, JetBrains, Xcode, Zed, and a dozen others. The picker lists what is installed and remembers your choice.
Other files open in the app you use for them. In Code, the wiki and Assets, a file's menu offers Open in… too: a Word document in Word, Pages or LibreOffice, a spreadsheet in Excel or Numbers, a PDF in Preview or Acrobat, a picture or a diagram in its own app. Each kind of file starts with your computer's default app. Pick another with Open With…, or Other… for any app you have, and that kind of file opens there from then on. The file opens from your copy of the repository, so changes you save land in your checkout.
The Mac app and the desktop app list the apps you have installed. A browser can only reach editors through their links, so office files open from the apps. On iPhone, iPad and Android, Open in… in a file's menu hands a copy to an app on the device, and changes made there stay in that app.