The Figma token importer I needed didn't exist. So I built it.

I was three weeks into architecting a design system for a product I was building. The foundation was done. Color scales, typography, spacing tokens, all documented and structured. The tokens.json file was a thing of beauty: nested collections, semantic naming, proper type definitions. The next step should have been trivial. Import these tokens into Figma as variables. It wasn't.

The Figma Community usually offers an embarrassment of riches. Need a wireframe kit? Hundreds. An accessibility checker? Take your pick. So when I searched for a token importer, I expected the usual. What I found was a graveyard of half-solutions.

The paid plugins wanted 15 to 30 dollars a month, with no trial to verify they actually handled my token structure. The free ones were worse. Colors imported as strings instead of COLOR types. Numeric spacing lost its precision. My carefully nested hierarchy flattened into an alphabetical mess that would take hours to reorganize by hand.

One plugin stood out. The type detection was spot on, the collection mapping was intelligent. It did exactly what it promised, but only for CSS custom properties. JSON and CSV, the formats every major design token specification actually uses, were left in the cold.

There is a specific frustration only designers who code will recognize. The moment you realize you could probably build the solution faster than you can find it. Usually that thought passes. You remember you have real design work to do. This time I had Claude.

Colors become COLOR. Numbers become FLOAT. Booleans become BOOLEAN. The token hierarchy maps straight into collections, not an alphabetical dump. Automatic type detection does the work that the broken plugins offloaded onto the user.

A visual preview before import shows every token with a type indicator and a color swatch, so nothing imports blind. Existing variables update instead of duplicating. The whole flow is four steps and takes under a minute.

It does one thing, and it does it without asking for an account, a subscription, or your data. The kind of tool I went looking for and could not find.

I didn't start by asking AI to generate code. I started by writing what engineers would call a specification, but what I thought of as a really detailed brief. The README read like a conversation with a senior developer. Here is what the plugin needs to do. Here is the architecture: separate plugin and UI layers, message passing between them. Here is how people will interact with it. Here are the edge cases to handle. That document became the north star, and every prompt referenced it.

With the brief as context, Claude built the foundation. Twenty six files, properly connected: TypeScript config, build scripts, the manifest, the plugin layer, the UI layer, even sample token files for testing. Not perfect, but a functioning skeleton I could iterate on.

Then I did the part I actually know how to do. The generated UI was functional but soulless, that particular flavor of technically correct and experientially wrong. So I designed it properly. An 8-point grid, a palette matching Figma's dark theme, type scales native to the platform, every screen and every state. Upload, preview, configuration, success. I designed it in Figma, exported the screens, and fed them back as the reference to match exactly.

Testing with real tokens exposed the gaps. A hex value parsing as a string. Numbers with units not detected. Boolean strings not converting. Each one became a focused conversation: the hex regex missing three-character values, RGB values with spaces needing to normalize to Figma's RGBA format. Fixed precisely, not patched broadly. It wasn't prompt engineering. It was pair programming with a partner who never got frustrated when I changed the requirements.

AI is a collaborator, not a contractor. Claude accelerated the implementation, but every decision about what to build, how it should feel, and why it mattered came from experience. The frustration was mine. The standards were mine. So was the satisfaction of seeing it work.

The best tools come from personal pain.I didn't build this because I thought it would be popular or profitable. I built it because I needed it to exist. That is the purest reason to make anything.

The gap between “I wish this existed” and “I built it” has never been smaller. You don't need to become a developer. You need to understand your problem deeply enough to describe it clearly, and care enough to iterate until it is solved.

The code is on GitHub. Open source, forkable, adaptable. Because somewhere another designer is spending their afternoon testing plugins that almost work, getting frustrated by problems that shouldn't exist. They shouldn't have to.