Component Spec

by owl-listener9a6930cf84a8No license2.8K starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 4 weeks ago

Specify one component — props, states, variants, accessibility, and usage rules. Use when defining a library component. For the reusable doc scaffold use `documentation-template`; for a problem-solution pattern use `pattern-library`.

AI-generated overview

Writes complete design-system component specifications covering anatomy, variants, props, states, behavior, accessibility and usage.

What it does
Guides an agent through producing a full component specification for a design system library. It defines an eight-part structure: overview, anatomy, variants, props/API, states, behavior, accessibility and usage guidelines. It also lists best practices such as writing for both designers and developers, giving examples for every variant and state, and documenting edge cases explicitly. The output is a written specification document rather than code or a visual artifact.
When to use it
Use it when defining or documenting a single reusable library component and a structured, implementable spec is needed. It suits design-system work where props, states, variants and accessibility must be spelled out for both designers and developers.
Requirements
No tools, packages, runtimes or credentials are required; it is instructions only and ships no scripts.

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

Source and attribution

Source:owl-listener/designer-skillsindesign-systems/skills/component-specat commit9a6930c

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal