GitLaw: Figma to code

Context

Two problems sat underneath the handoff, and they compounded.

Two libraries, no shared surface

Figma and the repo were separate systems, each holding its own copy of the design system, and over time the copies drifted. Thirteen semantic colours existed only in Figma. Nothing existed that both sides could open and look at together, so a built surface was compared to a Figma frame by eye, in review, after it had been built. When it did not match it was often rebuilt rather than corrected, and the work went back to design iteration. Rounds ran to ten and beyond.

Agents without context

Figma MCP and the out-of-the-box skills had already been released, so pointing an agent at the file was the obvious first move. Without context it hallucinated in both directions: shapes, hex values and hand-rolled positioning going into Figma, raw hex and Figma layer names coming back into code with tokens and variables missing. Iterating made it worse rather than better, because each round started from the previous round’s mistakes.

The approach

Make Storybook the canonical design system and keep it in the product repo, then write the skills that carry an agent between it and Figma in either direction. Figma mirrors Storybook rather than competing with it, and the agent reads the repo’s own conventions instead of guessing at them.

The diagram at the top of this page is the shape it took. The names clustered around the middle step are the point of it: the consequence that mattered most to the team was not speed, it was that anyone with access to the repository could put a UI change into the product. Product, marketing and the CEO, not only the two disciplines that already had the tools.

01Proof of concept

Rebuilding the system in a sandbox

To find out whether the idea held at all, I built a standalone sandbox outside the product. Agents rebuilt the entire design system in Storybook: each Figma component became a story, and each story was checked against a Figma screenshot before it was accepted. I then tested the result by prototyping full pages in Claude Code.

02Into the product

Storybook in the front-end repo

Once the sandbox proved the approach, the same method ran inside the product, with a lane the design side could work in: primitives, blocks, foundations and styles.

What made it repeatable was a playbook the agent reads at the start of every session. It lists what exists and what already has a story, so a session starts from the real state of the repo rather than from a guess. On day one, 18 of 54 primitives were covered, and the first commit added 17 stories.

03Engineering takes it over

Bricks

Engineers picked the Storybook work up and formalised it as bricks: small components with a clear contract, each with a story. They wrote the loop down themselves, in their own documentation. Edit the brick, write the story, screenshot it, compare the screenshot to the design, and go back to the start if it does not match. Every pull request now posts a Storybook URL as a comment.

The loop works because a brick has no server dependencies. It renders in Storybook with props and an IntlProvider, which is what makes the screenshot cheap enough to take on every round.

This is the point at which it stopped being a design initiative.

04Outcomes

Code from Figma

With the skills in the repo, an agent matches repo components against a Figma file someone shares with it, and the design can then be iterated in code until it matches what was asked for. The components it reaches for are the stories in Storybook, and those are the same components that go to production.

Figma from a prompt

The same pipeline runs the other way. Ask for a screen in plain words and the agent builds it in Figma from the library: components by key, colours as variables, auto-layout throughout, checked against a template, three variants in one pass. A single command classifies the request, creates the file, updates the ticket and repairs its own rules when a run goes wrong. That last part is why the playbook behind it grew from one file to twelve over three weeks.

05Validation

Checking it against other practitioners

I posted an outline of the process publicly to see whether it held up outside our own repo: Storybook in the repo, align the Figma library, shells as templates. The replies confirmed that other designers were automating the same loop, and one of them named the gap I would take on next. How do people who never touch a coding agent still take part?

06Improvements

A repo for people who do not write code

Adoption stopped at designers and developers, which is the gap the thread had pointed at. To let product and the CEO explore and validate fresh ideas, I set up a sibling repo for early-stage prototyping.

It works because of three deliberate differences from the product repo.

1. It does not hold strictly to front-law components, so exploration has more room, but it keeps the tokens and the same design language.
2. It carries full product context, so what gets explored is informed by what the product can do and what the stack allows.
3. It keeps project status in the repo, so a prototype can be evolved across sessions rather than depending on what one session remembers.

What worked, and what did not

Worked

• A consistent process for generating code from Figma, and for iterating on Figma from code.
• A much faster cycle from design to implementation.
• A prototyping playground that kept the whole team in sync on new ideas.

Did not

• Figma generation stayed relatively slow, and it was never fully reliable.
• The prototyping repo was disconnected from Storybook, which left it valuable mainly as an ideation tool.
• The Figma library still had to be aligned with Storybook by hand.