Collaborative visual review: comment on UI changes
Comment on a visual diff, draw a box on the pixels that moved, resolve threads with your team or a coding agent, and land the decision on the pull request.
Every UI Verify build already shows what changed. Collaborative review adds the conversation on top of it: a comment lives on the diff it is about, anchored to the region that moved, so the note and the pixels never drift apart into a separate Slack thread.
Comment on the exact pixels that changed
Open any changed story in a build and the candidate screenshot becomes a canvas. Click to drop a point, or drag a box around the part that moved, and a composer opens right where you clicked. The comment is saved against that story's diff at that spot, so every reviewer sees the note pinned to the same pixels.

Point, region, or the whole screenshot
A comment can be anchored three ways, all measured against the image itself so they stay put at any display size:
- A point, dropped with a single click, for a note about one element.
- A region, dragged as a box, for a change that spans an area like a banner or a card.
- The whole screenshot, when the comment is about the story overall and not one spot.
Comments on the baseline pane annotate the before, comments on the candidate annotate the after, so you can point at either side of the change.
Threads, replies, and resolve
Every comment is the root of a thread. Anyone on the build can reply, so a question and its answer stay together, and when the point is settled you resolve the thread. A resolved thread drops off the image and sinks to the bottom of the conversation, so the canvas only ever shows what still needs attention.

Comment and deny in one step
When a comment is flagging a regression, the composer offers Comment and deny: it posts your note and denies the whole story in one action, so the reason a change was rejected is attached to the rejection instead of living in a separate review click.
Humans and agents review in the same place
Comments are not just for people. Connect the UI Verify MCP and your coding agent joins the same review: it reads the diffs and the notes a designer or QA left, replies, resolves, and accepts or denies, all attributed to its own key so you can see who decided what. The AI judge still makes the deterministic call and your team still owns the merge; the agent handles the triage so people weigh in only on the decisions that need a human. See Triage visual changes from your coding agent.

list_comments, then denies the regression and accepts the intended change with review_diff.Over MCP the review runs through a small set of tools: get_diff and render_diff_image to see a change, list_comments to read the conversation, post_comment to leave a note anchored to a point or region, resolve_comment to close a thread, and review_diff to accept or deny.
The decision and open threads land on the pull request
Every comment updates the sticky UI Verify pull-request comment. Open threads ride inline under the story they are about, and the rest fold into a review-discussion section with an open or resolved marker per thread, so the whole team sees where a change stands without opening the dashboard. See what the whole PR did to your UI.
Can my coding agent leave comments over MCP?
Yes. The UI Verify MCP exposes post_comment, which takes a build selector, the diff, a body, and an optional anchor, so an agent can leave a note on the whole story or on an exact region. It can also reply, resolve, edit, and delete, with an agent key limited to comments an agent authored. See Triage visual changes from your coding agent.
Who can comment on a build?
A signed-in team member, or a project API key acting as an agent. Both leave real comments in the same threads, and each comment shows whether a person or an agent wrote it.
Are comments visible on a public project?
The diffs on a public build are visible to anyone, but the review conversation is for the team. An anonymous visitor sees what changed and the AI judge's verdict, not the comments, so internal review notes stay internal.
What happens to comments when a newer build arrives?
Review moves to the latest build. Once a newer build lands on the branch the older one stops taking new comments, but existing threads stay open for replies and can still be resolved, so a conversation in progress is never cut off.
Review UI changes as a team
Every reviewer in one place, human or agent, pinned to the pixels that moved. Start free and get your team reviewing UI together.
Get started