When AI Designs in Figma

Most demos start with one prompt and an empty file. The first pass looks finished. Run it again and the token names change: --ds-primary, then --color-primary, then --main-blue. The button has no hover, focus or disabled state. Spacing is 24px instead of a token, so auto layout breaks in a narrower frame.

None of that is the tool failing. Each problem is a decision nobody made: what things are called, which states exist, what binds to what. So the decisions come first, and they live in files the agents read before they draw anything.

Everything starts from two inputs.

The brand guidelines give me primitives: the brand colors, the typefaces, sometimes a type scale. They don't give me semantic tokens. No brand book says which blue is the primary action or what an error surface looks like. That layer is a product decision, and I make it, along with the full color scales and the feedback colors that a brand palette rarely covers.

The component inventory says what has to exist. I built it in a spreadsheet from three front-end references: MUI, Angular Material and Material Design 3. A master sheet maps 72 canonical components across the three and marks the gaps. Angular Material has no Rating; M3 builds Autocomplete from Search and Menus. Each library also gets its own sheet, because each composes components differently. MUI keeps the label and error inside TextField, Angular Material wraps inputs in a Form Field, and M3 defines the text field's anatomy itself.

In those sheets one row is one component × variant × state: 942 rows for MUI, 572 for Angular Material, 587 for M3. States use M3's vocabulary (enabled, hovered, focused, pressed, dragged, disabled) plus error, readonly, selected and the rest where they apply. The library the product is built on decides which sheet is used.

Neither input goes to Figma directly. An LLM turns them into markdown specs, and I edit what it writes. The structure is the one I use in Figma to Code: design-system.md at the top, then foundations/ (color, typography, spacing, motion, accessibility), components/, patterns/ and templates/. A DESIGN.md sits beside them in Google Labs' open format, with tokens in YAML front matter and the reasoning in prose underneath.

The same files are read by me, by developers and by every agent. One rule sits at the top of the set: never infer a value. If a spec doesn't state it, the value doesn't exist yet, and an agent has to say so instead of picking one.

The inventory decides what the specs must cover. A generated report lists which of the 72 canonical components are documented and which aren't. Each component spec is also scored on nine axes taken from the spreadsheet's columns, such as anatomy, props, states, guidelines and accessibility. A missing axis is a missing section.

Before an agent draws anything in Figma, I check whether the specs are enough on their own. A fresh agent gets only the md files: no Figma, no code, no way to ask me. It builds a few components. Every value it takes from a spec carries a SPEC: file:line comment. Every value it had to choose itself is marked INVENTED.

The INVENTED list is the to-do list. Each entry is a decision the specs are missing, and the fix goes into the md, not into the component. Then the run starts again on the edited specs. This is the loop that makes the specs work. I read the result, edit the md, and run it again.

The count doesn't simply fall. In an early run one component couldn't be built at all. Once the specs were fixed it could, and building it surfaced decisions the agent had never reached before. So I don't watch the total. I watch whether a gap comes back. A gap fixed once should never be INVENTED again.

Drawing and checking are separate agents.

The drawing agent reads the specs and writes into Figma with use_figma. Figma's figma-generate-library skill gives the build its shape: discovery, foundations, file structure, components, then integration and QA, with a stop for my review after each phase. It records every ID it creates in a state file and checks by name before creating anything, so a second pass edits the first instead of inventing new names. Fills, padding, radius and gap bind to variables, and variants are named Property=Value (State=Hovered). The skill expects a codebase as its source of truth. Here the md specs take that place.

The review agent never draws. It reads the result against the rulebook and the specs, and sends each failure back to where it came from, the same way QA routes failures in Figma to Code. A gap in a spec goes back to the md. A mistake no rule covers becomes a new rule. A drawing error goes back to the drawing agent.

The limits are practical. Output is capped at 20 KB per call, so a library takes dozens of calls. There are no images and no custom fonts.

The specs say what to build. The rulebook says what not to get wrong. It lives in .claude/rules/ and is split the same way the specs are.

foundations/ covers spacing, color, type and radius: no hardcoded values, spacing only from the scale, matching gaps between siblings. ui-patterns/ covers single patterns such as buttons, search, inputs and selection. ux-patterns/ covers flows: submitting a form, recovering from an error, an empty state. figma/ covers how things are built: every fill and gap bound to a variable, variant names as Property=Value, auto layout instead of fixed positions.

A rule starts as a mistake. When an inconsistent gap or a missing focus state shows up twice, it stops being a review comment and becomes a rule. From then on the review agent catches it before I see it. Figma points the same way: its create_design_system_rules tool exists to write a team's unwritten conventions into a rules file that agents read.

Iteration isn't a better prompt. It's the specs and the rulebook getting a little more complete on every pass. The agents do the drawing and the checking. The decisions in those files are still mine.