Years of building what matters now

How We Ship Figma to Production React with Claude Code

The Figma-to-code handoff usually ships a slightly worse product than the one you drew. Here are the ten Claude Code skills we built to close that gap.

Table of Contents

Heading2

For years the handoff was the moment our work got fuzzy. You send a Figma file to a dev team, and from that moment you have less control over how the product actually looks and behaves when it reaches users. Some decisions survive the sprint, many don’t. Spacing drifts, a hex value slips in, a variant quietly goes missing, and the product that ships is a slightly worse version of the one we drew.

Every agency and every in-house team we know lives with this tax. About a month ago we stopped paying it, and this post is about what we did with the time it gave back.

What we built

At Properly we put together a set of Claude Code skills that take a Figma design system and turn it into a production React and Tailwind repository, documented and ready for the next developer, or the next AI agent, to extend without hand-holding.

Ten skills, grouped into three phases: Prepare, Build, Ship - all available on our on GitHub.

Prepare

ds-session-start-tw reads the project state so the agent knows what's shipped, what's in flight, and which conventions to follow before it writes a line.
ds-setup-tw installs the foundation in one pass: tokens, Tailwind config, light and dark modes, semantic variables, and the CLAUDE.md every future agent reads first.

Build

ds-figma-to-react-tw turns Figma components into production React with typed props, accessibility attributes, and token-bound Tailwind classes.
ds-figma-patterns-tw extracts multi-component views like forms, empty states, and dashboards as specs that compose your components the way your designers intended.
ds-figma-templates-tw captures full page layouts with grid, spacing, and responsive behaviour, so your product ships with a structural blueprint instead of a screenshot gallery.
ds-qa-tw audits every component before it lands, flagging hardcoded values, accessibility gaps, and naming drift before code review has to.
ds-preview-tw renders any component across every variant and state, so designers verify pixel fidelity against Figma in seconds.

Ship

ds-showcase-tw builds a standalone HTML showcase of the full system, no build step, so your client can open it on a phone mid-meeting and see what's shipped.
ds-status-changelog-tw keeps STATUS and CHANGELOG files current as components land, so you always know what's ready and what changed this week.
ds-handoff-tw produces the final developer package: README, CONTRIBUTING, CLAUDE.md, and a W3C-standard token export any other tool can read.‍
ds-showcase-tw builds a standalone HTML showcase of the full system, no build step, so your client can open it on a phone mid-meeting and see what's shipped.‍
ds-status-changelog-tw keeps STATUS and CHANGELOG files current as components land, so you always know what's ready and what changed this week.‍
ds-handoff-tw produces the final developer package: README, CONTRIBUTING, CLAUDE.md, and a W3C-standard token export any other tool can read.

What the founder actually gets

Designers keep ownership of quality past the handoff, because the components in the repository reference the tokens and variants from Figma. Developers receive code they would merge on their own team, with typed props and accessibility already in place. Both of those matter. The person who gains the most is the founder.

Before, every feature was paid for twice. The first invoice covered the design. The second covered the slow translation of that design into code. Most of the file survived, rarely all of it, and the rest arrived as visual inconsistencies, bugs, and rebuild work that quietly ate the next sprint. Every product team knows this tax, even when nobody names it.

With this workflow the founder pays once, and gets a system that compounds. The design system becomes the source of truth for the brand, the codebase, and every feature built on top of it. When a new developer joins, the repository teaches them the rules. When you decide to rebrand six months in, the change lives in one file and propagates everywhere.

And because the baseline is higher and faster, we finally have budget for the work that usually gets cut first. The onboarding sequence gets motion, the empty state gets a moment of personality, the transitions between screens start to carry weight. These are the details that separate a product people tolerate from a product people recommend, and they used to be reserved for flagship projects. Now they are the default on every engagement.

About all those AI agents

You have seen them already. Claude Design, v0, Bolt, Lovable, and every month a new agent that promises to take your idea and ship a production interface. Most of them are good within their lane. They work well for a landing page, a quick MVP, a demo nobody has to maintain. They start to drift the moment you want the output to live inside your brand and follow your design system.

The reason is almost always the same. Your brand is legible to humans, not to machines. Your design decisions live in a Figma file, in a Notion doc, and in a conversation your team had three months ago. An AI agent sees none of that context, so it has to guess what “our primary button” means, what “the warmer grey we agreed on” translates to in hex, and which spacing scale you actually use. When it guesses, it drifts, and you get a product that almost looks right, which is worse than one that is obviously off.

Our workflow is the missing link, because the design systems we ship are AI-native by construction. The CLAUDE.md file explains the rules in a format any agent can read. Semantic tokens name intent instead of raw values. The repository documents every decision the next agent needs to make a correct call. General-purpose agents cannot reach this level of fidelity on their own, because they start from a blank repo. We start from a system that teaches them what to do, so the output stays in your brand even when the person writing the prompt is not a designer.

Eterna, in an afternoon

The first real test was Eterna, a fintech product we are building at Properly. The Figma file had matured, with variables in place, components carrying their variants, and the visual language locked with the client. Under the old workflow, getting that file into a working React repository would have been a multi-week project for a small dev team. With the skills we translated the entire design system into a production React repository in a few hours, on a single afternoon.

By the end of that first week we were delivering clickable prototypes of real flows to the client, running on the actual components the developers would eventually build against. Conversations shifted from “does this look right” to “does this feel right,” because the thing we were showing already looked right. More ideas got tested, more edge cases got caught early, and the gap between exploring an option and ruling it out compressed from days to an afternoon.

Nobody has ten thousand hours yet

Vibe coding, as Andrej Karpathy named it, has existed for about a year. Ten thousand hours in a single year works out to twenty-two hours a day. Nobody on the planet is an expert at this yet. We are all writing the playbook live.

What we offer is backed by a small team running this workflow on real client projects, breaking it, fixing it, and watching the output pass a bar we never used to hit. Founders and product leaders live in this kind of uncertainty, which is another way of saying they live where the opportunities actually are.