Component Spec
Produce an implementable design-system component spec with props, states, variants, and accessibility so agents and devs build the same UI.
Overview
Component Spec is an agent skill most often used in Build (also Validate scope) that writes detailed design-system component specifications including props, states, variants, and accessibility.
Install
npx skills add https://github.com/owl-listener/designer-skills --skill component-specWhat is this skill?
- Eight-part spec structure: overview, anatomy, variants, props/API, states, behavior, accessibility, usage guidelines
- Variants cover size, style, and layout with explicit do/don't usage guidance
- States documented: default, hover, focus, active, disabled, loading, error
- Accessibility block: ARIA roles, keyboard navigation, screen reader, focus management
- Written for both designers and developers with examples per variant and state
- 8-section specification structure (overview through usage guidelines)
- 7 interaction states enumerated (default through error)
Adoption & trust: 574 installs on skills.sh; 1.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have UI intent in mockups but no shared spec, so every implementation pass invents different props, states, and a11y behavior.
Who is it for?
Indie SaaS founders documenting reusable UI primitives before or during frontend build.
Skip if: One-off marketing pages with no reusable components, or teams that only need quick Tailwind snippets without a system.
When should I use this skill?
You need a detailed, implementable component specification including props, states, variants, accessibility, and usage guidelines.
What do I get? / Deliverables
You get a complete component specification document ready for design review and agent-driven frontend implementation.
- Markdown or doc-style component specification
- Props/API table with types, defaults, and required flags
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical home is build/docs because the primary artifact is a written specification consumed during implementation. Component specs are design-system documentation that bridges design and frontend work.
Where it fits
Define the MVP component set and document each primitive before committing engineering time.
Author the full spec for a DataTable including loading and error states for agent implementation.
Hand the spec to an agent to generate React props and Storybook stories matching documented variants.
Check shipped UI against the spec’s accessibility and interaction sections during pre-launch review.
How it compares
Use for structured design-system docs instead of informal chat descriptions of a button or modal.
Common Questions / FAQ
Who is component-spec for?
Solo builders and tiny teams creating or extending a design system who need specs both designers and coding agents can follow.
When should I use component-spec?
In validate when scoping MVP UI primitives, and in build when documenting or refactoring components before implementation.
Is component-spec safe to install?
It produces text specifications only; review the Security Audits panel on this Prism page for the skill package source.
SKILL.md
READMESKILL.md - Component Spec
# 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