I was listening tothe Dive Club podcastwith Flora Guo as a guest. There were a lot of memorable moments, but the one that really stuck was her idea that designers should treat the internet the way a good host treats a room. Ask what you can give rather than what you can get: notes, artifacts, events you put on. She makes things for her friends as gifts. That sat with me for a few weeks without anywhere to go.

Then I spent a Monday at the Fashion Nova office in Beverly Hills. A design workshop, lunch, then four back-to-back conversations. Six people over four hours. I could have sent the recruiter one email with six individual thank-you notes in it. I thought of Flora instead and wanted to make this a gift too. The day was memorable and I wanted to give that back as something memorable.

I built out a game, a representation of the office with the different hubs and the cross functions that I got to meet, interact and learn from during my interview process. It's an isometric floor you walk around in the browser. The recruiter meets you at the entrance, welcomes you in and tells you how to move, and then you walk the building and leave a note with each of the six people who interviewed me, each of them standing about where I met them. A table by the door keeps every note you've handed over so you can read them again.

I designed it, and my new best friend Claude built it, haha.

Resources

fashion-nova-hq.vercel.app— walk around the office. Arrow keys or WASD, space to talk, T to change the palette.

Every round of design feedback went through me as a copy-paste layer. Open Figma, read the comment thread, retype it into Claude in my own words, wait for the change, go check it against the original comment. For a file with a dozen open threads, that's a dozen trips back and forth before any of it reaches the agent.

The comments already exist, in full, in Figma. There was no reason Claude couldn't read them itself. So I builtfigma-comments-mcp, an MCP server that hands Claude a frame link and gets back the actual feedback pinned to it.

Two tools, both read-only

list_figma_comments reads the comment threads and Dev Mode annotations on a file, or on one frame within it. Each one resolves to the layer it's pinned to, so a comment reaches Claude as"on 01 · Results — default" instead of a bare node id:

rNK3UkoeLnbBHHYQiv9MW8 · frame 132:5 "01 · Results — default" · 1 thread · 1 annotation 1873426532 · Eun Ji Jung · 2026-08-05 19:22 on 132:5 "01 · Results — default" FRAME have hover states annotation on 132:258 "Overview" FRAME allow for collapsing panels

get_figma_comment_image renders the layer a comment is pinned to, for when the feedback is spatial ("too much space here") or pinned to a pasted screenshot named something useless like image 21.

Neither tool writes anything back. It reads Figma; it never edits a design or posts a reply.

Why there's no reply tool

An earlier version had a reply_to_figma_comment tool. I pulled it. A reply in a comment thread is a statement to a collaborator, not a status update, and I didn't want an agent posting into that conversation on my behalf, worded however it decided to word it. Reading feedback and acting on it is one thing. Speaking to the people who left it is mine to do.

A frame link isn't a file link

I share a link to one frame and expect comments on that frame, not the fifty other threads scattered across the rest of the file. Any Figma URL copied with a frame selected carries a node-id, and the tool scopes to it, descendants included, everything outside excluded, and it always reports how many threads it left out. Before this distinction existed, a frame link and a file link looked identical and every call just returned the whole file.

Annotations get the same care for a different reason. Dev Mode annotations are a separate Figma feature, invisible to the comments API, and easy to leave behind without noticing. A frame holding one comment and one annotation used to report "1 thread," which looked complete and wasn't. Both counts are on the headline now.

Try it

Clone the repo, npm install, npm run build, then point Claude Code or Claude Desktop atdist/index.js with a Figma personal access token scoped to read-only file content and comments. Full setup steps, the token scopes, and a troubleshooting table are in the repo README.

Once it's wired in, paste a frame link and ask Claude to read the comments and apply them, or ask what's still open across the whole file. No more retyping.

Resources

github.com/ejun-9/figma-comments-mcp— the server, setup instructions, and troubleshooting.

Some time ago I wrote aboutfixing a design system so Claude could actually follow it. That fix lived inside one project, a/DSYS folder in Lune's repo, built by hand for that codebase's stack and that codebase's tokens. It worked there. It also meant that the next time I wanted the same fix on a different project, I'd be rebuilding it from scratch.

So I rebuilt it once more, on purpose this time, as something reusable: a Claude Skill calledds-specs. It's on GitHub now, free to install, for any designer or team running into the same drift problem.

What a skill gets you that a folder doesn't

The Lune version was specific to one project's conventions. Turning it into a skill meant it had to work on a codebase it had never seen: detect whether the project uses Tailwind or plain CSS, scale the spec tree to how big the project actually is, and refuse to invent specs for components that don't exist yet. A small accurate spec beats a comprehensive stale one.

It also meant going further than the original fix did. Three thingsds-specs adds on top of what I described last time:

Three tiers, three layers of indirection

Every spec references only the tier above it, so a component spec can never point straight at a raw hex value:

specs/ ├── foundations/ color, typography, spacing, radius, elevation, motion… ├── tokens/ the master variable map ├── atoms/ ─┐ ├── molecules/ ├─ components, 8-section template each ├── organisms/ ─┘ └── patterns/ layout and composition rules

And every token itself passes through three layers before it reaches a component, so nothing in the UI touches the upstream library directly:

--ds-text: #292A2E; /* upstream library */ --color-text: var(--ds-text, #292A2E); /* your alias */ color: var(--color-text); /* components — alias only */

Five gates instead of one

The Lune pre-commit hook was a single checkpoint. ds-specsruns the same idea at five points, from session start through deploy, and draws a hard line on what's allowed to self-heal. Local autofix can rewrite an exact hex match with a human reading the diff. CI and deploy only block, they never rewrite. A near miss like#1868DA against a #1868DB token is either a typo or a deliberate one-off, and no script can tell which, so it gets flagged at higher severity and left for a person to decide.

On an existing codebase with hundreds of pre-existing violations, the gates start from a recorded baseline and only fail when the count goes up. Hard-failing against 400 existing violations just gets the gate deleted by Thursday.

A two-way bridge to Figma

The part I was most unsure I could get right. Figma variables carry acodeSyntax field. Set it to the matching CSS custom property and the Figma variable and the code token become one record seen from two sides, so syncing is exact instead of fuzzy name matching between "Text/Primary" and--color-text.

Neither side is treated as canonical. When you ask it to reconcile, it produces a six-category diff and stops. A mismatch is ambiguous. Only a person knows whether the designer moved the value or the developer did.

Try it

It installs two ways. On claude.ai, download the .skill file from the latest release and upload it under Settings → Capabilities → Skills. In Claude Code or Cowork, clone the repo and copy the skill folder into~/.claude/skills/. Full steps, including how to verify it installed correctly, are in the repo README.

Once it's in, you don't need to invoke it by name every time. Say "tokenize this" or "my prototype is drifting" and it builds the spec tree. Say "push my specs to Figma" and it hands off to Figma's own library-generation skill. Say "does Figma match my code" and it reconciles without changing anything.

Resources

github.com/ejun-9/ds-specs— the skill, install instructions, and the packaged.skill file for claude.ai.

Expose your design system to LLMsby Hardik Pandya. The article the whole approach is built on.

We are moving into an age where using AI is just expected in a design workflow. Not optional, not a nice-to-have on a resume. Expected. That expectation is what put me into a phase of obsessively testing every AI tool that came out, and it left me with two feelings at once that I don't think get said out loud enough.

There was excitement. Genuine excitement, about how much new technology was suddenly out there and how early I got to touch it. And there was a slight fear, too, that if I didn't learn the new tool fast enough, I would fall behind. Both were real. Neither one cancels the other out.

But the testing wasn't random. I was looking for something specific: an AI-native replacement for Figma.

The search

Figma is the tool I use the most. It is where I have lived for years. So the question I kept bringing to every new launch was not "is this a fun tool," it was "could this be the place I live instead."

Most of what I tried didn't survive an evening. I am not going to name those. They weren't great, and the interesting thing about them isn't which ones they were. It's how fast the filter worked. A tool either showed me something real in the first hour or it didn't, and if it didn't, I didn't go back.

Twelve did survive. I loved all twelve, for different reasons, not the same reason repeated twelve times. That matters, because it means there was no winner. Nothing on the list replaced Figma. What I ended up with instead was a stack.

The one with the best shot let me down the most

Figma Make is the one I was rooting for hardest, and its updates were the ones I kept hoping would land. Every other tool on my list started from zero. Stitch, Claude Design, all of them. They don't know my components, my variables, my files. When they fail to respect a design system, that's expected. They never had one to begin with.

Figma Make already had it. Same file. Same libraries. Same components I'd built over years. It had the one advantage nothing else on my list could claim, and it's still the one that disappointed me most.

It isn't just a feeling, either.Figma's own community forumconfirms the exact failure I kept hitting: components from design system libraries don't reliably export from Figma Make. They can paste back in as plain Figma elements instead of the real thing. The tool with the best possible starting position still couldn't carry my system through cleanly. For their own product to be that disappointment was sad to say the least.

What earned a place, and why

Cursor stuck because of two things together: point-and-click editing, and a noticeably better Figma integration than anything else I tried. It did a better job than the others at translating a vibe-coded prototype back into Figma.

That detail matters more than it looks like at first. I went looking for something to replace Figma. The tool that earned a permanent slot did so by being best at going back to it. Figma never stopped being the destination. It's still the system of record: the place work has to land, get reviewed, get handed off, and live.

So the honest version of my search isn't "nothing was good enough to replace Figma." It's that I built a stack that orbits the thing I was trying to leave. The tools that survived are the ones that talk to Figma well, not the ones that could stand in for it.

Claude Code desktop does the opposite direction well: Figma into code. With the capture link, my designs get translated exactly. It gives me point-and-click modification, multiple terminals, file management in a side panel, and context that actually persists. It's the center of the stack now.

Two different directions, both from tools I kept: my prototype becoming a design file, and my design file becoming a working prototype. I want to keep those separate in my head, because it's easy to blur them into one vague "Figma integration," and they're not the same job.

The tool built for exactly what I wanted

Paper (paper.design) is the one that made me feel like I wasn't crazy for looking. Its canvas is real HTML and CSS, not a proprietary format, and it's built MCP-native from the ground up: an agent can read the canvas and write directly to it, not just generate something new. Some reviewers frame it outright as a Figma challenger.

It's also still in open alpha. Figma is still where the industry actually is. EvenPaper's own comparisonsconcede it: Figma is more mature, has the ecosystem, and is still the default for most teams.

What I keep coming back to is the parallel. Paper rebuilt the canvas from scratch so an agent could act on it directly. I did something smaller with the same instinct. Neither of us thought the answer was a chat window. We both thought the answer was making the surface itself something an agent could touch.

The one I kept, then killed, then understood why

Conductor solved a real problem for me. I was living in the terminal, running Claude Code, and at some point I had what felt like a million terminal windows open. Conductor organized that.

Two things ended it. The model access I had through my subscription only covered Sonnet 4.6 for free. Every Opus tier I could pick was the paid, outside-subscription version, and Opus was the one I actually wanted for harder reasoning.

The second reason is the one I actually think matters more. I was living in the terminal because I assumed the desktop app had worse capabilities. It doesn't. It does the same thing, but with a UI: I can see everything, make point-and-click modifications, and switch between projects from a side nav.

Once I saw that, Conductor's whole reason for existing evaporated. It wasn't a bad tool. It solved a problem I had manufactured for myself by believing something that wasn't true. Claude Code desktop didn't beat Conductor. It made the problem Conductor was solving disappear.

The pattern I didn't notice until I looked back

Point-and-click kept coming up. Cursor, for the editing. Claude Code desktop, for the modification and a side nav where I can see everything. Figma, the one tool that was never displaced, is a canvas before it's anything else.

Every tool that survived lets me point at the thing instead of describing it. I'm a designer. Direct manipulation is the way I actually think, and I'd been selecting for it the whole time without naming it.

The Claude Code move is the cleanest proof of this, because it isolates the variable. Same product, same model, same capabilities. It does the same thing. The only thing that changed was the interface. And that one change was enough to end an entire tool I'd built into my workflow. The tool didn't get better. The interface did.

What none of the twelve have

This is where the search actually failed, and it wasn't about features.

None of the twelve are multiplayer. There's no one else in the file with me, no comment thread, and no history to point to when someone asks why a button ended up the way it did. Every one of them was built for one person and a text box.

Design doesn't work that way. It runs on review and disagreement, and on a trail you can walk back months later when nobody remembers the original reasoning.

Figma seems to know this is the gap. AtConfig 2026they announced that agent chats are now visible to the whole team by default, so you can see what directions a teammate is exploring and build on it. That's real progress toward collaboration. What Figma hasn't announced is the history and traceability piece: a record of why a decision was made, not just that the AI made one. I think that's what has to come next, not something already shipped.

Nobody on my list has built that piece yet. Not the twelve tools, not Paper, and not Figma.

What I am doing for now

So I built it myself. A small MCP server that reads comments left directly on a Figma file and hands them to Claude, which makes the modifications the comment is asking for.

The workflow is exactly the ordinary thing designers already do all day: leave a comment on a file. Except now the comment is also the prompt. The most mundane gesture in design review became the instruction channel for an agent.

That's the actual ending to a year of testing everything. I went looking for a replacement. I didn't find one. What I found instead is that the last piece (the one that would have made this all feel finished) wasn't for sale anywhere I looked. So I built it, small and specific, for exactly my own workflow.

I made the tool work for me.

Sources

Figma Make export design doesn't export the library components— Figma Community Forum.

Paper Design vs Figma: Two Different Bets on the Future of Design— Katharina Pilz.

Config 2026: New Materials, New Tools and a More Expressive Canvas— Figma Blog.

Vibe coding changed how teams build. Designers, PMs, and engineers describe what they want in plain language and get working UI back. That speed comes with a cost. When everyone is building, the design system is the only thing keeping the product from looking like five different apps.

I use Claude Code and Cursor daily. I pushed my team to do the same.

The first thing I tried: pointing Claude at Figma

As soon as the Claude Code and Figma MCP integration shipped (and even before, with a custom MCP built by the designer community), I was providing the agent with a Figma DSYS file and prompting it to reference it when building prototypes.

It worked, mostly. But every task started with the agent pulling the entire Figma file, reading through it, and then proceeding. That overhead added up. Token costs climbed. Sessions got slower. For a small correction like fixing one color, it felt absurd to burn that much context just to confirm one rule. I ended up going from free, to pro, and ultimately to max. (I need something in between pro and max, but what can I do.)

When errors crept in: re-prompting

On top of the token cost, something else kept going wrong.

I noticed our green slate color showing up on an alert message. Green slate was designated for AI-generated responses only. I had been clear about this. So I went back in and corrected it. Next session, same mistake. I corrected it again. Same mistake again.

I explained the rule in the prompt. I added more context. The agent got it right for that session, then forgot it in the next one.

This is not a prompting problem. Every new session starts with zero memory of previous decisions. The agent doesn't know it used green slate incorrectly last week. It doesn't know which colors belong where. It makes reasonable guesses, and 200 reasonable guesses across a session don't add up to a consistent system.

What actually explained the problem

Hardik Pandya's articleExpose your design system to LLMsnamed what was happening. Agents fabricate values, drift within sessions, and lose all context between sessions. The problem wasn't my prompts or my Figma file. It was that my design system existed in a format optimized for humans, not for agents. Agents need structured, local, readable files they can check at the start of every session without burning through your context window.

That reframe changed how I approached the fix.

What I built

I tested this properly onLune, a wedding planning app I co-founded. I was the only designer on it, which made it the right place to try: a technical co-founder building alongside me, a real design system, and no tolerance for a prototype that looks like it was built by three different people.

The design system now lives in a /DSYS folder at the project root:

DSYS/ DESIGN-SYSTEM.md ← master reference, always read first tokens.md ← flat token quick-reference foundations/ ← color, typography, spacing, motion components/ ← one .md per component patterns/ ← layout and interaction rules

Every design value in the codebase has a named token. Nothing is hard-coded. In Lune, tokens map directly to Tailwind utility classes, so the lookup is fast:

ivory → bg-ivory / text-ivory (#faf6f0) gold → text-gold / bg-gold (#b8944e) espresso → text-espresso / bg-espresso (#1e1510)

DSYS/tokens.mdis a flat file with every token, its hex value, and its utility class in one place. When the agent needs to know what color primary text is, it reads one file and gets one authoritative answer. Not a Figma panel. Not a Storybook story. A plain markdown file.

Each component gets its own spec file inDSYS/components/. Every spec follows the same eight-section format: metadata, overview, anatomy, props, variants, states, usage rules, and code examples. The anatomy section uses ASCII diagrams to show hierarchy and nesting without requiring the agent to parse actual code. The usage rules section lists what not to do. That part matters as much as the positive examples, because it trains the agent away from the most common mistakes before they happen.

Then there isCLAUDE.md, the file Claude Code reads at the start of every session. It sets the rules once:

• Read DSYS/DESIGN-SYSTEM.md and the relevant component spec before any UI work
• Run the design audit script before every commit
• When building a new component, also create DSYS/components/<name>.md
• When modifying a component, update the spec and sync Figma

The agent doesn't need to be reminded of these rules in every prompt. They are part of the project.

The last piece is the commit gate.scripts/design-audit.jsscans every.tsx,.ts, and.cssfile for hardcoded values that should be tokens. If it finds a raw hex color or a pixel value that belongs to the token system, it flags the file, the line number, and the correct class to use instead. The audit runs automatically on everygit commitvia a pre-commit hook. The commit is blocked until the audit passes. When a collaborator clones the repo and runsnpm install, the hook installs automatically. No manual setup, no way to skip it by accident.

Figma still has a role, but a different one. The MD files are the implementation contract: what shipped and what the audit enforces. Figma is the exploration layer, where new screens get designed and stakeholders review. When a component gets a new state or variant, the rule is to update both in the same pass. Claude is instructed to remind you to do this at the end of every component change.

What changed

Green slate now has a rule written in a file: use only for AI-generated response containers. The agent reads the file. The audit catches violations. It doesn't rely on my memory or my prompts.

A contributor with no design background can now build a new screen in Lune. They get code a designer would recognize, not because they studied the design system, but because the system was structured to be readable by the tool doing the work.

The bigger shift is that consistency is no longer something I enforce through reviews or repeated prompts. It's something the system enforces. That's what a design system is supposed to do. It just took me a while to realize agents need it in a completely different format than the one I built it in.

Resources

Expose your design system to LLMsby Hardik Pandya. The article that reframed how I thought about this problem.

Design Systems

Claude Skills

Workflow + Process

Podcasts

People I Follow