DEV Community: shadcncraft

Claude Cowork has changed managing a Figma design system library forever

shadcncraft — Wed, 27 May 2026 05:27:05 +0000

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.

From Figma to production React, with AI in the loop

shadcncraft — Wed, 27 May 2026 05:21:17 +0000

The four pieces of the new design-to-code workflow: shadcncraft in your project, the shadcncraft Figma kit, the Figma MCP, and the shadcn MCP. How to set it up, what the loop actually looks like on a real task, and how to bring it into an existing project.

Designers have been promised "design-to-code" for years. What kept arriving was a button that exported a div soup nobody wanted to ship. The promise quietly stalled. Something has shifted in the last twelve months, and the workflow that comes out the other side is finally one a real team can use.

This post is for the designer who wants to stop throwing redlines over the wall, and for the developer who wants to stop translating Figma layers into JSX by hand. It is about a single loop: design in Figma using a kit that matches your React components one to one, then let an AI tool read the Figma file and produce code that already speaks the same language as your codebase. Both sides of the team work in their native tool. The AI does the translation step that used to be a tax on everyone.

Below is how the loop works, how to set it up on an existing project, and where to keep your hand on the wheel.

Why this loop is different now

Three things had to be true at the same time, and they finally are.

First, your design file has to use the same building blocks as your production code. Not a "Figma version of a button." The same button, with the same name, the same variants, the same prop surface, sitting in your Figma library and in your /components/ui/ folder. shadcncraft is built around this constraint. The Figma kit and the React registry mirror each other component for component, slot for slot.

Second, the AI needs to see the design. The Figma MCP server exposes design files to AI tools the same way the file system is exposed to a code editor. Claude, Cursor, Codex, and friends can now read a frame, understand its structure, see the variables in use, and reason about it. This is what flipped the workflow. Until last year, AI tools could only see the screenshot. Now they can read the layers.

Third, the AI needs to recognise the components. The shadcn MCP server, plus shadcncraft's namespaced registry, means the AI is not generating React from scratch every time. It can pull the right component from your installed kit and compose with it. The generated code looks like it came from someone who already knew your conventions, because it did.

When those three pieces are connected, the loop runs like this: design a screen, ask the AI to implement it, get a first pass that uses your real components, refine in the editor. The translation step that used to take an afternoon takes a few minutes. The drift between design and code shrinks because both ends are pinned to the same kit.

The setup, end to end

There are four pieces to connect. Once they are in place you do not touch this part again.

1. shadcncraft installed in your React project

If your project already uses shadcn/ui, you are most of the way there. Add the shadcncraft registry to your components.json, set your license key in .env, and you can install any block or component with the standard shadcn CLI:

pnpm dlx shadcn@latest add @shadcncraft/header-1

The full setup is in the Installation docs, including how to switch style presets and how to configure a team license.

2. The shadcncraft Figma kit, opened in Figma

Open the kit in Figma. This becomes your design library. Every block and component you can install in code has a matching counterpart here, with the same name and the same variants. Themes are managed inside the file using the shadcncraft Figma plugin, which can export shadcn-compatible CSS variables straight from your Figma file into your codebase. Your design tokens and your code tokens stop being two separate things to maintain.

3. The Figma MCP server, connected to your AI tool

Enable the Figma MCP server in Figma's settings, then point your AI tool at it. Cursor, Claude Code, VS Code, and Codex all support MCP servers. Once connected, the AI can read any Figma file you have open, including the shadcncraft kit and the screens you are designing on top of it.

4. The shadcn MCP server, also connected

The shadcncraft registry works with the shadcn MCP server out of the box. From your project root, run the init command for your editor of choice:

pnpm dlx shadcn@latest mcp init --client cursor
pnpm dlx shadcn@latest mcp init --client claude
pnpm dlx shadcn@latest mcp init --client vscode

With both MCP servers connected, your AI tool can simultaneously read the Figma file (via Figma MCP) and install the right components from your kit (via shadcn MCP). This is the bridge.

If any of the four pieces are missing, the loop still works in a degraded form. You can build by hand without the AI, or use the AI without Figma MCP and lose the design context. But all four together is what makes this feel like a single workflow rather than four separate tools you keep tab-switching between.

The loop in practice

Here is what the loop looks like on a real task. Imagine you have an existing SaaS app, already built on shadcn/ui, and you need to add a billing settings page.

You open your Figma file. You compose the screen out of shadcncraft blocks: a page header, a settings nav, a plan summary card, an invoices table, a payment method block. Because these are real components from the kit, they already have the right tokens, the right spacing, the right empty and error states. You change copy, swap the plan tier, point the table at your real data shape. You spend maybe twenty minutes designing.

Then you switch to your editor and ask Claude something like:

"Build the billing settings page from the selected frame in Figma. Use the existing shadcncraft components in this project. Keep the existing route conventions and data fetching patterns from the user settings page."

Claude reads the Figma frame through the Figma MCP. It sees the shadcncraft layer names. Because shadcncraft's convention is for layer names to match the data-slot values in the React components, it knows that card-header becomes <CardHeader>, that tabs-trigger becomes <TabsTrigger>, and so on. It installs anything from the registry that is not already in your project, references your existing data fetching patterns, and outputs the page.

The first pass gets you most of the way there. You review the diff. You correct the things only you can correct: business rules, real data shape, copy that the design did not specify, edge cases the AI did not consider. You commit.

This is the part the previous generation of design-to-code tools never delivered. The code that comes out is not div-soup that you would never write yourself. It uses the same components you would have picked, with the same props, in the same composition. Because the AI did not invent the components from a screenshot, it composed them from your installed kit.

Where the loop breaks, and what to do about it

Honest answer: the loop is not a magic button. It works well when both ends are disciplined. Here is what to watch for.

The Figma file has to be built out of shadcncraft components, not custom shapes that happen to look like shadcncraft components. If your designer detached an instance to make a one-off tweak, the AI cannot see the underlying component anymore. It just sees a frame with some rectangles in it. The output will be generic JSX rather than your kit. The fix is mechanical: keep instances intact, use slots and variant properties to make changes rather than detaching.

The AI's output is a starting point, not a final commit. Treat it like a pull request from a fast but new contributor. Read it, run it, refactor anything that does not fit your codebase's conventions. The advantage is the speed of the first pass, not the elimination of review.

Drift is real, but it is now measurable. If you generate a screen today and the kit updates next month, your screen does not auto-update. This is the same problem any installed-not-imported registry has, and shadcncraft handles it the way shadcn does, with the update strategy in the docs. The point is that drift is now visible and resolvable, instead of being the permanent baseline.

When the AI picks the wrong component, the fix is usually a clearer name. If the same prompt keeps producing a Dialog when you wanted a Sheet, that is feedback about your naming, not about the AI. shadcncraft component names are public surface, and we update them when they consistently confuse tools or people.

Why this beats the previous attempts

Two reasons, both structural.

The first generation of design-to-code tools tried to be clever about screenshots. They read pixels and tried to infer structure. That works for a static rectangle and falls apart on anything stateful, anything responsive, anything composed of real primitives. By contrast, this loop reads the actual Figma layer tree and matches it to actual React components. There is no inference layer to get wrong.

The second is that the design file and the production code are pinned to the same source. Both sides use the same kit, with the same names, the same variants, the same tokens. The AI does not have to translate between two languages, it just has to assemble. That is the part AI tools are good at right now.

Bringing this into an existing project

You do not need to start over. You probably should not.

If your project already uses shadcn/ui, you can layer shadcncraft on top without ripping anything out. Components install side by side with your existing ones. Tokens align. Pick one screen on your roadmap, ideally one that is greenfield or due for a refresh, and try the loop end to end on that single screen. A settings page, a new onboarding flow, a billing card. Anything contained enough that you can compare the before and after honestly.

What you are looking for in that first screen is not a productivity number. You are looking for whether the loop feels like one workflow or four. If it feels like one, expand from there. If it feels like four, the most common culprit is that one of the four pieces is not actually connected, usually the Figma MCP. Worth ten minutes to check.

If you want a place to start, the Installation docs cover the project side and the shadcn MCP setup. The Figma kit and the Figma MCP setup live inside Figma itself. Pick a screen, set aside an afternoon, and see what comes out the other side.

The promise that designers and developers could ship from the same source has been around forever. This is the first time it has been true.

Create and preview your own design system with shadcncraft create

shadcncraft — Thu, 30 Apr 2026 00:52:25 +0000

shadcncraft create mirrors shadcn create, with the same styles, bases, icon libraries, themes, fonts, and preset workflow, plus live previews of shadcncraft pro blocks.

shadcncraft now has its own create experience.

It mirrors shadcn create: same styles, same bases, same icon libraries, same themes, same fonts, same radius, same preset codes.

The difference is the preview. On shadcncraft create, you can test those combinations directly on shadcncraft pro blocks before installing anything.

If you already have a shadcn project, you can also resolve its current preset with the shadcn CLI, import it into shadcncraft create, and preview your existing design system on real pro blocks.

The workflow

If you already have a shadcn project:

Resolve your current preset.
Import the preset into shadcncraft create.
Preview it on pro blocks.
Adjust the config if needed.
Use the new preset with init or apply.

If you are starting fresh, skip the first step and build a preset directly in shadcncraft create.

Resolve your current preset

From your existing shadcn project, run:

npx shadcn@latest preset resolve

You can also use the alias:

npx shadcn@latest preset info

The CLI reads your current shadcn config and returns the matching preset code.

Example:

Preset
  code         b5Kc6P0Vc
  version      b
  style        luma
  baseColor    olive
  theme        lime
  chartColor   sky
  iconLibrary  hugeicons
  font         geist
  fontHeading  inherit
  radius       default
  menuAccent   subtle
  menuColor    default
  url          https://ui.shadcn.com/create?preset=b5Kc6P0Vc

The important part is the code:

b5Kc6P0Vc

That code contains the visual setup: style, theme, colors, fonts, radius, icons, and other preset settings.

For monorepos, point the command at the app:

npx shadcn@latest preset resolve -c apps/web

For machine-readable output:

npx shadcn@latest preset resolve --json

Import it into shadcncraft create

Presets are fully compatible between shadcn create and shadcncraft create.

If you made a preset on ui.shadcn.com/create, you can import it into shadcncraft create. If you resolved one from an existing project, import that too.

The importer accepts:

A bare preset code
A --preset <code> flag
A full shadcn init --preset <code> command

Open shadcncraft create, choose the open preset option, and paste any of these:

b5Kc6P0Vc

--preset b5Kc6P0Vc

npx shadcn@latest init --preset b5Kc6P0Vc

shadcncraft create extracts the preset code and applies the same config to the customizer.

Now your existing shadcn setup is loaded into the preview.

Preview real pro blocks

The point of shadcncraft create is the block preview.

Preview your preset across real shadcncraft pro blocks: marketing, application, and ecommerce. Small component previews help, but blocks expose the full system.

You can keep adjusting:

Base: Radix UI or Base UI
Style: Vega, Nova, Maia, Lyra, Mira, Luma, or Sera
Icon library: Lucide, Tabler Icons, Hugeicons, Phosphor Icons, or Remix Icon
Theme, base color and chart color
Font and heading font
Radius
Menu accent and menu color

Create a new project

Once the preview feels right, use the preset with init.

npx shadcn@latest init --preset b5Kc6P0Vc

This creates a new project with the selected style, theme, fonts, radius, icons, and preset settings from the start.

You can also include a template:

npx shadcn@latest init --template next --preset b5Kc6P0Vc

Same shadcn CLI. Same preset resolver. shadcncraft create just gives you a better way to choose before running the command.

Apply it to an existing project

Presets are not only for new projects.

To update an existing shadcn project, apply the preset:

npx shadcn@latest apply b5Kc6P0Vc

This updates the project to match the preset, including theme, colors, CSS variables, fonts, icons, and detected UI components.

You can also apply only the parts you want:

npx shadcn@latest apply b5Kc6P0Vc --only theme

npx shadcn@latest apply b5Kc6P0Vc --only font

npx shadcn@latest apply b5Kc6P0Vc --only theme,font

That makes it easy to test a new visual direction without rebuilding the project.

Why this matters

The new shadcn preset commands make your current project portable.

preset resolve and preset info turn an existing project into a preset code.

shadcncraft create can import that code and apply the same config to the live customizer.

Then you can preview your existing design system against shadcncraft pro blocks before changing anything in your app.

Resolve the preset. Open it in shadcncraft create. Preview real pro blocks. Then create, apply, or share the setup.

Try it

Open shadcncraft create, pick a pro block, and start switching styles, bases, icons, themes, fonts, and radius.

When the preview looks right, copy the preset.

Create a new project with it, apply it to an existing one, or import it back into shadcn create.

Same shadcn foundation. Same preset workflow. Now with shadcncraft pro blocks in the preview.

Pick your shadcn base, your style, your icons

shadcncraft — Tue, 28 Apr 2026 02:48:39 +0000

shadcncraft now supports Base UI, all seven shadcn styles, multiple icon libraries, and a new customizer for previewing combinations before install.

shadcncraft now adapts to your setup.

Choose your base, style, and icon library, and everything follows. A new customizer lets you preview combinations live.

Until now, every component shipped with fixed defaults: Radix UI, the standard shadcn look, and Lucide icons. If your project used something else, you had to adjust it after install.

That is no longer the case. shadcncraft now respects your project config from the start.

Your project defines the defaults

Your setup is the source of truth. The registry reads what you've chosen and installs components to match:

Base — Radix UI and Base UI, both fully supported.
Style — all seven shadcn presets.
Icons — Lucide, Tabler Icons, Hugeicons, Phosphor Icons, and Remix Icon.

Tokens, fonts, radius, and themes remain unchanged. Nothing gets overridden.

Built on shadcn styles

These styles come directly from shadcn. Same presets, same output.

Vega — classic shadcn look.
Nova — tighter spacing, more compact.
Maia — softer and more rounded.
Lyra — sharp and structured.
Mira — dense and product-focused.
Luma — softer and more fluid.
Sera — editorial and typographic.

If your project already uses one of these, shadcncraft follows it. If not, you can try them across the library.

Custom styles from shadcn create also work.

Preview every combination

Each component and block page now includes a live customizer.

You can:

Switch between Radix and Base UI
Change styles
Swap icon libraries
Adjust fonts and radius
Apply shadcn or tweakcn themes

This is the same model as shadcn create, applied to every component and block.

You can see exactly what you'll get before installing anything.

Works across the library

Support is library-wide. Components and blocks are built to follow your config.

Some older blocks may not support every option yet. We're updating those over time and will surface support more clearly on each component and block page.

One-line migration

Nothing breaks if you're already using shadcncraft.

To enable style-aware install, change one line in components.json:

{
  "registries": {
    "@shadcncraft": {
-     "url": "https://shadcncraft.com/r/{name}",
+     "url": "https://shadcncraft.com/r/{style}/{name}",
      "headers": {
        // ... your existing headers ...
      }
    }
  }
}

That's it.

Try it

Try the customizer on a live pro block. You can test different bases, styles, icons, and themes in our pro components and blocks before installing.

Where this is going

This brings shadcncraft closer to how shadcn create works.

Same styles. Same structure. Same expectations.

The goal is simple: your design system behaves the same in Figma and in code.

More updates coming soon.

Introducing shadcncraft

shadcncraft — Wed, 08 Apr 2026 06:37:08 +0000

New name, new website, bigger vision

Today we’re launching a new name, a new brand, and a completely rebuilt website.

Shadcraft is now shadcncraft.

This change reflects what the product has become and where it is going next.

Why the rename

From the beginning, the goal was simple: build the best design system built on top of shadcn/ui.

Over time the product grew beyond a simple Figma UI kit. It became a full ecosystem built around the shadcn stack, including:

A React component library
A matching Figma design system
Hundreds of production ready UI blocks
A plugin for importing and exporting themes
Tools designed to work naturally with modern AI coding workflows

The new name makes that connection clear.

shadcncraft reflects what the product actually is: carefully crafted design system tools built specifically for the shadcn ecosystem.

A completely new website

Alongside the rename, we’ve rebuilt the entire website from scratch.

The old site did not reflect the scope of the product anymore. It focused heavily on the Figma kit and did not show the full design system.

The new site fixes that.

It clearly shows what shadcncraft provides:

React components ready for production
Matching Figma design files
Hundreds of blocks across marketing, application, and ecommerce
Full sites and templates
Design tokens and theming tools

Everything is now easier to explore, preview, and understand.

The new structure also makes it much easier to browse blocks, pages, and full site templates.

Built for modern workflows

Frontend development is changing quickly.

Tools like Cursor, Claude Code, v0, and Figma Make are reshaping how developers and designers work together.

Design systems now need to support both humans and AI.

shadcncraft is designed for that new workflow.

The system is built around:

Clean React components
Structured design tokens
Predictable theming
Consistent naming and patterns

This makes it easier for developers, designers, and AI tools to generate high quality UI.

React and Figma working together

One of the biggest goals for shadcncraft is tight alignment between design and code.

Every block and component exists in both places:

React code ready to install
Matching Figma components

Designers can work in Figma while developers install the exact same blocks into their projects using the CLI.

No guesswork. No rebuilding UI from scratch.

What stays the same

Even with the new name and brand, the core philosophy remains the same.

shadcncraft is still focused on:

Clean, production ready UI
No unnecessary abstraction
Simple installation via the shadcn CLI
Full ownership of the code you install

You get real components you can ship to production, not locked templates or proprietary frameworks.

What’s coming next

The rebrand and website launch are just the beginning.

There is a lot more coming:

More blocks across all categories
More full site templates
Deeper theming support
Improvements to the plugin
Tighter integration with modern AI coding tools

The goal remains simple: make it dramatically faster to design and ship high quality interfaces with shadcn.

Thank you

A huge thank you to everyone who has supported the project so far.

Thousands of designers and developers have already used the kit, shared feedback, and helped shape what shadcncraft is becoming.

If you have not explored the new site yet, take a look and see what is new.

New way to bring your tweakcn themes into Figma (works with shadcn/ui)

shadcncraft — Sun, 03 Aug 2025 21:22:47 +0000

Hey folks 👋🏻

If you’ve been using tweakcn to customise your shadcn/ui theme in the browser, you can now bring those themes straight into Figma via a new integration with Shadcraft and the tweakcn plugin.

Here’s how it works:

🎨 tweakcn is a super handy in-browser theming tool for shadcn/ui (great for quickly testing out colour, radius, shadow, etc.)
🔌 With the plugin, you can now apply your custom theme to a Figma UI kit built specifically for Tailwind and shadcn-based projects
⚡ It’s all powered by Figma variables, so you can instantly switch between themes or update styles without tedious overrides

It’s been a smoother handoff experience for us working across dev/design — especially when devs pick the theme in tweakcn and designers apply it in Figma.

You can try it out at tweakcn.com — happy to answer questions or share how we’ve been using it in side projects too.