Triage Visual Changes

Triage a UI Verify build from your agent

When a build comes back changed, the dashboard shows a triptych per story (baseline / candidate / diff). This skill does that review from your agent over the UI Verify MCP — read what changed, look at the pixels when a number is ambiguous, then summarize or accept.

Connect the MCP (once)

The server is a remote Streamable-HTTP MCP at https://uiverify.ai/api/mcp, authed with your project's uv_proj_… API key as a Bearer token. Add it as a real MCP server in your agent — don't hand-roll curl against the endpoint. Over raw curl the image tools come back as MCP image blocks a shell can't render, so the pixels are useless to a script; a native client shows them to the model directly.

Claude Code:

claude mcp add --transport http uiverify https://uiverify.ai/api/mcp \
  --header "Authorization: Bearer $UIVERIFY_API_KEY"

Cursor — add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "uiverify": {
      "url": "https://uiverify.ai/api/mcp",
      "headers": { "Authorization": "Bearer YOUR_uv_proj_KEY" }
    }
  }
}

Any other MCP client (Codex, Copilot, Gemini): point it at the same Streamable-HTTP URL with the Authorization: Bearer header. If a client can only reach it over HTTP by hand, prefer the get_diff tool (it returns downloadable image URLs) over render_diff_image (inline pixels) — see the tool table below.

Tools it exposes:

Recipe 1 — "Triage this build"

Bucket the changes so the human sees signal, not 60 rows. Call get_build for the PR — it carries the AI judge's call per story (aiVerdict, and for a regression the aiFlagReason) for the first page of changes; if counts.changed is larger than that page, keep paging list_build_stories { status: "changed" } on the nextCursor until it runs out, so no regression slips past the page boundary. Read the judge before you form your own view, and for anything that actually changed content, adjudicate it against the before image, not in isolation:

• Render BOTH images, not just the diff. render_diff_image which: "baseline" and which: "candidate" and compare them. The green diff mask tells you where pixels moved, never whether the result is good — a code block that went dark-on-dark, text that lost contrast, a control that's now clipped all look like "some pixels changed" in the mask and only reveal themselves as regressions in the before/after. Judging the candidate alone is how "it has colours now → improvement" passes an illegible block. Pull get_diff for the judge's aiReasoning / aiFlagReason on the ones it flagged.

Report in four buckets, with real story names and % deltas:

1. Regression — a real change that's wrong — content changed and the after is broken or worse: illegible/low-contrast text, clipping, overlap, missing content, a control that stopped reading as itself. A regression the current PR caused is still a regression — "my diff explains it" says nothing about whether it's correct. Never accept these; they're the reason to triage.
2. Intended change — content changed and the after is correct and matches the PR's stated intent (a deliberate restyle, new copy, a genuinely new story). These still want a human eye, but they're accept candidates.
3. Cosmetic reflow — real diff pixels, but the diff image shows the same content shifted a few px (a row moved down ~5px, text ghosted lower). Not a content change.
4. Rendering noise — safe to accept — sub-0.4% jitter on chart edges / anti-aliased lines. Pure render jitter.

The judge's regression verdict is a reason to look harder, never to dismiss. If you're about to call a story the judge flagged "intended anyway", you need a concrete reason from the before/after that refutes its aiFlagReason — not "it's a colour change, probably fine." When you can't refute it, trust it.

Example output shape:

67 changed stories → buckets. ⚠️ Regressions (2) — real changes that look wrong, do NOT accept: SetupWizard/Playwright (8.3%, code block now dark-on-dark / illegible — judge flagged regression), Card/Compact (5.1%, title clipped) … 1. Intended changes (11) — content changed, looks correct, accept candidates: Hero/Default (14%, new headline copy), … 2. Cosmetic reflow (9) — real pixels, vertical shift only: EventStatusCard/All Variants (4.1%, rows shifted ~5px), TestingInit/Playground (3.7%), … 3. Chart anti-aliasing noise (6) — sub-0.4% edge jitter, safe to accept: FunnelChart/Smaller Screen (3.2%), UpliftChart (single 1px mark), … New stories (12) — first baseline, nothing to compare: Button/AllVariants, …

Never accept from inside the triage step — surface the buckets and let the human decide, or do it explicitly in recipe 3.