Individual skill
design-qa-checklist
Runs an ordered design QA pass over an implemented UI - layout, type, color, states, motion, content - against the design spec, with concrete tolerances and a filed defect list. Use when someone asks "QA this build against the designs", "does the implementation match Figma", "is this ready for design sign-off", or before releasing a UI change. Do NOT use for critiquing the design itself - use design-critique instead; for a full WCAG conformance audit, use accessibility-audit; for writing the spec the build is checked against, use design-handoff-doc.
skills/design-qa-checklist/SKILL.md
Source commit 97a13607d669157a4a16d5ba79b77f208319f7b9
What was checked
- Matches the observed repository HEAD
- Yes
- Scanner rules are current
- No
- Repository scan complete
- No
- Skill scan complete
- No
- Observed behavior
- Not checked yet
- Last checked
- Nov 6, 2026
These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.
Install this skill
Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.
An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.
Repository context
- Repository stars (not skill ratings)
- 24
- Repository last updated
- Oct 13, 2026
- License
- MIT
Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.
- claude Repository topic
- claude-skills Repository topic
- skill-me Repository topic
- design Derived category
- writing Derived category
- security Derived category
- design-interface Derived category
Files and excerpt
File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.
Read excerpt
# Design QA Checklist
Design QA catches drift between design intent and shipped code before it compounds into a product that looks 90% right everywhere and fully right nowhere. The costly failure is an unordered spot-check: motion gets polished while the grid underneath is wrong, so half the findings are invalidated by the layout fix. Run the pass in order - layout first, because layout errors move everything downstream - and file every deviation with expected vs. actual values, not adjectives.
## Operating procedure
### Step 1: Gather inputs
- The design source of truth (Figma file, spec, or design-handoff-doc output) and the build URL or branch.
- The token set (spacing scale, type scale, color tokens, motion tokens). If none exists, note that and QA against explicit spec values; flag "no token system" as its own finding.
- Supported breakpoints and the narrowest supported viewport (default: 320px).
- Whether dark mode and motion specs exist (default: assume light mode only, no motion spec - label as assumption).
### Step 2: Layout pass