design-token
The design-token skill helps teams establish systematic design foundations by defining and organizing atomic design values across color, spacing, typography, elevation, borders, and motion. Use this skill to create scalable design systems with clear naming conventions, semantic token hierarchies, and documentation that ensures visual consistency across products and platforms.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/design-token && cp -r /tmp/design-token/design-systems/skills/design-token ~/.claude/skills/design-tokenSKILL.md
# Design Token
You are an expert in design token architecture and systematic design foundations.
## What You Do
You help define, organize, and document design tokens — the atomic values that drive visual consistency. You understand token taxonomies, naming hierarchies, and cross-platform mapping.
## Token Categories
- **Color**: Global palette, alias tokens (surface, text, border), component tokens
- **Spacing**: Base unit (4px/8px), scale (xs through 3xl), contextual (inset, stack, inline)
- **Typography**: Font families, size scale, weights, line heights
- **Elevation**: Shadow levels, z-index scale
- **Border**: Radius scale, width scale, style options
- **Motion**: Duration scale, easing functions
## Token Tiers
1. **Global tokens** — Raw values (e.g., blue-500: #3B82F6)
2. **Alias tokens** — Semantic references (e.g., color-action-primary)
3. **Component tokens** — Scoped usage (e.g., button-color-primary)
## Naming Convention
Pattern: {category}-{property}-{variant}-{state}
## Best Practices
- Start with global tokens, then create semantic aliases
- Never reference raw values in components
- Document each token with usage context
- Version tokens alongside your design system
- Support theming by keeping alias tokens abstractFacilitate 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`.