Skip to the usage guide
Component Specby Owl-Listener

Component Spec Skill.

Make one component implementable by explaining its behavior as carefully as its appearance.

  • Design Systems
  • Specifications
Source Review · Component SpecSKILL.md
Task Design Systems Produces • An anatomy and variant specification • A props table with types, defaults, and required status • State, behavior, accessibility, and usage rules Before You Start Provide the component's purpose, visual variants and target platform. The output is a specification for implementation and testing, not an implemented component.
Editorial summary · source reviewed 2026-10-07 · not a generated example

01 What It Does

Component Spec: Specify One Library Component

A single-component contract covering anatomy, API, variants, interaction states, accessibility, and use.

Source-based workflowNot an execution benchmark

The Working Approach

Component Spec defines a single design-system component. It organizes the handoff around anatomy, variants, API properties, interaction states, responsive behavior, accessibility, and usage. Required and optional parts are made explicit.

Its purpose is agreement between designers and developers. A button's loading behavior or a dialog's focus return is not captured by a static screenshot. The source therefore asks for examples and edge cases, while keeping broader documentation templates and multi-component patterns outside this task.

Expected Deliverables

  • An anatomy and variant specification
  • A props table with types, defaults, and required status
  • State, behavior, accessibility, and usage rules
See the Example Brief

From Brief to Review

  1. 01
    Set the Component Boundary

    Define its purpose, when to use it, and required versus optional parts.

  2. 02
    Specify API and States

    Name properties and variants, then describe default, focus, disabled, loading, and relevant error behavior.

  3. 03
    Resolve Interaction Details

    Document keyboard, focus, responsive, and edge-case behavior with examples that implementation can check.

02 When to Use It

When to Use It

Provide the component's purpose, visual variants and target platform. The output is a specification for implementation and testing, not an implemented component.

A Good Fit

  • A New Library ComponentUse before multiple teams implement competing versions of the same control.
  • An Ambiguous HandoffClarify what changes between variants and how state transitions behave.

Limits to Check

  • Not the Whole LibraryThe scope is one component rather than a full design-system architecture.
  • Specification Is Not ImplementationA written accessibility rule still needs to be implemented and tested.

Bring These Inputs

  • Component PurposeState the user task and related controls.
  • Existing ExamplesSupply visual variants and current behavior.
  • Platform ContractIdentify framework, input methods, and accessibility expectations.

03 Decisions That Matter

Decisions That Matter

  1. Behavior Is First-Class

    States and transitions become part of the handoff rather than developer guesswork.

  2. Shared Vocabulary

    Prop names and anatomy labels connect design decisions with implementation.

04 Try a Focused Brief

Try a Focused Brief

The example brief below has not been tested. Check the skill’s setup before using it.

Review the Setup

Load this task's SKILL.md from the designer-skills repository in your agent's supported skill location. No universal installer command is established by the entry file.

Upstream Source File
https://github.com/Owl-Listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-systems/skills/component-spec/SKILL.md

Provide the component's purpose, visual variants and target platform. The output is a specification for implementation and testing, not an implemented component.

Start With One Deliverable

Adapt the scope, source material and constraints in this brief before running the skill.

Example Brief
Use component-spec to document our async submit button. Specify anatomy, sizes, props, focus, loading, disabled, and error behavior. Explain repeated clicks and keyboard activation, and include when a link should be used instead. Do not claim that the component is already implemented.

Inspect the Result

Check the actual output against these observable criteria.

  • Properties have explicit defaults and requirements.
  • Every relevant state has a behavior example.
  • Keyboard and focus expectations can be tested.

OpenDesign provides a local design workspace for coding agents. This listing does not mean the skill is bundled or that its external tools, credentials and software dependencies are included.

05 Source and License

Source and License

This page describes the pinned source revision linked below. Upstream behavior and requirements can change.

Source Owner
Owl-Listener
License
MIT
Reviewed Snapshot
2026-10-07 · 9a6930cf84a8
Editorial Source Summary
A single-component contract covering anatomy, API, variants, interaction states, accessibility, and use.

Original summary by OpenDesign, based on the linked source. Repository stars are a dated popularity signal, not skill usage or a quality score.

06 Questions Before You Start

Questions Before You Start

Will it generate production code?

It is intended to produce a specification that developers can implement. Building and testing the component are separate steps.

Does it include accessibility?

Yes. Roles, keyboard navigation, screen-reader behavior, and focus management are explicit sections.

How is it different from a pattern library?

It specifies one component; a pattern describes a broader problem-solution arrangement.

OpenDesign

Make Room for the Next Design Iteration.

Keep your brief, source material and design work together in a local workspace. Check the skill’s own setup before adding it to your workflow.

Upstream Source File
https://github.com/Owl-Listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-systems/skills/component-spec/SKILL.md