The design must be exact. Only the data may differ.
design-qa is a Claude Code skill that checks a build against its Figma design in every state the design defines, and turns what it finds into fixes, Figma updates and tickets.
I designed and built it end to end with Claude Code: the parity contract, the state model, the interactive report, the scripts, and the showcase film below, rendered from code.
Key results
- Every designed state — with data, empty, loading, error, hover, focus, selected, each captured at the Figma frame’s exact size (Qualitative)
- A report and a fix plan — one for people to review, one a coding agent can act on, from the same run (Qualitative)
- You pick the fixes — the rest becomes tickets and a debt log, created only after you confirm (Qualitative)
design-qa
In alpha
The design-qa showcase film, running live in this page from its own code. Acme Console, ticket ACME-482 and the preview URL are sample content.
Cut from the design-qa showcase film, running live. Acme Console is sample content.
Check every state the design defines
The bet
When engineering moved a ticket to QA, a designer had to stop their own work, switch context and check the build against Figma, often several times for the same ticket. They kept finding differences that should never have shipped, because the components were already defined in Figma. Not every state is in the handoff, and it doesn’t need to be: when a pattern is already built, working and documented, we reuse it. I built design-qa to give that time back, and to let engineers hand the fixes to a coding agent or a group of agents.
QA rounds pull designers away
Every round interrupts a designer’s own work, and one ticket can come back several times.
States get skipped
Empty, loading, error, hover and focus states are designed in Figma, rarely compared with the build, and sometimes never built.
Products are a mix
Enterprise products mix design-system components, custom components and components from a newer design system, sometimes on the same page. Checking the build means knowing which is which.
The usual review → the bet
A designer stops their work to check each build against Figma by hand, sometimes several times per ticket.
A rule a script can check and a coding agent can fix: the design must match exactly, and only the data may differ.
Every style check compares the value in Figma with the value the browser computed.
One command checks every designed state
How it works
Give it a Figma link, a Jira ticket or a preview URL, in any combination. It reads the design and the acceptance criteria, drives the app into each designed state at the Figma frame’s exact size, compares computed styles and pixels, and classifies every difference.
Designing the verdict
The design work
Most of the design work went into three questions: what a difference means, who resolves it, and when a pass is finished.
Four outcomes for every difference
A pixel diff flags every changed name and number, so the real defects get lost among them.
Every difference gets one of four outcomes: fix the code, update Figma, sign off an intentional change, or accept it as data. Each finding is pinned on the capture and, when the source code is available, traced to its token and line of code.
Every state gets a verdict
A designed empty state that was never built is invisible to a screenshot review.
Expected states merge from Figma, the ticket’s acceptance criteria and the project config. A state that was designed but never built is a blocker. A state that isn’t in the design handoff is a question, not a defect. The team often reuses a pattern that is already built and documented elsewhere, so the person accepts it as that pattern, with their name and the date recorded, or sends it to Figma. If the design system has no such pattern, the skill flags a gap in the design system. A state the skill can’t reach is reported as unverified, with the missing hook named.
You choose what gets fixed
A report is only useful if someone acts on it, and an agent that fixes everything without asking creates new risk.
The report’s board splits findings into fix now and debt. What you pick goes to the coding agent as paste-ready prompts; the rest becomes tickets and a design-debt log. Blockers can’t become debt. The debt log records where the product departs from its design, so the debt is written down instead of rediscovered on the next pass.
Open source on GitHub, soon
Where it stands
As of September 2026: version 0.1.0 runs on real product work, and a group of outside alpha testers gets it next. An adversarial review found that a report with no evidence could still pass. The public release waits until a report with missing evidence is marked incomplete.
No measured results yet
It runs on real projects, but defects caught, false positives and review time haven’t been measured yet. The first figures will come from the alpha group.
Motion isn’t checked yet
Captures are static, so transitions and animation aren’t checked yet. They are on the roadmap.
What worked, what I’d change
What worked
A rule a script can check
I turned “only the data may differ” into four outcomes, a report schema and a validator, so the pipeline can recompute a pass instead of relying on a reviewer’s judgement.
What I’d change
List the evidence first
I built the verdict before the list of evidence it depends on, and the review found that an empty report scored 100%. The first fix is a list of expected checks, so a run that checked nothing can’t pass.
FAQ
When can I use it?
Soon. A group of alpha testers gets it first; then design-qa goes open source on my GitHub under the MIT licence, once the fixes from the review are in. It installs as a Claude Code plugin, or as a skill folder you copy into a project.
What does it need to run?
Any mix of a Figma link, a Jira ticket key and a preview URL. A ticket key alone is often enough: the skill reads the Figma links, acceptance criteria and preview URL from the ticket. When a tool is unavailable it steps down, from the Figma MCP to the REST API to exported values, and the report records each step.
Why a skill and not a standalone tool?
The fixes are made in the code, so the skill runs inside the coding agent: it reads the project’s own tokens and components and hands its fix plan to the agent that makes the change.