---
title: "I Removed Figma From My Code. Now I Removed It From My Design System Too"
description: "A custom Claude Code skill that builds Storybook as the source of truth for AI prototypes — so the design system no longer lives in Figma, and UX flows and edge cases no longer live apart from it."
slug: i-removed-figma-from-my-design-system-too
publishDate: 2026-07-09
author: Igor Dobzhanskiy
tags: [AI, Claude Code, Storybook, Design Systems]
---

I've already talked about removing Figma from my workflow — the whole product now gets built directly in AI prototypes: Claude Code, Cursor, and Codex draw the real flows, use cases, and edge cases, and the entire UX lives inside the prototype instead of a separate showcase file. But one gap remained: if the design system still lived in Figma, I was just moving the old problem to a new place. The prototype became the source of truth for UX, but components and tokens were the source of truth for nothing — the AI just reinvented them every time.

So the next logical step was to remove Figma from there too. I built a skill that builds the design system directly in Storybook, and forces whatever AI is building the prototype to use only those components. The source of truth is no longer a Figma library — it's Storybook plus the prototype itself.

## Why "AI builds the prototype" alone is only half a solution

When AI builds a prototype from scratch every time, it doesn't remember which color it picked for the primary button yesterday. Every new screen is a new set of hardcoded values, a new button that looks slightly different from the last one. Without a separate source of truth for components, consistency depends entirely on how carefully I re-check every intermediate output.

Storybook, in this role, isn't "documentation for developers" the way it's traditionally positioned. It's the layer the AI prototype pulls components from, instead of drawing them again from scratch. Tokens, states, edge cases — all defined once, and the prototype is required to reference them.

## Before generating anything, the skill asks questions

When you activate the skill on a new project, it doesn't start writing code right away. First comes a short interview, one group of questions at a time: is this project starting from scratch, does code and a Figma file already exist, what's the stack and UI library, do tokens exist anywhere, and what does this specific project actually need Storybook for.

Based on the answers, the skill picks one of four paths: building from scratch (component inventory first, then foundations), auditing existing code with no Storybook yet, porting whatever's left in Figma into code via Figma MCP — as a one-time migration, not an ongoing dependency, or cleaning up a Storybook that already exists but is a mess.

## A token without a value isn't a token — it's a promise

This is the section the skill itself calls the one that "makes or breaks the whole skill." The rule is simple: every token used anywhere — in CSS, in a story, in documentation — must have a real value and a real source. No abstract names floating in the air, because that's exactly what hardcoded values look like before you find them too late.

The source lookup order is always the same: if Figma MCP is still connected, pull the real values from there, one last time. If tokens already exist in the code, use them instead of inventing new ones. If no tokens exist anywhere and I want the AI to decide, that's a valid path — but every decision gets stated out loud, not buried silently in the code. And if it's unclear whose call it is, the skill stops and asks instead of guessing.

After every component it creates or edits, the skill automatically outputs a Token Usage Report:

```
## Token Usage Report — Button

| Property                    | Token                       | Value    | Source                          |
|------------------------------|------------------------------|----------|----------------------------------|
| background-color (primary)   | --action-primary-default     | #2563EB  | Figma: action/primary/default   |
| background-color (hover)     | --action-primary-hover       | #1D4ED8  | Figma: action/primary/hover      |
| text color                   | --text-inverse               | #FFFFFF  | Existing tokens.json             |
| padding (horizontal)         | --spacing-4                  | 16px     | AI-defined (no prior token existed) |
| border-radius                 | --radius-md                  | 8px      | AI-defined (no prior token existed) |
```

That same table goes straight into the component's MDX documentation. It's not a "just in case" chat answer — it's part of the deliverable the prototype references every time the AI adds a new screen.

## A story without an empty state is half a story

Every component in Storybook, under this skill, must have: a Default state, every visual variant, every interactive state (hover, focus, disabled, loading, error), an empty state, and edge cases — long text, RTL, mobile viewport. These are exactly the states the prototype needs to show as part of a real flow, not something to "design later."

When you ask the AI to "add a component" or "add a screen," the skill checks on its own: does it need an empty state (for lists, tables, dashboards, search results — always yes), does it have a loading state, does it have an error state. If you haven't thought about it, the skill raises it instead of silently skipping it. That's the mechanism that used to depend entirely on how carefully a designer read a Figma file.

## Figma still exists, just not as the source of truth

If Figma still has components left over from old projects that need porting, Figma MCP or Figma Console MCP works alongside Style Dictionary — once, as a migration. But the "code → Figma" direction (Storybook Connect, story.to.design) isn't something I actively use anymore — syncing the design system back into a file that no longer defines anything doesn't serve a purpose. There's one source of truth, and it's Storybook plus the prototype.

## What actually changes

The AI building the prototype no longer reinvents a button on every screen — it pulls it from Storybook, with documented states and real token values. The entire UX, every flow and edge case, lives in one prototype, and all visual consistency lives in one design system right next to it. Figma no longer takes part in that chain.

The skill is open — grab it and adapt it to your own stack.

**Download:** [dobzha-storybook-ds.skill](/downloads/dobzha-storybook-ds.skill)

You can also find it on [GitHub](https://github.com/dobzha/dobzha-storybook-ds-skill) or watch the walkthrough on [YouTube](https://youtu.be/7zV7lqBH0Fc).

If you want more on design, AI, and engineering practices — subscribe to my [Telegram channel](https://t.me/dobzha_pro_design).
