Collaborative visual review: comment on UI changes

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.

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.

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.

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.

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.

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.

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.

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.

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.

Yes. While a story has an unresolved thread, the MCP refuses to accept or ignore it: accept_build accepts nothing and names the stories that still have open notes, and review_diff turns down accept and ignore for that story (deny still works). Every changed story the agent lists carries its own comment count, and render_diff_image puts a short note next to the image when a thread is open, so the agent finds the note on its own. It then reads the note with list_comments, fixes what it asks for, resolves the thread with resolve_comment, and accepts. People accepting in the dashboard are not blocked, since they can already see the threads. A comment belongs to the build it was left on, so a new push starts a build with no open notes of its own.

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.

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.

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.