Uiprobe

View saved version →

---
name: design-qa-summary
description: Summarise how a webpage came through against its Figma design, from a Uiprobe probe. Use when the user asks what's different between a design and a page, wants a design QA summary, or wants to share a probe's findings with a designer, developer or PM. Reads existing probes only and never starts a run.
---

# Summarise a probe's findings

The Uiprobe MCP server's instructions explain each tool and how to read a finding's evidence. Follow them. This skill turns a probe's findings into a summary a person can read and share.

It only reads. Don't call `run_probe` or `rerun_probe` unless the user asks for a new run.

## Steps

1. **Find the probe.** If the user gave a probe or viewer URL, use it. Otherwise call `list_probes`, with `nameFilter` when the user named the page or design. If more than one probe fits, ask which one.
2. **Get all findings.** Call `get_probe` and page through with `nextOffset` until you have them all. If the latest run is still `PENDING` or `RUNNING`, say so and offer to wait.
3. **Sort them into sections:**
   - **Properties**, grouped by what differs: text and content, typography, colour and style, size
   - **Spacing**, including layout shifts
   - **Unverified**, kept apart from the rest
4. **Pick a few to show.** Choose up to five findings that are easy to see on the page: grouped findings that cover many elements, and large differences in size, colour or typography. Call `get_finding_images` for them.
5. **Write the summary** in the format below.

## Format

- One line on top: the probe's title (from `list_probes`) and the viewer URL.
- One short paragraph on what came through as designed.
- Per section, one bullet per finding or group: what differs, the design value and the page value, and the `findingUrl`. Put a group on one line and say how many elements it covers.
- The images from step 4, each under its bullet.
- Unverified findings last, as elements Uiprobe couldn't map yet. Don't present them as differences.
- If `get_probe` reports findings hidden by the probe's filters or dismissed, say how many and offer to include them.

Keep it short enough to paste into a chat. Offer a longer version if the user wants every finding.

## Don't

- Rank findings by importance or severity. Uiprobe reports differences; the user decides what matters.
- Explain why a difference exists. You can't see the code or the design process behind it.
- Compare the number of findings with an earlier run.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: match-design
description: Bring a webpage in line with its Figma design using Uiprobe. Use when the user asks to check a page against a Figma frame, fix design differences, do visual QA, or make an implementation "match the design", and gives (or has) a Figma URL and a page URL. Needs a code repository, for example in Codex or Claude Code.
---

# Match a page to its Figma design

The Uiprobe MCP server's instructions explain each tool, how to poll a run, how to expose a local page and how to read a finding's evidence. Follow them. This skill adds the loop around those tools.

## The loop

1. **Find or create the probe.** Call `list_probes` first. If a probe already exists for this design and page, use `rerun_probe` on it so its history is kept. Otherwise call `run_probe`.
2. **Get the findings.** Wait for the run to finish, then call `get_probe`. Page through with `nextOffset` until you have all of them.
3. **Triage before editing.** Group the findings:
   - property findings (text, font, colour, size): fix these first
   - spacing and layout-shift findings: leave them until after the rerun, since many disappear once the property fixes land
   - unverified findings: report them, and don't change code for them unless the user asks
4. **Fix property findings in the source.** Locate each element as the server instructions describe, change the `cssProperty` from `pageValue` to `designValue`, and prefer the project's existing design tokens over raw values when a token matches.
5. **Rerun.** Call `rerun_probe` on the same probe. For a local page, pass the current tunnel URL.
6. **Repeat** steps 2 to 5 until only findings you've reported as intentional or out of scope are left. Stop after three rounds without progress and report what remains. Findings the user calls intentional can be set aside with the `uiprobe:triage-findings` skill.

## Reporting

End with a short summary for the user:

- what you changed, with each finding's `findingUrl`
- what's left, and why you didn't change it
- the probe's viewer URL

Don't change spacing to match the design when it conflicts with the project's layout system (a grid, a spacing scale). Report the conflict instead.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: pr-design-check
description: Check a pull request's pages against Figma with Uiprobe and write a note for the pull request. Use before opening a pull request or asking for review, or when the user asks to check UI changes against the design before pushing. Reports where each changed page stands; it doesn't change code. Needs a code repository, for example in Codex or Claude Code.
---

# Check a pull request's pages against Figma

The Uiprobe MCP server's instructions explain each tool, how to poll a run and how to make a local page reachable. Follow them. This skill decides which pages to probe for a change and writes the result up for the reviewer.

It changes no code and dismisses nothing. To fix findings, use the `uiprobe:match-design` skill.

## Steps

1. **Find the changed pages.** Read the branch's diff and work out which pages it affects from the routes, templates and components it touches. List them for the user and ask whether to add or drop any.
2. **Pair each page with its Figma frame.** Call `list_probes` to find an existing probe for each page: match the page's route with the path of each probe's `webpageUrl`, using `nameFilter` only to narrow the list. An existing probe already links the page to its frame, its `figmaUrl`. Show the user the matches and let them correct them. For a page without a probe, ask the user for the Figma frame URL. If the user has no frame for a page, leave it out and say so in the note.
3. **Get a reachable URL.** Use the branch's preview deployment when there is one. Otherwise make the local page reachable as the server instructions describe.
4. **Say what the check will cost.** Tell the user how many runs it uses, one per page, and wait for a go.
5. **Run the probes.** Call `rerun_probe` for pages with a probe, passing the current URL, so their history is kept. Call `run_probe` for the rest. Wait for each run as the server instructions describe. If a run can't start, for example because the allowance is used up, leave that page out and say why in the note.
6. **Read the findings.** Call `get_probe` for each page and page through with `nextOffset`. The result follows the probe's finding filters and leaves out dismissed findings, the same as the web app.
7. **Write the note** in the format below. Offer to add it to the pull request description, and add it only after the user agrees. Otherwise give it to the user to paste.

## Format

```markdown
## Design check (Uiprobe)

### <page name>
Figma: <frame URL> · Page: <page URL> · Probe: <viewer URL>

Came through as designed: <one line>

Still differs:
- <what differs>: design <designValue>, page <pageValue> ([finding](<findingUrl>))

Couldn't be mapped yet: <unverified findings, one line>
```

The Figma link is the probe's `figmaUrl`, and the page link is the URL you just probed. Group findings of the same kind on one line. Leave out sections that are empty. When a page has nothing that still differs, say so in one line.

## Don't

- Fix findings or edit code. Point to the `uiprobe:match-design` skill instead.
- Start runs before the user agrees to the number of runs.
- Edit the pull request without asking.
- Judge whether the pull request is ready to merge. The note says where the pages stand; the reviewer decides.
- Compare the number of findings with an earlier run.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: triage-findings
description: Go through a Uiprobe probe's findings with the user and decide, group by group, what to fix and what is intentional. Use when the user wants to triage or review findings, mark differences as intentional, or clean up a probe before someone fixes it. Dismisses findings only after the user confirms.
---

# Triage a probe's findings

The Uiprobe MCP server's instructions explain each tool and how to read a finding's evidence. Follow them. This skill walks the user through a probe's findings and records their decisions.

## Before you start

Dismissing a finding hides it for everyone who sees the probe, in the web app, on shared and public links and in CSV exports, and on future runs of the probe. It can always be restored. Tell the user this once, at the start.

## Steps

1. **Find the probe.** If the user gave a probe or viewer URL, use it. Otherwise call `list_probes`, and ask which probe if more than one fits.
2. **Get all findings.** Call `get_probe` and page through with `nextOffset` until you have them all. If the latest run is still `PENDING` or `RUNNING`, say so and offer to wait: findings can only be dismissed once the run has finished.
3. **Go through them in batches of up to five**, groups first, then single property findings, then spacing, then unverified. For each, give one line: what differs, the design value and the page value, and the `findingUrl`. Number them so the user can answer by number. Offer images through `get_finding_images` when a line isn't clear enough.
4. **Ask for a decision per item:** fix, intentional, or skip. For a group, ask whether the decision covers the whole group or only some of its findings.
5. **Confirm before dismissing.** After each batch, list the findings marked intentional and ask once to dismiss them. Then dismiss them with `dismiss_findings`. Dismiss a whole group in one call when the user chose the whole group.
6. **Repeat** until every finding has a decision or the user stops.

## End with

- **To fix:** each finding with its design value, page value and `findingUrl`. In a coding agent, offer to continue with the `uiprobe:match-design` skill. Elsewhere, offer to write the list as tickets.
- **Dismissed:** what was dismissed, and that any of it can be restored by asking.
- **Skipped:** what is left undecided.
- The probe's viewer URL.

## Restoring

When the user wants a dismissed finding back, call `get_probe` with `includeDismissed` to get the dismissed findings' ids, then `restore_findings`, and confirm. Restoring works per finding, also for findings that were dismissed as part of a group.

## Don't

- Dismiss anything the user didn't confirm in this conversation.
- Suggest dismissing a finding because it looks small. Whether a difference matters is the user's call.
- Describe the list as shorter or the findings as fewer after triage. Dismissed findings are set aside, not removed.

Referenced files: 1 — file references are metadata, not package contents.