← LeaderboardThe Skill Leaderboard

component-spec

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`.

Published by Owl-Listener ↗Owl-Listener/designer-skills

Try your first task

Draft a specification for one component

Start a fresh conversation.

Use the component-spec skill to draft an implementable specification for the <component-name> component. Cover its purpose, anatomy, variants, props or API, states, behavior, accessibility, edge cases, and concise do/don't guidance. Use the supplied design-system conventions and component evidence; label unresolved decisions instead of assuming them.

Required inputs

  • Component name and purpose
  • Existing designs, implementation, or requirements at <path-to-component-materials>
  • Relevant design-system conventions and constraints

Suggested template by Skill Leaderboard, grounded in the linked source. Task evidence ↗

SKILL.md

name: component-specdescription: 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`.

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