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.
