Review a build
Review visual changes as a team — request reviewers, comment on the exact pixel or line that changed, discuss in threads, and approve or reject in real time.
When a build detects visual changes, the build page is where your team decides what to do with them. Reviewing a build is collaborative: request the people you need, leave comments pinned to exactly what changed, discuss in threads, and approve or reject — with everything updating in real time.
Every reviewer's decision counts on its own, so a build reflects your whole team's input rather than just the last person to weigh in.
Open a build
You can open a build from several places:
The Builds list in your project.
The pull request comment Argos posts on your PR.
The Argos status check on your commit or pull request.
The build page shows each screenshot with its baseline (the reference) next to the changes (the new screenshot), and highlights the visual diff between them. See How Argos detects visual differences for how the diff is computed, and use Tags to filter the screenshot list down to what you care about.
Compare baseline and changes
The diff viewer offers several ways to compare a snapshot:
Split view — baseline and changes side by side. This is the default.
Single view — one image at a time, switching between Baseline and Changes.
Changes overlay — changed pixels are highlighted with a red overlay. Toggle it on and off, and customize its color and opacity from the toolbar.
Highlight and navigate changes — flash the changed regions and jump from one to the next.
Fit or expand — fit the screenshot to the screen or inspect it at full size; zoom and pan stay in sync between the baseline and changes panes.
ARIA view — when a snapshot has an ARIA snapshot, switch between the screenshot and its accessibility tree.
Follow a journey step by step
A test that walks a checkout, a signup or an onboarding captures a screenshot at each screen it visits. Argos groups those screenshots back into the journey the test walked, so a change is reviewed next to the screens that come before and after it. There is nothing to configure: the journey is the test that took the screenshot, and each screen the test captured is a step.
The Journey button in the toolbar unfolds that journey as a strip of steps above the comparison panes.
Every step, not only the ones that changed. The strip is built from the whole build, so the screens that stayed identical are in it too. A dot marks the steps that need review, and names what is waiting there on hover.
Jump to a step. Select a thumbnail to open that step. The strip stays on the variant you are reviewing, so you keep the same browser and viewport as you move along the journey.
⇧+←and⇧+→walk the same steps from the keyboard, whether the strip is open or not.
The button appears only when the screenshot belongs to a journey of more than one step: a test that captures a single screen is regular visual testing, not a journey. The strip stays closed until you open it, and then remembers your choice.
Where a journey comes from
A journey is derived from the metadata your Argos SDK already records, so nothing changes in your tests:
The journey is the test that took the screenshot, identified by its title path (file,
describeblocks and test name). Storybook uploads group by component instead, with one step per story.A step is a screen, not a file. The viewport and browser variants of one screen collapse into a single step, exactly as they do elsewhere in the review.
The order is the order in which the test captured the screens.
Keyboard shortcuts
Press ? on a build page to see the full list of shortcuts. The ones you'll use most while reviewing:
↑ / ↓
Go to the previous / next snapshot
← / →
Show only the baseline / only the changes
⇧ ← / ⇧ →
Go to the previous / next step of the journey
S
Toggle side-by-side view
D
Toggle the changes overlay
H
Highlight the changed regions
J / K
Go to the previous / next change
Space
Toggle fit to screen
Y / N
Mark a change as accepted / rejected
I
Ignore a flaky change
C
Toggle the comment tool
↵
Open the review popover
Request reviewers
Use the Reviewers section in the build sidebar to request the people you want to weigh in.
In the Reviewers section, click the + button (Add reviewer).
Search for and select one or more project members.
You can request several reviewers, add or remove them at any time, and each reviewer's verdict is tracked individually — a new review never overwrites someone else's.
Each reviewer shows one of the following states:
Approved
The reviewer approved the changes.
Rejected
The reviewer rejected the changes.
Commented
The reviewer left feedback without approving or rejecting.
Pending
The reviewer was requested but hasn't reviewed yet.
Dismissed
The review was dismissed and no longer counts.
How reviews decide the build status
Only each reviewer's latest review counts, and dismissed reviews are ignored. The build status follows two rules:
One rejection blocks. If any reviewer's latest review is a rejection, the build is rejected — even if others approved.
Otherwise, one approval passes. With no active rejection, a single approval marks the build approved.
Comment reviews and pending requests don't affect the outcome. To unblock a rejected build, the rejecting reviewer can submit a new review, or an administrator can dismiss the rejection.
Submit a review
Open the review popover from the build header and choose one of three actions:
Comment — submit feedback without approving or rejecting.
Reject — reject the changes.
Approve — approve the changes so the build can be merged.
Add an optional summary in the Add review summary… field, written in Markdown. A summary is required when you submit a neutral Comment review.
As you work through a build, a review-progress chip (for example, 2 / 3 reviewed) tracks how many changes you've reviewed so far.
Draft reviews
You don't have to publish each comment as you go. By default, the comments you add while reviewing are gathered into a pending review that stays private to you — each shows a Pending badge noting "Only you can see this. It becomes visible when you submit your review." When you submit, all of them are published at once and your reviewers are notified together — GitHub-style.
To post a single comment immediately instead of adding it to your pending review, hold Alt while submitting (Post comment).
Your in-progress comments are saved locally, so you won't lose a thought if you navigate away before submitting.
Comment on exactly what changed
Comments are pinned to precisely what they're about:
On a screenshot, click a point to pin the comment to that exact spot.
In a text-based snapshot, select a line or a range of lines to attach the comment to those lines.
The snapshot you're viewing is automatically attached to your comment, and you can detach or reattach it without losing what you've written.
Comments are written in Markdown and support:
/slash commands for quick formatting.@mentions to notify a teammate.
Discuss in threads
Any comment can become a conversation:
Reply to a comment to start a thread.
React with emoji — open the Add reaction menu on a comment and pick one.
Resolve a thread once the discussion is settled, and reopen it if it comes back up.
Collaborate in real time
Everything on the build page updates live — comments, replies, reactions, resolutions, and review decisions appear as they happen, with no refresh.
Presence dots show who else is on the build and whether they're online, and each teammate's user card shows their role and current local time, so you know who's around before you wait on a review.
Review notifications arrive as a single digest rather than one message per action. To control your own notifications for a build, use the subscribe toggle in the Activity section of the sidebar.
Reference a screenshot
Each screenshot pane has a ⋮ actions menu — on both the baseline and the changes — that makes it easy to reference a screenshot in a pull request or share it with a teammate:
Copy link — copy a direct link to the screenshot.
Copy embed as Markdown — copy the screenshot as a Markdown image embed, ready to paste into a PR description or comment.
Download — download the screenshot. For a changed screenshot you can also download the diff mask and the composed changes (the diff overlaid on the screenshot).
Who can review
Leaving reviews and comments requires a role that can review builds — team Owners and Members, or Contributors assigned the Project Reviewer or Project Administrator role. The build must also be in a reviewable state (changes detected, approved, or rejected).
Dismissing another person's review requires an administrator-level role.
See Team members & roles for the full permission breakdown.
Review from the API
Every review and comment action is also available in the Argos REST API: submit, list, and dismiss reviews; create, read, update, and delete comments and replies; add and remove reactions; and resolve or reopen threads. Because these actions are attributed to a user and checked against that user's project permissions, they require a personal access token rather than a project token.
You can also submit reviews from the Argos CLI with argos review create, or let an AI agent review builds for you.
Last updated
Was this helpful?