---
name: skill-design-parity
type: skill
description: Review a UI build against its intended design and write a plain-language verdict Aled can act on without reading the code. Use this whenever running the design-parity pass, or when a ticket in In Review carries PR-1SM and names a design reference (a Figma spec, prototype, or design link) — compare the implemented interface against the design intent and flag divergences in layout and spacing, design tokens, colour and type, missing states, responsive behaviour, and component substitutions. Sibling to skill-qa; formalises the prototype-port regression guard. Review only, never merges or advances the ticket. Trigger it whenever the task is to design-QA, check design fidelity, or sanity-check that a build matches its design in a Linear context.
license: Proprietary — Aled Pritchard workspace use.
---

# design-parity

A design-fidelity review pass — the pair of eyes that confirms a built interface matches the design it was meant to implement, made legible to Aled without him reading code or opening every screen himself. Sibling to skill-qa: same shape, same gate discipline, a design lens. Formalises the prototype-port regression guard (Linear APP-267). Follows convention-linear, convention-github, convention-brand, Pattern A, and the gate policy (Aled is the approver; nothing merges without him).

This is **review only**. It compares build against intent and reports divergences. It never edits the build and never changes ticket state.

## Trigger

Poll for issues in In Review carrying `PR-1SM` where the ticket names a design reference — a Figma spec, a prototype, or a design link in the body or its embedded criteria (Pattern A). If no design reference exists, there is nothing to compare against: note that on the ticket for Aled and stop. Delivery projects only; never the Pipeline team.

## Dedup — one parity verdict per PR state

Keyed on the PR head commit SHA, not elapsed time, so the review re-runs after an In Review to Todo bounce where exec pushes new commits.

1. **Fetch the PR's current head commit SHA.**
2. **Scan existing PR comments** for any comment that starts with `[design] HEAD: [sha]` where `[sha]` is the first 7 characters of the current head commit SHA. Use this as the dedup key.
3. **If a match is found:** skip silently — no comment, no state change.
4. **If no match:** proceed with the full review below.

Every verdict comment **must** begin with:

```
[design] HEAD: [sha7]
```

where `[sha7]` is the first 7 characters of the PR head commit SHA. This line is the dedup key.

## Behaviour

Read the design reference named in the ticket and the implemented interface in the PR diff. Where it helps, read the domain's design system or convention-brand so the comparison is against the right tokens and identity, not a guess. Compare build against intent across the checklist below, then post a plain-language verdict.

**The checklist:**

- **Layout and spacing** — element positions, alignment, padding and margins, grid and gutters against the design.
- **Design tokens, colour and type** — colours, typefaces, sizes, weights, and line-heights drawn from the design system's tokens rather than ad hoc values; flag hardcoded values that should be tokens, and any token mismatch.
- **Missing states** — hover, focus, active, disabled, empty, error, and loading states present in the design but absent in the build.
- **Responsive behaviour** — how the interface reflows across breakpoints versus the design's responsive intent.
- **Component substitutions** — a bespoke or off-system element used where the design specifies a design-system component, or the wrong variant.

Then:

1. **Post the verdict comment on the Linear ticket** (the canonical record). Begin with `[design] HEAD: [sha7]`.
2. **Post the same verdict comment on the GitHub PR** (where Aled reviews). Begin with `[design] HEAD: [sha7]`.

Verdict comes in one of two modes:

- **On design** — a plain statement that the build matches the reference, naming what was compared, so Aled can see the review was real. Note anything the design did not cover or that fell out of scope.
- **Divergences to fix** — the specific gaps, each with: what diverges, where (the screen or component, file and line where it helps), how it differs from the design, and what would bring it on-design. Specific and actionable, so a bounce is self-contained.

Plain language throughout — Aled acts on it without reading the code.

**Hand off to Aled.** Once the verdict is posted, assign the ticket to **Aled**, leaving the label `agent:PR-1SM` and the state **In Review**. Do **not** switch the label to `agent:R3-LAY` and do **not** advance or merge — that is Aled's approval action.

## Guardrails

- **Review only.** Never edits the build, the design, or the design system. It reports divergences for the exec leg to fix on a bounce.
- Does not merge, does not change the ticket's **state** (stays In Review), and does not change the `agent:*` label (stays `PR-1SM`). The one thing it sets is the **assignee to Aled** once the verdict is posted.
- Approve, merge, and bounce are Aled's: his `@relay` approval signal triggers the merge leg; an In Review to Todo bounce re-triggers exec.
- A parity pass makes design fidelity legible; it does not sign off the design itself. Sign-off is human (Pattern A).
- Scope to delivery repos only. Never touches the Pipeline team's work.

## Setup

- Claude Code Desktop, Schedule, New remote task — or run alongside skill-qa in the review lane.
- Connectors: Linear plus GitHub (read for the diff, write for the comments); access to the named design reference (Figma or the prototype link).
- Routine prompt: "Run the design-parity skill."

Owned by **Prism** (`PR-1SM`) — the independent review and quality role.

On finish, run skill-ops-retro capture on this run's friction: file a FRICTION note to the Pulse queue for the drain pass to assess.