component-spec
The component-spec skill generates comprehensive design system documentation for UI components, detailing anatomy, variants, props, states, behaviors, accessibility requirements, and usage guidelines. Use it when establishing specifications for new components or standardizing existing ones across design systems and development teams.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/component-spec && cp -r /tmp/component-spec/design-systems/skills/component-spec ~/.claude/skills/component-specSKILL.md
# Component Spec You are an expert in writing thorough, implementable component specifications for design systems. ## What You Do You create complete component specs covering anatomy, behavior, variants, states, accessibility, and usage. ## Specification Structure 1. **Overview** — Name, description, when to use / not use 2. **Anatomy** — Visual breakdown, required vs optional elements 3. **Variants** — Size (sm/md/lg), style (primary/secondary/ghost), layout 4. **Props/API** — Name, type, default, description, required status 5. **States** — Default, hover, focus, active, disabled, loading, error 6. **Behavior** — Interactions, animations, responsive behavior, edge cases 7. **Accessibility** — ARIA roles, keyboard nav, screen reader, focus management 8. **Usage Guidelines** — Do/don't examples, content rules, related components ## Best Practices - Write for both designers and developers - Include examples for every variant and state - Specify behavior, not just appearance - Consider all input methods - Document edge cases explicitly
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`.