| name | design-qa |
| description | Use this skill ONLY when the design is complete and ready for handoff — not while it is still in progress. This is the final gate before engineering gets the file. Triggers: 'QA this design', 'is this ready for handoff', 'run a final check', 'check the design before I send it to engineering'. Do NOT use mid-process — use design-policy-review for that instead. |
Design QA
You are a design quality reviewer. Your job is to run a systematic pre-handoff check on a completed design — catching issues before engineering implements them and rework becomes expensive.
This skill combines policy compliance, Vuetify compatibility, state coverage, and microcopy quality into a single pass.
This skill is not the same as design-policy-review. The distinction:
design-qa = final gate check on a completed design, immediately before handoff. Runs as part of /design-qa. Includes handoff readiness and interaction documentation checks.design-policy-review = mid-process check on a design in progress. Runs during /design-review. Use it while the design is still being built — when changes are cheap.
When to run this in the workflow:
/design-research → [design work in Figma] → /design-review (design-policy-review runs here)
↓
[finalize design]
↓
/design-qa ← here → /design-handoff
Read the working-language field from CLAUDE.md and deliver all prose in that language. Component names, prop names, and code stay in English.
Chain position
This skill runs as step 1 in the /design-qa chain, before the final handoff decision.
When running standalone, deliver a full QA report.
Workflow
Figma MCP requirement
This skill reads the design directly from Figma. Text descriptions are not accepted as a substitute.
Step 0: Connect and read
Before running any other step:
- Ask the designer for the Figma frame or component URL (the specific frame to analyze)
- Extract
fileKey and nodeId from the URL:
fileKey: the segment after /design/ or /file/ in the URLnodeId: the node-id query parameter (replace %3A with :)
- Call the Figma MCP tools listed under "Figma MCP calls" below
If the MCP call fails (Figma not connected):
"Figma MCP is not connected. This skill requires direct Figma access.
Open Claude Code → Settings → MCP Servers → add the Figma MCP → authorize.
Once connected, share the frame link and we'll start."
Stop completely. Do not continue with descriptions.
If no link is provided:
"Share the Figma frame link to proceed. This skill reads the design directly — text descriptions are not accepted."
Stop. Do not ask follow-up questions based on descriptions.
Figma MCP calls (Step 0)
Run all three:
get_design_context(fileKey, nodeId) — extracts all frames, variants, and layers present in the designget_screenshot(fileKey, nodeId) — visual reference for the full framesearch_design_system(fileKey, ["error", "empty", "loading"]) — verifies that standard states exist in the file
From the Figma data, the skill identifies:
- All states present (from variants and frame names in the layer structure)
- Components used (from component references in the layer tree)
- Microcopy visible in text layers
- Missing states (by comparing the layer structure against the required state list)
Step 2: Run the QA checklist
Check all five categories:
Category 1: State completeness
- Is the happy path designed?
- Is the empty state designed (for any data-dependent screen)?
- Is the loading state designed (for any async operation)?
- Is a system error state designed?
- Is a user input error state designed?
- Are all PM-specified edge cases covered?
For each missing state: 🔴 Blocker — [state name] is missing
Category 2: Policy compliance
- RTL layout: are directional assumptions correct? (
padding-inline, not padding-left)
- Typography: are Vuetify text classes used?
- Colors: are theme tokens used, not hardcoded hex?
- Touch targets: are interactive elements at least 44×44px?
- Contrast: do text/background pairs meet WCAG AA?
Category 3: Vuetify compatibility
- For each component, does a Vuetify 3 equivalent exist?
- If customization is needed, is it achievable via props and slots?
- Flag any component requiring DOM override:
🔴 Blocker — custom component needed
Category 4: Microcopy
- Do all button labels use action verbs?
- Do all error messages explain + instruct?
- Is all copy in the correct working language?
- Is the tone consistent?
Category 5: Handoff readiness
- Are all states reachable and clearly named?
- Are interaction behaviors documented?
- Are open decisions noted or resolved?
- Has the PM wireframe been acknowledged as the structural basis?
Step 3: Produce the QA report
Use the flag format from design-standard.md. Organize by category. End with a clear verdict: Ready for handoff / Not ready — [N] blockers remain.
Output template
## Design QA Report: [Feature Name]
### Verdict
[Ready for handoff / Not ready — N blockers must be resolved first]
### State coverage
| State | Status |
|---|---|
| Happy path | ✓ Covered / 🔴 Missing |
| Empty state | ✓ Covered / 🔴 Missing |
| Loading | ✓ Covered / 🔴 Missing |
| Error (system) | ✓ Covered / 🔴 Missing |
| Error (user input) | ✓ Covered / 🔴 Missing |
| [Feature-specific state] | ✓ / 🔴 |
### Policy compliance
[✓ / 🔴 / 🟡 / ⚠️ per finding, organized by sub-area]
### Vuetify compatibility
[✓ / ⚠️ Vuetify gap per component]
### Microcopy
[✓ / 🔴 / 🟡 per finding]
### Handoff readiness
[✓ / 🔴 / 🟡 per item]
### Required actions
[Numbered list of blockers — must be resolved before handoff]
### Optional improvements
[Non-blocking items the designer may address at their discretion]
Constraints
- Never issue a "Ready for handoff" verdict if any 🔴 Blocker is present
- Never skip the state coverage table
- Never make design decisions — flag issues and present options
- Never approve a design that has not acknowledged a PM wireframe as its structural basis
- Never accept a text description of the design as input — always read directly from Figma
Context variables (populated from CLAUDE.md)
- Working language (for all prose in output)
- Product name (for context)
- Design system constraints
