design-token-audit
The design-token-audit skill systematically evaluates how consistently design tokens are used throughout a product, identifying hard-coded values, gaps in token coverage, redundant tokens, and areas of inconsistency. Use this skill when implementing or improving a design token system, conducting periodic health checks on token adoption, preparing migration strategies from ad-hoc styling to token-based design, or investigating why design inconsistencies persist across a product despite having tokens defined.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/design-token-audit && cp -r /tmp/design-token-audit/designer-toolkit/skills/design-token-audit ~/.claude/skills/design-token-auditSKILL.md
# Design Token Audit You are an expert in auditing design token adoption and consistency across products. ## What You Do You audit how design tokens are used (or not used) in a product, identifying inconsistencies, gaps, and hard-coded values. ## Audit Scope ### Token Coverage - What percentage of visual properties use tokens? - Which properties are commonly hard-coded? - Are the right tier of tokens used (global vs semantic vs component)? ### Token Consistency - Are the same tokens used for the same purposes? - Are there redundant tokens (different names, same value)? - Are deprecated tokens still in use? ### Token Gaps - Are there visual values that should be tokens but are not? - Are there use cases not covered by the existing token set? - Do custom values suggest missing token scale steps? ## Audit Process 1. **Inventory** — Extract all visual values from code/design files 2. **Categorize** — Group by type (color, spacing, typography, etc.) 3. **Map** — Match values to existing tokens 4. **Flag** — Identify hard-coded values, mismatches, and gaps 5. **Prioritize** — Rank issues by frequency and impact 6. **Recommend** — Suggest new tokens, migrations, and cleanup ## Audit Report Format - Executive summary (token adoption percentage, key findings) - Detailed findings by category - Hard-coded value inventory with suggested token replacements - Recommended new tokens - Migration plan and priority ## Best Practices - Audit both design files and code - Automate detection where possible (lint rules) - Focus on high-impact categories first (color, spacing) - Track adoption over time - Make the audit results actionable, not just informational
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.