Check a prototype against its original design direction and requirements before shipping. Compares implementation to the mockup/spec/context, flags drift in layout, spacing, type, color, states, and behavior, and reports a pass/fix list.
SkillScore82Maintained
Automatic
◆Design & UX Review pack
Last verified 8/6/2026
What it changes
Passed 16 of 19 test cases with the skill, and 10 of 19 without it.
Without skill50%
With skill82%
Checks it passed that the model alone missed
Recommends proceeding to design-share
Designates ./design/qa.md as the output file path
Limits final verdict options to READY or NOT READY
and 5 more in the full report
7 fixed11 passed either way4 still failing0 broke
Pass-rate lift
+32 pp
Tokens
+37%
Agent turns
0%
Response time
-25%
Model gemini-3.6-flashMeasured 8/6/2026v118 of 22 cases passed with skill · 19 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 7
Prompt
The QA report for http://localhost:3000/card passed all visual, behavioral, requirements, and accessibility criteria against ./design/context.md. What is the recommended handoff step?
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends proceeding to design-share
Missed
Passed
case-12 · gemini-3.6-flash · 8/6/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md57 linessingle file
Design — Design QA
Verify the built prototype actually matches the intended design + requirements. Catch drift before it ships. Unlike design-audit (open-ended critique of any UI), QA is a conformance check against a known source of truth — it answers "does this match what we agreed to build?"
When to use
A prototype is built and you need to confirm it matches the mockup/spec before review.
Final gate before design-share or dev handoff.
"Does it match the design?", "conformance check".
When NOT to use
No spec/reference to compare against → that's open critique → design-audit.
Nothing built yet → build it first.
Inputs
The built prototype (local URL or path).
The source of truth: reference image/mockup, ./design/context.md, ./design/ideate/*.
Acceptance/success criteria (from context).
Workflow
Capture the implementation via a browser-automation tool — screenshots of key screens and states (loading/empty/error/success).
Visual conformance — compare to the reference: layout, type scale, spacing rhythm, palette, radii/shadows, iconography. Note every drift with the expected vs actual value.
Behavioral conformance — walk the flow: do interactions, states, and navigation match the intended UX?
Requirements conformance — does it satisfy the goal + success criteria from context? Any scope item missing?
Accessibility sanity — contrast, focus order, target size, keyboard reachability (flag what needs manual AT testing — automated checks aren't full WCAG).
Write ./design/qa.md: PASS items + prioritized fix list (severity × effort) + a verdict.
Output: ./design/qa.md
prototype: http://localhost:5173 source: ./mocks/onboarding.png + context.md
visual:
✓ layout matches ✗ body type 14px (spec 16px) ✗ accent #7C3 (spec #6366F1)
behavior:
✓ happy path ✗ no error state on empty name (spec requires inline error)
requirements (vs success criteria):
✓ 3-step wizard ✓ progress saved ✗ missing "skip" affordance (scope v1)
a11y:
✗ CTA contrast 3.1:1 (<4.5) manual: screen-reader pass still required
verdict: NOT READY — 4 fixes (2 HIGH: error state, contrast). Loop to design-prototype.