Field notes from a month of running a Figma library with Claude Cowork in the loop. What it is great at (variables, rebinding, scoped refactors, plugin generation), what it cannot do (anything truly visual), and the workflow rules I had to learn the hard way so it does not eat your file.
If you manage a Figma library for a living, you already know the work that does not show up in any portfolio. Renaming a few hundred variables when a naming convention shifts. Hand-building a tokens page so an AI tool can pick up your variables. Quietly reconciling drift between the Figma kit and the code-side tokens because nobody else is going to. Writing internal docs that go stale the moment the library updates.
I have spent the last month using Claude Cowork on the shadcncraft Figma kit, and most of that work has changed shape. Tasks that used to take days are now a single scoped prompt. Tasks that were never really practical to attempt by hand, like a full cross-collection audit, are suddenly on the menu. And a small but real slice of the work is now riskier than before, because the agent is happy to make large, confident changes you may not catch until later.
This is the guide I wish I had at the start. It is written for designers and design system leads who own a Figma library and want to know, in concrete terms, what Cowork is good at, what it is bad at, and the workflow rules that keep it useful rather than dangerous.
What this is, in one paragraph
Claude Cowork can read and write your Figma file directly through the Figma MCP. It can rename variables, rebind them, audit collections, walk component trees, change states, and write Figma plugins for you on demand. It cannot see your file the way you and I can. It reads the underlying node tree and variable graph, not pixels. Once you internalize that, almost every good and bad thing about working with it makes sense.
If you are not using it yet for library work, you are about to fall behind. The catch is that "using it" badly is worse than not using it at all, because confident agents at scale produce confidently broken files at scale. The point of this post is to spare you that.
This post is about using the Figma MCP loop to maintain a Figma library. If what you actually want to do is use the same loop to build apps from your Figma file, that is a separate workflow with its own setup, and it has its own post: From Figma to production React, with AI in the loop.
Two customer pain points this directly solves
When we ran the last shadcncraft customer survey, two themes came up again and again from people running a Figma library against a shadcn/ui codebase. Cowork puts a real dent in both.
The first was designers building a hand-maintained "tokens page" inside their Figma file purely so an AI workflow could read variables over the Figma MCP. With Cowork in the loop, that page is unnecessary. It can read the variables directly. The workaround can now go away.
The second was drift. Customers running a Figma kit alongside a shadcn codebase spend ongoing cleanup time keeping the two in sync, because there has never been a good way to detect where they diverge. Cowork can read your shadcn CSS variables file and compare it against your Figma variables in one pass. Drift becomes visible and fixable in a single operation, instead of a slow manual reconciliation that nobody has time for.
Neither of these were really design problems. They were tax that design system owners were paying because the tooling did not exist. The tooling now exists.
What Cowork is genuinely great at
Three areas have changed the shape of my week.
Variable management, rebinding, and managing states
This is the thing Cowork does that I no longer want to do by hand, ever. Bulk renames across a collection without breaking references. Rebinding instances from one variable to another. Switching states on a large set of components. Moving a variable from Primitives into Theme while preserving every reference that points at it. These are the tasks where a careful agent saves you days, and the work is mechanical enough that the agent stays accurate if you scope the prompt properly.
Auditing collections and detecting drift
Asking Cowork to walk a single collection and report unused variables, duplicates, suspiciously similar values, or values that drift from your code-side tokens is the kind of task a human will do once and never again. The agent does it on demand, without complaint, and it can run the same audit on a cadence if you want it to.
Writing Figma plugins for you
This one took me by surprise and is now one of the highest leverage uses of the tool. Cowork is extremely good at writing small, single-purpose Figma plugins. If you have a repetitive task that you would rather not run through an agent every time, ask Cowork to write you a plugin that does it once, locally, in your file. The plugin runs as fast as Figma can execute, has no API timeout, and never gets bored or lazy halfway through. There is a real lesson here: sometimes a dumb deterministic script is a better answer than a smart agent that gets distracted on the seventh hundredth iteration.
The other reason to prefer plugins for big jobs is that the Figma MCP has a 60-second timeout. Large agent-driven tasks routinely run past it, and when they do, the agent often has no clean confirmation that the work either completed or failed. A plugin sidesteps that entire failure mode.
What Cowork cannot do
Be honest with yourself about this before you start, because the failures are not always loud.
It cannot "see" your file
Cowork reads the underlying Figma data, not the canvas. It does not know that a button looks visually unbalanced, that a card has slightly more breathing room on the right than the left, that an icon is optically misaligned, or that a color, while technically correct, looks wrong against the surface behind it. Any task that depends on visual judgment is yours, not the agent's.
In practice this is fine. It actually makes you a better team. You bring the visual taste; the agent does the bulk mechanical work that would otherwise make you want to lie down. Once you stop expecting it to design, the division of labor settles in quickly.
It cannot order your variables
It can reorder layers without much trouble, but variable ordering inside a collection is not currently something it can change. Worth knowing before you ask it to "tidy up" a collection and then wonder why the order is unchanged.
It is happy to confidently break things at scale
This is the failure mode that almost broke me. Without the right guidance, Cowork behaves like an extremely over-confident junior designer. It will tell you the job is done. It will sound certain. And, if you let it loose on a whole file, it will sometimes have quietly snapped references, renamed things you did not want renamed, or modified components it should not have touched. The rest of this post is, in many ways, the set of habits I built to stop that happening.
The workflow rules that make it work
These are not optional. Every one of them I learned the hard way.
Do small, specific, scoped tasks
The single most important habit. Give Cowork one narrow job at a time. Point it at a specific node, a specific collection, or a specific component set. The more scoped the task, the less surface area for it to do something unexpected.
When I am pointing it at something specific in Figma, I paste the node URL straight into the prompt. That removes any ambiguity about which thing I am referring to and stops it from wandering off into adjacent parts of the file looking for something that loosely matches the description.
Chunk down large tasks
If a job feels big, it is too big. Break it into pieces and run them as separate prompts. When I have asked Cowork to "walk the whole file" and do something across the lot, bad things have happened. Sometimes the API times out partway through. Sometimes it processes a slice and reports success. Sometimes it touches things it should not have.
A good rule of thumb: if the task touches more than one collection, more than one page, or more than a few hundred nodes, split it.
For big repetitive jobs, ask for a plugin
This deserves repeating because it is the single biggest unlock. If you have a job that is large, deterministic, and you might want to run again, ask Cowork to write you a plugin for it. The plugin runs locally inside Figma, dodges the MCP timeout, and produces consistent results across thousands of iterations. Cowork is exceptionally good at this, and it converts a stressful agent run into a one-click button you keep around.
Store reference files in the project folder and point the agent at them
Cowork's memory is not something you want to rely on across a long session. The fix is to put the source of truth in the project folder and instruct the agent to read it whenever it needs to. I keep the shadcn styles CSS in the folder, for example, so any sync or audit work references the actual file rather than the agent's recollection of what it looked like an hour ago.
This is also a quiet token saver. The agent does not have to carry a long copy of the file around in its working context. It reads, acts, and moves on.
Keep a CLAUDE.md in the project folder
For any sustained piece of work, build a CLAUDE.md file alongside your project. Use it to capture the broader goal of the session, conventions the agent should follow, references it should read before acting, and anything you have asked it not to touch. Update it as the work evolves. Over a long chat this is the difference between an agent that holds the thread and an agent that drifts back to a generic default behavior.
Get it to validate its own work
Never accept "done" at face value. Ask it to read back what it changed, run an audit against the change, or open the affected nodes and report their current state. If you are doing something destructive, ask it to dry-run first and list what would change before you let it commit.
Make regular backups in Figma version history
Before any larger or potentially breaking change, save a named version in Figma's version history. This is your undo button when the agent confidently does the wrong thing at scale. It costs you ten seconds and it has saved me from rebuilding entire collections more than once.
Plan for token cost
Cowork chews through tokens. For the month of intensive library work I moved onto the Pro Max 20x plan so I could stop thinking about usage caps, and that turned out to be the right call. If you are working at a lower tier, scope your prompts tighter, lean harder on plugins for repetitive work, and avoid open-ended "explore the file and tell me what you find" prompts. Those are the most expensive and the least reliable.
Three new workflows worth knowing about specifically
The capabilities I covered above are general. These are three specific workflows where I went from "this is a known problem with no good answer" to "this runs in one prompt." Worth calling out individually because they each unlock something that was either painful or genuinely not possible before.
Drift detection against your code-side tokens
Drop your shadcn CSS variables file into the project folder. Ask Cowork to read it and compare against the equivalent Figma variables, reporting any value mismatches, any tokens that exist on one side and not the other, and any naming inconsistencies.
The output is a list. You decide which side is right and ask Cowork to bring the other into line. The point is that the drift becomes visible in one pass, instead of slowly accumulating in the background as it does today. If your code-side tokens are the source of truth, the same workflow goes the other way: read the CSS, write the values back into Figma.
Per-variable reference docs generated from the live Figma file
Ask Cowork to walk a collection and produce a reference document, one entry per variable, with the current value, what it is aliased to, and where it is used. Store the output alongside your library and your docs stay aligned with the file without anyone transcribing anything. Re-run it after any meaningful change. This is the one that finally killed the "docs are always six weeks out of date" problem for me.
Custom plugins for your most repetitive jobs
When the task is "do this exact thing several thousand times across a file," I do not ask the agent to do it. I ask the agent to write me a plugin that does it, run the plugin, and verify the result. Stripping a specific deprecated style off every instance of a component, retagging a large set of nodes, batch-renaming layers to match a new convention. The plugin is faster, cheaper, more reliable, and you keep it around for next time.
The moment you will want to quit
I will tell you this so you are ready for it. There have been at least two moments during this month where I was so frustrated at Cowork's apparent ineptitude that I genuinely considered abandoning the project and canceling my plan. Something I had asked it to do had gone badly wrong at scale, and the damage was big enough and expensive enough that the cleanup was going to take longer than starting from scratch.
The thing that kept me going both times was simple: I went back to doing the same job manually, and after about twenty minutes it felt absurd. The power of the tool, when it works, is high enough that going back is no longer a serious option. The frustration is real, but it is a frustration of working out the right workflow, not a frustration with the underlying capability.
If you find yourself in that moment, the answer is almost always the same. Make the scope smaller. Point at a single node. Ask for a plugin instead of an agent run. Add a validation step. Restore from version history and try again. Update your CLAUDE.md so the agent does not make the same mistake twice.
Start small
Pick one collection. Something contained, like renaming a set of spacing variables to a new convention. Run it with the rules above and see how it feels. Build from there.
If you own a shadcncraft Figma kit, every workflow in this post runs against your file today. If you are running a different shadcn-based library, most of them will transfer with minor changes.
If you hit something that does not behave the way this guide suggests, come and tell us in the Discord.
