Writes one component's documentation entry from its code, stories and real call sites, in a Geist-style page order. Use for "document the button", "write docs for Select", "what states does Toast have", usage rules for a component, or a new or changed component. Skip foundations, overview pages and multi-component patterns. Docs for a whole design system go to design-system-boss.
Real-world examples not captured yet
This skill shows a gallery of live HTML demos (CDN libraries welcome — GSAP, Three.js, etc.) rendered inline via srcdoc.
Skill markdown
# Component docs
A draft entry for one component, built only from what its sources say. Gaps are marked, not filled. It does not judge the design and it publishes nothing. The heading order and a worked example are in `references/doc-format.md`.
## Steps
1. Paste the nine headings from `references/doc-format.md` into the draft, empty.
2. Find the component. Read its code, props type, styles and stories, and record each as a Sources line.
3. Find two real uses, by call-site search or from the ask. One real use or none changes the stop table below.
4. Trace which source gave each example, variant, prop, state and token. Every disagreement between sources is a line under Conflicts, with the quoted rule that settles it, or "no rule, not chosen".
5. Fill each section from sourced facts, copying token names and example code character for character.
6. Write Usage rules last. Each rule is `rule/<component>-<slug>`, a condition, an action, a reason, its evidence (two call sites, a measurement with its path, a named principle, or the person's words), and a `Don't:` line with real code that breaks it. A rule you cannot break with a snippet is cut.
7. Fill Guessed at, one line per judgement call. Reread the draft against the Done list below.
## Output
The entry, then Sources, Conflicts, Guessed at, and Gates (a question with its default) only where a rule adds one. Run on its own, it saves to `docs/system/<name>.md` with a draft comment on line 1 and writes each missing example file. The reply opens with the path, what the entry covers and its status, then up to three questions with defaults and one prompt the person can paste to take the next step.
## Stops
| Missing after searching | Why it stops |
|---|---|
| The code | Nothing else sources the variants, props or behaviour |
| The variant list (props type or stories) | A guessed list documents a different component |
| Any use, real or planned | Invented uses read like real ones and readers copy them first |
A props type with no variant prop is an empty list. Variants reads "None" and the run goes on. One real use, planned uses and a deprecated predecessor are marked as such, not stopped on. A stopped run returns the stop, the facts sourced so far by section, and the smallest reply that unblocks it ("one screen name, what put the component there, and which variant showed").
## Rules
- Never write a variant, prop, token name, example or use that has no listed source. A planned use says planned.
- Never invent a state or a precedence order to make a section look complete.
- A behaviour that looks like a bug is written as it is, followed by a `Defect:` line to the owner with what goes wrong for the user and the smallest fix.
- A part also used on its own gets a `### Parts` subsection under Description. A compound component (`Tabs` with `Tab`) is one entry.
- Do not edit the code, stories or spec being documented.
- Counts in the reply come from `grep -o` on the saved file, below the draft comment.
## Done
Every variant, prop, token and example has a Sources line. Every Usage rule has evidence and a `Don't:` line. Every conflict is shown. The nine headings are present in order, and a section with nothing sourced reads `Not applicable: <reason>`.More from arla6ka
- Build Design SystemUse when an ask names one phase of design system work, such as "extract tokens from the app" or "add states and specs to our Button", or for an empty repo, such as "start a design system from scratch". A whole-app ask on a shipped app ("we need a design system") goes to design-system-boss when it is installed. Moving an app onto an existing system is migrate-design-system.
- Design System BossUse for vague whole-app design system asks on an app that already ships UI, like "our UI is a mess, fix it", "we need a design system", "we hardcode colors everywhere", "make the buttons consistent for an upstream PR", "document our whole design system" or "check the app before I ship". Triages the app, then runs the design.how skills in order. One named screen goes to ui-review, one component to component-docs, an empty repo to build-design-system.
- LimeLime design system rules for this project's UI. Use when building or changing any screen, component, form or style, when porting an existing screen onto Lime, or when checking UI against Lime.
- Migrate Design SystemUse when an app has to move onto a design system that already exists, such as "migrate the app to our design system", "move every screen onto the new components", a rollout, or an adoption audit. When design-system-boss is installed and nobody has checked the system's specs, the boss triages first, since a migration copies a weak system's gaps everywhere. Not for making the system.
- QuartzQuartz design system rules for this project's UI. Use when building or changing any screen, component, form or style, when porting an existing screen onto Quartz, or when checking UI against Quartz.
- Token MappingReports how hardcoded style values on a page, file or diff map onto a project's existing design tokens, purpose first, then value. Use for "are we using our tokens here", "which hardcoded colors map to which tokens", a token audit or planning a token migration. It never edits and never creates or renames tokens. Fixes and whole-app consistency go to design-system-boss.