Produces a component specification covering states, anatomy, token mappings, and accessibility requirements.
play · specify-component
You are helping me write a component specification — a complete design and behavior description that can be implemented consistently against my design system.
**Step 1 — Read the living brief:**
Read `LIVING_BRIEF.md`. Note the token naming convention, the shape scale, and any component decisions already recorded.
**Step 2 — Read the references:**
Read the following from the Sistema knowledge base:
- Token architecture synthesis: `{{sistema_url}}/raw/principles/tokens/architecture`
- Accessibility floor: `{{sistema_url}}/raw/principles/accessibility/floor`
The token architecture synthesis defines the naming convention your spec should use for token references. The accessibility floor defines the non-negotiable requirements for every interactive component.
**Step 3 — Write the specification:**
Component: [e.g. Button, Text Input, Card, Modal, Chip, Badge]
My token context:
[Describe your CSS custom property naming pattern (e.g. `--color-primary`, `--color-on-primary`, `--radius-md`) or paste the relevant token names your spec should reference.]
Use this exact document structure:
```
# [Component Name] Specification
## Variants
[Table: variant name | description | when to use]
## Sizes
[Table or "single size" if applicable]
## States
[Table: state | visual change | token consumed]
Include: default, hover, focus, active, disabled.
## Token Map
[List every token the component consumes: property → token name]
Group by: container, text/label, border, shape, typography.
## Accessibility
- ARIA role and required attributes
- Keyboard interaction (tab, space, enter, escape — per the accessibility floor spec)
- Focus indicator: color token, width, offset (must meet 3:1 contrast per accessibility floor §3.2)
- Minimum touch target: ≥ 44×44px interactive area (per accessibility floor §4.2)
- Accessible name requirement (per accessibility floor §5.2)
## Behavior
[Animation, loading states, icon support, edge cases]
```
Output only the specification document. Token references must use names from my token system — not hardcoded hex values or raw px values for anything covered by a token.
**Step 4 — Update the living brief:**
Append to the decision log:
```
[2026-05-13] — [Component name] spec written — [note any non-obvious decisions]
```
---