The workflow I wrote about in the first post — Figma to code — assumes design comes first. But what about when the designs don’t exist yet, or need to be built out as part of a system?
There’s a newer side to this that’s worth covering: using AI to build directly inside Figma. Not generating code and translating it back. Writing to the Figma file in real time.
The shift: from reading to writing
The Figma MCP server started as a read-only tool. Claude Code could inspect a design file, extract variants and token values, and use that as context for writing code. Useful, but one-directional.
A more recent capability changes that. Through a tool called use_figma, Claude Code can now make changes directly in Figma — creating frames, building component sets, binding variables, generating variant matrices — all without leaving the terminal. You can watch the components appear on the canvas in real time.
The two directions complement each other. Reading Figma is still the right approach when you’re implementing an existing, finalised design. Writing to Figma is useful earlier in the process — building out the design system components themselves.
In Practice
Building a Pill component
The first test was a Pill component. Given a description of the variants and sizes we wanted, Claude Code created the component set in Figma, connected it to our variable collections, and set up the full variant matrix — primary, secondary, error, warning, success, and information.
What makes this more than just drawing shapes is the variable binding. Every colour, spacing value, and corner radius is connected to a named variable from our token library. The same variables used in the code. Because the variable names follow a consistent convention, Claude Code can infer the right variable for each role without being told explicitly — the naming does the work.
The result was close to 90% correct on the first pass. Colours right, spacing right, radius right. The kind of small tweaks a designer would make — tightening spacing between specific elements, adjusting a particular state — still needed a human eye. But the structural work, the repetitive work, was done.
In Practice
Building without a finished design
The more interesting test was building components that didn’t have a finished Figma design to reference.
For Checkbox and Radio, the prompt provided the existing Button and Pill as reference components, along with the Radix component library as context on the code side. Claude Code used those references to infer what good components should look like in this file, then built both from scratch.
It created dedicated pages for each, laid out component sets with the full state matrix, and connected everything to the shared variable collections. An overview page was generated alongside, showing all variants in a single view — useful for design review and for the handoff to implementation.
The components weren’t pixel-perfect. Some spacing needed adjustment, and the font handling required a fix. But as a starting point connected to the right variables and following the file’s existing patterns — it was 90% there, with only tweaks remaining.
The skills behind this
A set of Claude Code Skills encode the rules for how this works in our codebase.
cc-figma-tokens builds the Figma variable collections from our token source files. It creates two collections — Primitives (raw values, hidden from component panels) and Semantic (aliases that components bind to) — and sets up the correct scopes and code syntax for each variable. This runs first; everything else depends on it.
cc-figma-component generates a complete Figma component set from a component contract. It reads the contract’s token bindings, derives component-scoped tokens, builds the full variant matrix across size and state axes, and binds every visual property to the appropriate Semantic variable. No hardcoded values.
audit-design-system reviews an existing Figma screen or component for drift — places where the design should use shared components or tokens but doesn’t. It flags non-systemised primitives, hardcoded values, and repeated structures that should be components.
apply-design-system takes those findings and fixes them, swapping local frames for library instances and reconnecting token bindings across a screen.
Together, these Skills mean the agent isn’t working from general knowledge. It has precise, project-specific rules for how the design system is structured — and it applies them consistently.
What this means for the design side
Building a design system component normally involves a lot of repetitive Figma work. Creating base components, duplicating them across a state matrix, setting up variant properties, binding every value to a variable. It’s mechanical, but it takes time and it’s easy to introduce inconsistencies.
This approach removes most of that mechanical work. A designer or engineer describes what they want — the variants, the sizes, the token connections — and the agent builds it. The designer’s job shifts toward reviewing and refining rather than constructing.
That’s meaningful for pace. It’s also meaningful for consistency. Every component built through this process uses the same variable structure, follows the same naming conventions, and produces the same kind of overview documentation.
Where this could go
The immediate next step is making the overview pages more useful. Right now they show variants in a basic grid. What we want is a full spec page — scaled properly, annotated, showing states in a way that gives developers everything they need to implement without further questions. That’s achievable with a more detailed prompt and a Skill to enforce the format.
Longer term, this connects to the same vision as the code workflow: a designer marks a component ready, the pipeline builds it both in Figma and in code, both outputs are reviewed, and everything lands in Storybook and the Figma library simultaneously. The two directions — code to Figma and Figma to code — converge into a single process.
The bottleneck in building a design system has always been the sheer volume of components to get through. This makes that volume manageable.
Beach Towel is a multi-brand React component library built at OTB Group.