0 min read

Generate a Component Spec From Figma

Designers

Claude Skill

TL;DR:

Documenting a component by hand means listing every variant, every property, every state, then writing the usage guidance nobody gets around to until something's already been misused. I built this as a Claude skill that reads the component straight from Figma, drafts a starting definition and usage guidance from what it finds, previews the whole thing for you to approve, then writes it into Figma as an actual documentation frame beside the component.

Why This, Specifically

A component's variants and properties are accurate transcription of something Figma already knows, no taste required. Usage guidance, when to reach for this component, what counts as real misuse, takes more judgment, but even that goes faster from an informed first draft than a blank page. This skill handles the transcription completely and gives you a real starting point for the judgment part.

How It Works

Source of truth: every variant, property, state, and piece of anatomy comes from reading the actual Figma component directly.
Two modes: document a component for the first time, or update an existing spec against the component's current state. Update mode reads both the component and the existing frame, diffs them, and only rewrites what's actually changed, marking each changed value with an UPDATED badge and leaving the rest of the document untouched.
Drafted starting content: the skill drafts a suggested definition, when-to-use, and when-not-to-use from the component's real structure, its anatomy, its properties, what it's built from, and hands it to you to keep, edit, or replace.
Accessibility, honestly labeled: you're asked whether the accessibility behavior you're describing has been verified against a real implementation, or is the intended design behavior. That distinction carries into the document as a visible label.
Built to be read again: the frame uses a consistent, flat naming convention section by section, and the component itself gets Figma's native description and documentation-link fields set, so a future skill, or a future you, can find and read this spec without hunting for it.
Batches: it's been tested against a batch of components in a single pass and held up. Even so, going one component at a time is still the better habit, it gives you a chance to catch a wrong assumption or a misread property early, before it's repeated across twenty components instead of one.

The Skill

It runs the full sequence: a short setup interview, a live read of the component from Figma, a complete HTML preview you approve before anything is built, then the actual Figma frame, bound to your design system and placed right beside the component it documents.

When and How To Use It

Works for a component that's never been documented, or one whose documentation has drifted out of date. Point it at the component either way and it asks which situation you're in.

Any of these will trigger it:

document this Button component in Figma

write a component spec for this

generate design system documentation for this component

update the documentation for this component, it's changed since it was last written

give me usage guidelines and accessibility notes for this

A Note on What This Skill Can and Cannot Do

It can get things wrong, same as any of these. The drafted definition and usage fields are a starting point built from the component's structure and general reasoning about what that implies. Read them before approving. The same goes for accessibility notes: an "unverified" label just means it hasn't been checked yet, treat it as a prompt to verify, not settled fact. Check the preview before approving it, and check the actual frame in Figma after it's built, the same two-checkpoint habit that matters for any of these skills, a run can report success and still have missed a badge or bound the wrong token.

This skill is a structured prompt. It instructs Claude to evaluate without softening criticism, but it does not guarantee accuracy. Claude can still miss things, misread context, or produce confident-sounding findings that turn out to be wrong. The output is a starting point for your own judgment, not a substitute for it.
Treat any finding that would drive a real decision as something to verify independently before acting on it.

One limitation, not caused by this skill: the Figma MCP has a known, recurring issue reading nodes on a page that isn't currently open in Figma, even with a direct link. This skill asks you to confirm the target page is open before reading, which sidesteps the failure.

Get the Skill

The skill is available free on GitHub.

Download from GitHub

Let's Talk