Triage a UI Verify build from your agent

Triage a UI Verify build from your agent reviews visual changes through the UI Verify MCP connection. For each story, it can inspect baseline, candidate, and diff images, read metrics and review comments, summarize regressions, and record baseline decisions. It supports both a single build's gate and the cumulative visual impact of a pull request.

The workflow distinguishes four outcomes: a regression is a real change that makes the result wrong or worse; an intended change matches the PR's purpose and remains visually correct; cosmetic reflow moves the same content by a few pixels; rendering noise is small edge or anti-aliasing jitter. New stories need a separate first-baseline category because they have no prior image to compare.

The skill preserves instructions from an MIT source at commit 181d9e4, with catalog sections covering use cases, examples, limitations, and safety. It does not infer that a change is correct merely because the current PR caused it.

Use it when a UI Verify build reports changed or failed stories, when preparing a visual-regression summary for a PR, when reviewing before-and-after images, when responding to diff comments, or when the user explicitly asks to accept reviewed baselines.

A UI Verify account, network access, and a project that uploads builds from CI are required. Supported upload contexts include Storybook, Playwright, and Vitest through the uiverify CLI. Without an uploaded build, there is nothing to triage. Browser OAuth login must be completed by the user.

Triage itself never accepts stories. It first surfaces the buckets so the user can decide, or proceeds through a separately explicit acceptance step. Bulk acceptance is appropriate only after every changed story has been inspected and no real regression remains. A deliberate headline or theme change does not establish that all affected stories are correct.

Builds can be selected by commitSha, prNumber, or buildId. list_projects identifies accessible projects when several exist, and projectId disambiguates lookups. With one project, selection is automatic; ambiguous calls return the available projects. list_builds narrows recent builds by project, branch, status, or limit.

get_build returns the gate, total/changed/failed/unchanged counts, build-wide comment counts, review tallies, and the first twenty-five changed or failed stories. Each changed story includes a diffResultId and percentage delta. When AI review is enabled, it also includes verdict, confidence, and a one-line regression reason. Additional stories must be paged with list_build_stories until nextCursor is exhausted; the default page is twenty-five and the maximum is one hundred.

The build response does not dump unchanged stories. Its unchanged count indicates the set available through list_build_stories with unchanged status. A clean build can still be inspected: get_diff with a storyId returns its current baseline URL, while render_diff_image can display that baseline directly.

get_diff provides per-story metrics and presigned baseline, candidate, and diff URLs. When enabled, the judge's full verdict includes summary, reasoning, confidence, and aiFlagReason. render_diff_image returns actual inline pixels rather than a URL. Its before_after option crops to changed regions and stacks separate regions when, for example, a header and footer both moved.

For a content change, the reviewer renders both baseline and candidate and compares them directly. The diff mask only locates changed pixels; it cannot establish whether text became illegible, contrast worsened, content disappeared, or controls became clipped. A judge's regression verdict is a reason to investigate. Overriding it requires concrete evidence from the image pair that refutes its stated reason. Attribution to the PR alone does not refute a regression.

A useful triage report names real stories and percentage deltas in the four buckets. A concise PR summary puts regressions first and intended content changes next, one line per story, leaving reflow and noise out of the main summary. Supporting before-and-after images and a build link keep the evidence accessible to the reviewer. Presigned URLs can be downloaded for attachments or linked where the team would normally share screenshots.

The service uses a remote Streamable-HTTP MCP connection with one browser OAuth login. That connection reaches every project in the user's teams, without a separate key or per-project account setup. Each person authenticates with their own account.

claude mcp add --scope project --transport http uiverify https://uiverify.ai/mcp

In Claude Code, project scope writes a secret-free .mcp.json that can be committed for teammates; each teammate completes their own login. Cursor and other MCP clients can use the same service URL. Restarting the session after adding the server makes the tools available.

A native MCP client is important because image tools return MCP image blocks that a shell cannot render. Raw HTTP does not provide useful inline pixels to a script. Where a client only reaches the service over HTTP, get_diff supplies downloadable URLs instead of render_diff_image's inline image response.

The cumulative get_pr_changeset is distinct from get_build. A build gate describes one commit's unreviewed changes; the changeset compares the whole PR with its base branch and survives earlier in-PR acceptance and merge. It catches stories added and accepted earlier as well as removed or renamed stories that no current build can render. Its counts and first pages cover new, changed, removed, and unchanged stories; list_pr_stories pages individual new, changed, or removed buckets.

Every changeset entry must be attributable to the PR diff and correct. An unattributable change requires stopping and flagging the issue rather than accepting it, dismissing it as flake, or rerunning until it disappears. It may indicate an unexpectedly moved baseline. An unintended removal, or a rename appearing as removal plus addition, must be highlighted even if the current build is green. The changeset is generally available, and public-project build changesets can be read without login.

Review comments supply context that pixels alone do not carry. get_build and get_diff expose total and unresolved counts. list_comments returns each live comment with its diffResultId, author type, body, side, parent thread, image anchor, and resolved state. Read these notes before classifying or accepting stories.

The server refuses accept and ignore decisions on a story with unresolved comments. accept_build refuses the entire bulk operation if any changed story has an open note, accepting nothing and naming the affected stories. The correct sequence is to read the note, address it, resolve the thread, and only then accept. Resolving a note solely to unblock acceptance defeats the review safeguard.

post_comment can create an anchored root comment or reply through parentId. New root comments require the latest branch build; replies remain allowed on older builds. resolve_comment resolves or reopens a root thread. update_comment and delete_comment can touch only comments authored through the agent, never a human's comments. These tools require the team's image-comments feature; without it, they are absent and comment counts are zero.

For mixed builds, review_diff records accept, ignore, or deny per diffResultId; deny remains available even with unresolved notes. accept_build advances every changed story's baseline and therefore changes what later builds treat as truth. Both operations require prior inspection, and real regressions must remain unaccepted. Presigned image URLs are readable by anyone holding them until expiry and must be shared only within the screenshot's intended audience.