Purpose
Evaluate a proposed design element by element against an established design system, confirming which existing components it should use, flagging unjustified deviations, and identifying the rare cases that genuinely warrant a new pattern — so designs ship consistent, handoff is faster, and the system doesn't quietly accumulate one-off variants.
When to Use
Invoke this skill when the user asks to:
- Check whether a proposed design uses existing design system components
- Review a screen or flow before developer handoff for consistency
- Decide whether an element should reuse a component or become a new pattern
- Flag where a mockup deviates or drifts from the design system
- Prepare a component audit for a design system review or PR
- Justify (or challenge) a request for a net-new component
Inputs Required
Before starting, collect:
- Design description: The screen, flow, or component being evaluated — described element by element (layout, controls, inputs, cards, modals, etc.)
- System inventory: The available design system components (names and purposes) — e.g., Button, Input, Card, Modal, Toast, Table, Tabs
- Component variants/props: Known variants, sizes, states, or props available for key components (if known)
- Design tokens: Available tokens for color, spacing, typography, radius (if the system is token-based)
- Deviation policy: How strict the team is — "system-first, deviations need approval" vs. "flexible, document exceptions"
- Context of use: Platform (web/mobile/responsive) and whether this is a new feature or an edit to existing UI
If the system inventory is not provided, request it before proceeding — the audit cannot be meaningful without knowing what components exist. If variants and tokens are missing, evaluate at the component level and note where variant-level checks were skipped.
Instructions
Step 1: Decompose the Design Into Discrete Elements
Break the proposed design into a flat list of UI elements. For each element, capture:
- Element: What it is (e.g., "primary CTA button", "email input field", "results table")
- Function: What it does in the flow
- Visual/behavioral notes: Anything specified — size, state, color, spacing, interaction
Every subsequent step operates on this element list. Aim for one row per meaningful UI unit, not per pixel.
Step 2: Match Each Element to a System Component
For each element, assign one of four match verdicts:
- Exact match — An existing component and variant covers this element as-is. Name it.
- Component match, variant/prop gap — The right component exists, but the needed variant, size, or state isn't in the inventory (or wasn't confirmed). Name the component and the missing variant.
- Approximate match — An existing component could serve this with minor adaptation (a prop change, a token swap). Name it and describe the adaptation.
- No match — No existing component fits this element's function.
Prefer reuse. Only assign "No match" when the element's function — not just its styling — is genuinely absent from the system.
Step 3: Flag Inconsistencies and Drift
Scan the design for signals that it deviates from the system even where a component exists:
- Reinvented components: A custom element that duplicates an existing component's function (e.g., a hand-built dropdown when a Select component exists) — the single most common and highest-cost drift
- Off-token values: Colors, spacing, type sizes, or radii that don't map to available tokens
- State/interaction gaps: Hover, focus, disabled, loading, empty, or error states missing from an element that the system component handles by default
- Inconsistent patterns: The same function styled differently across the design, or differently from how the system handles it elsewhere
- Accessibility regressions: Deviations that drop touch target size, contrast, or focus visibility below what the system component guarantees
Log each as a discrete finding with severity: High (reinvents an existing component or breaks accessibility), Medium (off-token or missing states), Low (cosmetic, low-risk).
Step 4: Adjudicate New-Pattern Requests
For every "No match" element and every reinvented component, apply the new-pattern test. A new pattern is justified only if it passes all four:
- Functional gap: No existing component covers this function, even with adaptation
- Recurrence: The need will appear again elsewhere — not a one-off
- Non-composable: It can't be built by composing existing components/tokens
- Owner-ready: Someone can own it, document it, and add it to the system
Return a verdict per element: Reuse existing (name it), Adapt existing (name the adaptation), Compose from primitives (name the parts), or Net-new justified (with which criteria it passes). Default toward reuse or composition; "net-new justified" should be the exception.
Step 5: Summarize the Reuse Ratio and Priority Fixes
Produce a headline verdict:
- Reuse ratio: X of Y elements map cleanly to existing components (count them)
- Top priority fixes: The 3–5 highest-severity findings, ordered by cost of leaving them unresolved
- Handoff readiness: Ready / Ready with noted exceptions / Not ready — needs system alignment first
Output Format
- Structure: Element-by-element audit table, followed by an inconsistency log, a new-pattern adjudication list, and a summary verdict
- Length: 700–1,100 words
- Format: Tables for the component audit and inconsistency log; a short structured list for new-pattern adjudication; prose for the summary
- Sections: Element Breakdown & Component Match (table) → Inconsistency & Drift Log (table with severity) → New-Pattern Adjudication (per-element verdicts) → Summary: Reuse Ratio, Priority Fixes, Handoff Readiness
- Tone: A design systems reviewer — precise, reuse-first, opinionated about drift but constructive; names components and tokens explicitly rather than speaking in generalities
Quality Checklist
Before delivering output, verify:
- [ ] Every element in the design has a match verdict (Exact / Variant gap / Approximate / No match) — no element left unassigned
- [ ] Each inconsistency finding carries a severity label (High / Medium / Low)
- [ ] Every "No match" and reinvented element runs through all four new-pattern criteria before a net-new verdict is given
- [ ] The reuse ratio is stated as an actual count (X of Y), not a vague "mostly consistent"
- [ ] Named components and tokens come from the provided inventory — not invented ones
- [ ] Handoff readiness is stated as one of the three defined verdicts, not hedged
Notes
- Reinvented components are the highest-cost drift because they look fine in isolation but multiply maintenance forever — weight them heavily.
- "Approximate match" is usually the right answer more often than designers expect; most perceived gaps are variant or token gaps, not true functional gaps.
- If the deviation policy is strict, treat off-token values as High severity; if flexible, Medium — the same finding, calibrated to team norms.
- When the system inventory lacks variant detail, be explicit about which checks were done at the component level only, so the reviewer knows what still needs a variant-level pass in Figma.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills