How to Auto-Generate Component Docs From Figma
For Design systems teams writing component docs · Based on UI Collective AI Design System Audit Workflow
// TL;DR
Design systems teams can use this workflow to turn undocumented Figma components into structured markdown drafts covering Name, Purpose, When to Use, When Not to Use, Properties, Accessibility, and Notes. You create a 'design system documentation' Project Rule that instructs Cursor to document only what exists — no new components, no opinions, no unconfirmed assumptions — then run '@generate documentation' on a simplified component selection. The output feeds directly into ZeroHeight, Supernova, or an internal doc site as a first draft you refine. It's fastest way to close documentation gaps without writing every section from a blank page.
Why is component documentation always behind?
Most design systems teams have components but no written docs — a button with six variants and zero usage guidelines is a common reality. Writing documentation from scratch for every component, variant, and state is slow, and it's the work that always gets deprioritized. The UI Collective AI Design System Audit Workflow uses Cursor and the Figma MCP server to generate structured first drafts, so you're editing instead of authoring from zero.
How do I set up the documentation workflow?
First, create a Cursor Project Rule named 'design system documentation.' Its directives are critical: the goal is to document what exists, not redesign or expand; reference only provided components or Figma links; use plain language describing what the component is, where it's used, and why it exists; never introduce new components or rules; confirm assumptions rather than stating them as fact; don't over-explain theory; and consider accessibility and usage guidelines.
Then build a `@generate documentation` command that identifies what's being documented, reviews it as a whole (what problem it solves, where it appears, what makes it different), and writes in a fixed format: Name, Purpose, When to Use, When Not to Use, Properties, Accessibility Guidelines, Notes. Output is a markdown file, one section per item, no opinions.
What does generated documentation look like?
For a button component, select just the primary and secondary variants in Figma — not all six at once — copy the link, and invoke `@generate documentation`. Cursor returns markdown like:
- When to Use: Primary button for the single highest-priority action per view.
- When Not to Use: Do not use alongside another primary button.
- Properties: size, icon slot, state.
- Accessibility Guidelines: contrast ratio, focus ring requirement.
You copy this into ZeroHeight and supplement it with annotated screenshots. The draft covers variants, use cases, states, behaviors, props, and accessibility notes — the structure that's tedious to build by hand.
How do I keep the output accurate?
Follow Document What Exists, Not What Could Exist: your rule must instruct the AI to confirm assumptions rather than present them as fact. Follow Simplify Before You Scale: scope to a specific, simplified selection to reduce errors and noise. And follow Clarity Over Completeness: keep docs short, plain-language, and free of internal jargon unless provided. Developers write developer content; designers write usage and accessibility guidelines.
Can I audit documentation I already have?
Yes — even with existing docs, run `@generate documentation` to check for missing elements, incorrect usage guidelines, or gaps. Compare the AI's structured output against your current pages to surface omissions in states, accessibility, or when-not-to-use guidance that manual writing often skips.
What's the one rule I can't break?
Never hand raw generated markdown to developers. It's a structured first draft, not a finished handoff document. Review it line by line, confirm assumptions, and dialogue with the AI to expand or tighten sections before it goes anywhere near production.
Next step
Create your 'design system documentation' Project Rule and `@generate documentation` command in Cursor, then run it on two variants of a single component. Review the markdown, refine your rule based on what's off, and once the quality holds, expand to more components and pipe the output into your documentation platform.
// FREQUENTLY ASKED QUESTIONS
What documentation sections does the command produce?
The '@generate documentation' command outputs Name, Purpose, When to Use, When Not to Use, Properties, Accessibility Guidelines, and Notes for each item. It documents what exists in plain language, covers variants, states, behaviors, and props, and avoids opinions, new components, or unconfirmed assumptions.
Should I document all variants of a component at once?
No — scope to a simplified, specific selection like one or two related variants. Feeding all variants at once produces errors and noise. Validate output quality on a narrow scope first, then expand incrementally following the Simplify Before You Scale principle.
Can I paste the generated docs straight into ZeroHeight?
You can use the markdown as structured input, but review it first — it's a first draft, not finished. Copy it into ZeroHeight or Supernova, supplement with annotated screenshots, confirm any AI assumptions, and tighten sections through dialogue with the AI before publishing.