design-spec-review

Review component implementations against spec docs for variants, states, accessibility, and tokens.

6|Updated Jul 10, 2026
One-click install
npx skills add https://github.com/Mozurok/fhorja.dev --skill design-spec-review-mozurok
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: design-spec-review
Source: https://github.com/Mozurok/fhorja.dev/tree/main/.claude/skills/design-spec-review
Command: npx skills add https://github.com/Mozurok/fhorja.dev --skill design-spec-review-mozurok

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Design system implementations often drift from their documented specs: missing variants, skipped states, hardcoded values instead of tokens, or accessibility props left out. This Skill systematically compares a component or screen implementation against its spec doc and produces a severity-ranked findings list so drift is caught before release. ## Core Features & Use Cases - Eleven-point fidelity audit: Checks variants, sizes, the six mandatory states, accessibility props, design token usage, motion and haptics, TypeScript API parity, Storybook coverage, anti-patterns, platform specifics, and visual fidelity. - Severity-ranked findings: Reports each issue as P0/P1/P2 with the spec section reference and exact code file:line, ending in an overall verdict of faithful, needs fixes, or significant drift. - Visual fidelity comparison: When a design MCP is reachable, compares the running implementation against the design source; falls back to a source-image comparison when no MCP node exists. - Use Case: After implementing a design-system Button component, run this review to confirm all variants and states from the spec exist, tokens are used instead of hardcoded hex values, and the props interface matches the documented API before packaging the PR. ## Quick Start Review the Button component implementation in src/design-system against its spec doc at docs/research/components/core/button.md and report any drift.

Frequently Asked Questions about design-spec-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a component matches its design spec?▼

Provide the component name, the spec doc path, and the implementation code path. The review runs eleven checks covering variants, sizes, states, accessibility, tokens, motion, TypeScript API, Storybook, anti-patterns, platform specifics, and visual fidelity, then returns a findings list with severity ratings.

What accessibility checks does a design spec review cover?▼

It verifies accessibilityRole or role attributes, accessibilityLabel or aria-label for icon-only elements, accessibilityState forwarding for disabled, checked, and busy states, and documented contrast ratios. Missing props are reported as findings with the exact file and line.

Can I run a design review without a Figma MCP connection?▼

Yes. When no design MCP node id exists but the spec header has a populated Source image field, the review compares a same-state screenshot of the running implementation directly against the source image. Only when neither exists is the visual check deferred.

When should I not use design-spec-review?▼

Do not use it when no spec doc exists for the component; write one first with component-spec or screen-spec. It is also distinct from review-hard, which covers general risk, and repo-consistency-sweep, which handles pattern matching.

Why does the review return a no-op for some components?▼

A no-op is returned when no spec doc exists for the component, since there is nothing to compare the implementation against. In that case the workflow routes you to component-spec to author the spec first.