DEV Community: Hamish O'Neill

How to manage your design system with the UI Rules Agent

Hamish O'Neill — Mon, 07 Sep 2026 06:41:32 +0000

Part of a series on keeping AI tools on brand with UI Rules. Watch the video version on YouTube.

Managing a design system means making lots of small edits: clarifying a guideline, changing a style, or deciding which components belong in a project. Working through a form for each change takes time, even when you already know what you want.

The UI Rules Agent lets you describe those changes in plain language. It drafts proposals for you to review, so you can spend more time on the decisions and less on entering them.

Review every design system change before it lands

The Agent proposes. You decide what actually lands.

Every change it drafts arrives as a proposal you can approve or reject. Asking for an edit does not apply it automatically. You get to check whether the proposal captures what you meant before it becomes part of your design system.

That matters because a short request can leave room for interpretation. "Make the labels clearer" could mean changing the wording, placement, or both. A proposal gives you something specific to assess against your brand guidelines.

Review the substance, not just whether the wording sounds polished. Check which decision the proposal expresses and whether it belongs in your system. If it misses your intent, reject it and describe the change more precisely. Nothing is applied without your approval.

The same approach carries through the Agent's work, whether you're adding guidance or changing what connected tools can see.

Write design guidelines by describing the change

Start with a decision you would explain to another designer:

Add a rule that form labels always sit above the field.

The Agent drafts a rule from that request, including a type and importance level. You review the proposed wording and check that those choices match your intent.

A type describes how to interpret a rule: Do, Don't, Caution, or Info. Importance distinguishes Required, Recommended, and Optional guidance. A form-label convention might be a requirement in your system or a recommended approach with exceptions. The proposal lets you assess that distinction before approving it.

Keep the request focused on one decision. If the placement of a label and the wording of an error message are separate guidelines, describe them separately. The guide to writing design system rules explains how rule text, types, importance, and rationale fit together.

Control what your AI tools can see

Your system may include components or blocks that don't belong in a particular project. You can ask the Agent to change their visibility in plain language, such as:

Hide all marketing blocks.

Review the proposed visibility change, then approve it if the selection is right. The blocks aren't deleted. They stop being served to your connected AI tools.

This gives you a way to shape the component set those tools work with. You can keep marketing blocks out of a product project's available choices without removing them from your system.

Add your logo alongside its guidelines

Give the Agent your logo and it prepares it with its variants, ready for usage rules. As with other changes, you review the proposal before it is applied.

The asset and its guidance belong together. Having a logo available doesn't explain which version belongs on a dark background or where it should appear. Use your existing brand decisions to guide those rules, so your connected AI coding tools have both the asset and the context for using it.

Refine rules and scan your website with Pro

The free plan includes a limited Agent. The full Agent, Enhance, and Scan your website are available on Pro.

Enhance helps turn a loosely written guideline into something more precise. For example, you might start with:

Make sure text lines never get too long.

Enhance can propose "Keep body text line length at or under 70 characters," with Do as the type and Recommended as the importance. It shows what changed and why, and you can apply or discard the suggestion. Check that a suggested limit fits your system before accepting it.

Scan your website starts from a different source: your live site. Give the Agent the URL and it drafts styles for you to review as proposals. These styles are your design tokens, including values for color, typography, and spacing. The brand styles guide explains how those values work alongside your written guidelines.

Coming soon: give the Agent an existing brand document and turn its guidelines into editable rules and styles.

Where to start

Choose one small update you already know you need. Describe it as you would to a colleague, review the proposal, and approve it when it matches your decision. Then move on to the next change.

Start with your own design system at uirules.com.

How to keep AI aligned to your design system

Hamish O'Neill — Mon, 07 Sep 2026 06:40:58 +0000

Written for design system managers, with examples for brand teams too.

Your design guidelines capture years of decisions about how your organization's products should look, work, and sound. Some are immediately visible, such as typography and color. Others show up as people use the product: whether they can undo a deletion, what a button says while they wait, or how an error message helps them recover.

When someone on your team builds a screen with AI, those decisions still matter. A screen can use the right colors and miss the behavior you've carefully worked out. A delete action might skip a necessary confirmation. An error message might explain the problem without telling anyone how to fix it.

How do you make that guidance available to the tools your team is using, and keep it current as your system changes? This guide looks at the problem from a design system manager's perspective, with examples for brand teams too.

Keep accessibility and usability decisions in the build

A finished screen doesn't show all the work behind it. Your team may have tested its contrast in dark mode, checked the keyboard navigation, and revised the wording after watching people struggle with a form.

Those choices belong in the next version of the product too, whether a person or an AI tool builds it. Sharing the visual styles alone won't explain how a focus state should work, how large a touch target needs to be, or what an error message should include.

The reasoning matters as well. If your date picker behaves a particular way because of usability testing, that context helps someone understand why they shouldn't casually change it.

An AI tool needs access to those guidelines to take them into account. Without them, it may produce a reasonable interface that doesn't follow the decisions your team has already made.

Make your documentation available to AI tools

Your documentation may already cover all of this: component behavior, styles, content guidelines, and examples of what to do and what to avoid. The question is whether the tool building a screen has that guidance available when it needs it.

AI tools can read documentation when you give them access. But having a docs site doesn't mean every tool your team uses will find the relevant page or read its latest version.

For a designer, looking up a component is part of the work. With an AI tool, that step needs to be part of the workflow too. Otherwise, your guidelines can be well documented and still be absent from the request the tool is working on.

Markdown files and Notion pages get out of sync

One approach is to copy your guidelines somewhere the tool can read them: a Markdown file alongside the code, a Notion page, or a skill file containing instructions for a particular tool.

That can work well for a small project. The maintenance problem starts when the original guidelines change. If you update the spacing guidance on your docs site, someone also needs to update every copy used by an AI tool.

Skill files need the same care. A file written for one project can remain in use long after the person who created it has moved on. Without a clear owner and a review process, it's easy to lose track of which guidance is current.

The files themselves aren't the problem. It's the extra work of keeping several copies of the same guidance up to date.

It gets worse with a team

That work grows as more people and tools get involved.

A designer might prototype in one tool while an engineer builds in another. If each uses a separate copy of your guidelines, a single design-system change can mean updates across several projects.

Say you changed your focus-state guidance last week. How would you check that every tool has the new version? With separate files, someone has to find and review each copy.

If a tool uses old guidance, the difference may not show up until design review. Your team ends up correcting work using decisions it had already documented.

One place your tools read from

We built UI Rules to give connected AI tools a shared place to read your design system. Instead of maintaining a separate set of instructions for each tool, you manage the styles and guidelines together.

Your brand in UI Rules holds two things.

Your styles are the real values, your design tokens: color, typography, radius, shadow, spacing, sizing, and layout, with light and dark values where they apply.

Your rules explain how to use those styles, along with guidance for behavior and content. A primary color value tells a tool which blue to use. A rule can tell it to reserve that color for the main action on a screen.

Give a tool your brand styles and it'll look like your brand. Rules help apps work and sound like your brand.

Write rules that explain what matters

Each rule has a type: Do, Don't, Caution, or Info. It also has an importance level: Required, Recommended, or Optional. Use these to distinguish a requirement, such as minimum contrast, from a preference. They help a tool interpret your guidance, but they don't replace reviewing its work.

Write a rule as you'd explain it to a colleague. If you want help refining it, Enhance, available on Pro, suggests clearer wording and explains the changes. You review the suggestion before applying it.

Keep related rules in named groups alongside the components, styles, or content they describe. You can lock agreed rules to protect them from edits.

Guidelines for your components

UI Rules also includes components based on shadcn, an open-source collection of interface components such as buttons, cards, and dialogs. Each component can carry guidelines for how your team uses it, including spacing, behavior, and states. You can also turn off components that aren't part of your system.

Give your tools access to current guidelines

You can connect Claude Code, Cursor, v0, Lovable, Codex, and Figma Make to your brand. Connections are read-only by default, so a tool can read your guidelines without being allowed to change them.

When you update a rule, the new version is available the next time a connected tool reads your brand. That gives your team one place to check the current guidance instead of searching through separate instruction files.

Some apps need different styles. Your marketing site might use larger headings than your product, for example. In UI Rules, each connected app inherits your brand's styles and rules. You can then change values for that app without changing the shared brand or the other apps using it.

For brand managers

Brand managers can use the same approach for language and assets.

Voice and tone. Give tools guidance for the words they write, including button labels, error messages, and onboarding. Be specific about what your voice means in practice. For example: "In error messages, explain what happened and what the person can do next. Avoid jokes." Group these rules by the kind of content they apply to.

Logo and brand assets. Upload your logo and add guidance for clear space, placement, and suitable backgrounds. This gives connected tools access to the asset you want them to use and instructions for presenting it correctly.

You'll still need to review the output. The benefit is that your guidelines are available while the tool is creating the work, rather than only being used to explain corrections afterward.

Where to start

Start with one app and the guidelines you find yourself repeating most often:

Get your real values in. Import your existing theme rather than typing every value in by hand.
Write the guidelines you repeat most often in design reviews. Mark genuine requirements as Required, and use Recommended or Optional for preferences. The rules guide explains how to write and organize them.
Connect one tool and one project. See what comes back, then write rules for whatever it still gets wrong.
Add your voice guidelines and logo usage rules so the tool has guidance for both the words and the visuals.

Build a screen, review it against your guidelines, and note what still needs attention. Use that review to clarify your rules. You don't need to document every possible situation before you begin; start with the decisions your team is already making repeatedly.

How to use your brand styles in AI coding tools

Hamish O'Neill — Mon, 07 Sep 2026 06:39:50 +0000

Part of a series on keeping AI tools on brand with UI Rules. Watch the video version on YouTube.

You've already chosen your brand's colors, typefaces, and spacing. When you build with an AI tool, you want to use those same choices without having to describe them again in every project.

UI Rules makes your brand styles available to Cursor, v0, Lovable, Codex, Figma Make, and Claude Code. Import them from Figma, paste an existing CSS theme, or use a preset, then connect the apps your team uses. This guide covers those three import methods and how to use the styles in a build.

Design tokens are the values, rules are the guidance

If you've read the rules guide, here's how the two fit. Styles are your design tokens, the actual values: the color of your primary button, your background, your border color, the typeface for body copy and headings. Rules are the brand guidelines that say how those values get used.

A color value tells a tool which color to use. A rule explains where it belongs. Your primary color, for example, might have a rule saying to reserve it for the most important action on the screen. UI Rules lets you keep that guidance alongside the value.

What a new brand starts with

A new brand starts with neutral colors and standard typography. You can use these as a starting point, then replace them with your own styles. Choose an import method based on where your design system lives today.

Import design tokens from Figma

If your colors, spacing, and other styles are stored as Figma variables, you can import them with the UI Rules plugin. Create a Figma key in UI Rules, install the plugin from the Figma Community, and use the key to connect your brand. Choose the variable collections you want to import, review the preview, and apply.

Open your brand in UI Rules to review the imported values. The plugin brings across the collections you selected, including light and dark modes, so you don't need to enter each value by hand.

Paste your CSS variables

If your styles are already in your website's code, ask a developer for the CSS theme and paste it into UI Rules. CSS variables are named values for things such as colors and fonts. If you need to create a theme, tweakcn is a quick way to build a theme: enter your brand values or start from one of its presets, and paste the CSS it produces.

Paste a preset code

A preset is a shareable code for a complete theme. These presets work with shadcn, an open-source collection of interface components such as buttons and cards. You can create one at ui.shadcn.com/create or shadcncraft.com/create, or grab a ready-made one, and paste the code in.

Whichever route you take, UI Rules previews the import before anything is written, so you can see exactly what will change.

Use your styles in a connected AI tool

Connect your chosen app to your brand, then ask it to read your UI Rules styles before building a screen. The same approach works with Cursor, v0, Lovable, Codex, Figma Make, and Claude Code. The worked example uses v0, where the project starts with the brand's colors, typography, and corner radius.

When a style changes, update it in UI Rules. The new value is available the next time a connected tool reads your brand. You still need to review the result, and existing screens won't change on their own, but you no longer need to maintain a separate copy of your styles for each tool.

Start with the styles you already have, then connect the AI app you use most. You can connect more apps to the same brand as your team needs them.

How to share your design system rules with AI coding tools

Hamish O'Neill — Mon, 07 Sep 2026 06:39:13 +0000

Part of a series on keeping AI tools on brand with UI Rules. Watch the video version on YouTube.

When you ask an AI tool to build a form, you want it to use the guidelines your team has already agreed on: where labels go, how buttons are written, and what happens when something goes wrong. The tool needs those guidelines to make decisions that fit your system.

UI Rules connects your design guidelines to Cursor, v0, Lovable, Codex, Figma Make, and Claude Code. You write and organize your rules in one place, and each connected tool can read them as it builds. This guide shows how to create and manage those rules, with a worked example in Claude Code.

What a design rule actually is

A rule describes a design decision you want your tools to follow. It can be as simple as a sentence, with a type and importance level to clarify how it should be used. You can also add a heading and explain the reason behind it.

The rule itself, short and single-purpose: "Never use a placeholder as the label."

A type. Do and Don't are instructions. Caution is a warning a tool should weigh. Info is context worth knowing rather than something to enforce.

A heading makes the rule easier to find. A rationale explains why it matters. For a rule about form labels, you might write: "Placeholder text disappears when someone starts typing. Keep the label visible so they can check what the field is asking for." That explanation helps both your teammates and your AI tools understand the decision.

Importance tells the tool how strongly to prioritize the rule. Choose Required for a requirement, Recommended for your usual approach, or Optional for a preference. These labels communicate your intent; you should still review what the tool builds.

Design guidelines you get out of the box

When you create a brand, you can start with curated guidelines or write your own from scratch. The curated set includes guidance for colors, components, accessibility, and content. Review it against your own system, keep what fits, and edit the rest.

Rules can apply broadly or to a specific part of your system. A general color rule might explain when to use color for emphasis. A rule attached to your primary color can be more specific: "Use this for the single most important action on the screen." Components such as buttons have their own guidelines too.

Writing and editing design system rules

Open an existing rule to edit it, or add a new one. For example, if your brand uses uppercase button labels, write "Use uppercase for all button labels" and set its type to Do. Add a heading and rationale if they're useful, then save. The updated rule is available the next time a connected tool reads it.

Group related rules together and reorder them so they're easy to review. Once you're happy with a rule, you can lock it to protect it from edits.

Try your rules in a connected AI tool

You can try this with any of the supported apps once you've connected it to your brand. For this example, I used Claude Code. With the uppercase rule saved, I asked:

Create a simple alert that shows I'm running out of disk space. Be sure to include some buttons.

Claude Code read the rules from UI Rules and built the alert with uppercase button labels. I hadn't mentioned capitalization in the prompt. It's a small example, but it shows how a guideline you've written can inform the result without being repeated in the request.

To try this yourself, create a brand in UI Rules, add a few guidelines, and connect the app you already use. The connection guides cover Cursor, v0, Lovable, Codex, Figma Make, and Claude Code.

The best shadcn/ui libraries in 2026

Hamish O'Neill — Fri, 31 Jul 2026 05:41:54 +0000

Last updated July 31, 2026.

Somewhere in 2025, shadcn/ui stopped being a library and became an ecosystem. There are now dozens of registries built on top of it, and figuring out which one to pay for is harder than it should be. Most comparison posts don't help. They're either forty links with no opinion attached, or five links where the author somehow comes out on top.

I build shadcncraft. It's in this list and it comes first, so let me put my cards on the table. I'm a design leader with over 25 years of experience. I've worked in some of the top agencies in Melbourne, Australia, along with leading organizations like carsales and ANZ Bank. A lot of what follows is judgment about design quality, and you should know whose judgment it is: I know what good looks like. Every number in this post is attached to a page you can open. The opinions are mine and I stand behind them.

TL;DR

If a designer and a developer both touch your product, get shadcncraft. It's the only library where every block exists in both Figma and React with matching names, so the design file and the codebase stay the same thing. If you're a developer working alone and you just need volume, get Shadcnblocks.

By category:

Best overall: shadcncraft
Best Figma to code parity: shadcncraft
Largest block library: Shadcnblocks, 1780 blocks
Largest Figma kit: Shadcn Studio, 800+ Pro blocks
Best open source: ReUI, 1,000+ free components and examples
Best for marketing sites: Tailark
Best for motion: beUI
Best for interaction detail: chanhdai.com
Best for advanced application components: Kibo UI

How I evaluated these

Six things, same for everyone. How many blocks and components there are, and whether they're new work or restyled shadcn primitives. Whether there's a Figma kit and how much of the code library it covers. Whether design and code share names and tokens or a human translates between them. Ecosystem support, meaning CLI, registry, MCP, Base UI, and how current it is with upstream. Tooling. Price at list, not whatever sale is on this week.

Best overall: shadcncraft

shadcncraft.com · 245 blocks · 116 components · 11 page templates · $119 to $499, one time

I'll skip the part where I pretend to be neutral about my own product and just tell you what it does differently.

The case for shadcncraft isn't volume. Three libraries in this list have more blocks. The case is that everything exists twice, in Figma and in React, and the two halves actually know about each other. All 245 blocks have a matching Figma frame whose layer names are the React data-slot values. That sounds like trivia. It stops being trivia the first time you point an AI tool at a design, because an agent reading the frame through the Figma MCP can tell exactly which registry block it's looking at and install the real thing instead of generating a lookalike from a screenshot.

Theming runs in both directions, which nothing else here does. Build a theme in shadcn Create, paste the preset into the Figma plugin, and it's recreated in variables exactly. Or build it in Figma and carry the preset back to your codebase. tweakcn themes layer over any of the eight shadcn styles. Most kits drift from their codebase within a month of purchase because themes only flow one way, if they flow at all.

Icons get the same treatment. Five sets, Lucide, Tabler, Hugeicons, Phosphor, Remix. Switch them from Figma's variables panel, and the registry reads your components.json and installs React blocks with whichever set you picked. Plenty of kits let you swap icons inside Figma. This is the only one where your choice survives the handoff to code.

There are two component bases, Radix UI and Base UI, which makes sixteen style and base combinations. Base UI landed here on April 26, a couple of months before shadcn/ui made it the default.

On quality, since everyone in this list claims it: open any block on the site. They're all live. Switch the style, the base, the theme, the icon set, flip to dark. Then open the matching Figma frame from the same page and compare. Judge it yourself.

What's in each tier. Base Figma is the official shadcn/ui set in Figma with all 8 styles and the Figma plugin for styles, themes and presets. The Pro tiers add the 192 Pro blocks, 55 Pro components, and the Pro pages and sites: in Figma on Pro Figma, in React on Pro React, and in both on the bundle. Pro React is code-only, so no Figma kit and no plugin, but it steps the agent skills up from token sync to full Figma-to-code and adds an offline Storybook build alongside the public one. The bundle gets everything, including React generation inside the plugin itself. Every tier has lifetime updates, unlimited commercial use, and support within 24 hours on Base and 12 hours on the Pro tiers. Upgrades are self-service and you pay only the difference between tiers, so starting on Base costs you nothing later.

Where it falls short. It's a smaller library, and if breadth is what you're buying, buy breadth. The 11 page templates are full multi-section layouts, dashboards, settings, auth flows, but they're Figma only. No React equivalent for pages, just for the ClearFlow site. There's nothing for motion or animation. And there's no IDE extension or page builder yet.

Free tier: a starter kit on the Figma community, plus 8 blocks and 16 components in the registry, no license key.

Largest block library: Shadcnblocks

shadcnblocks.com · 1780 blocks · 1914 components · 49 pages · 17 templates · $149 to $399, one time

Credit where it's due. Nothing else is close on volume, the pace is real, roughly 50 to 100 new blocks a month since launching in August 2024, and the tooling around the library is the best in the ecosystem. IDE extension, browser page composer, CMS boilerplates for Payload and Sanity, an admin kit. The catalog runs across marketing, app UI and e-commerce, and the templates are genuinely multi-page in both Next.js and Astro. 5,420 people pay for it. If you're a developer who wants the widest menu available and tooling that keeps up with you, this is the default, and I won't pretend otherwise.

Where it falls short. The design. To be precise: this isn't about the code, it's about what's on the canvas. Weighting, spacing, typographic hierarchy, horizontal and vertical rhythm. Browse the library with those in mind and the blocks read as produced rather than designed. Elements sit where a generator or a developer doing their best would put them, not where a designer would. Which makes sense, because this is a developer-led product. And that's the trap: developers deserve good design too, they're just less likely to spot where it's missing until their product is live and something feels off next to a competitor's. If you're buying this, you're buying volume. Know that going in.

The Figma side has a gap you can count. 484 block designs in the kit against 1780 blocks in code, and their own pricing FAQ says it doesn't yet contain all the block designs. For about three quarters of the library, a designer has nothing to work from. Figma also starts at the $299 tier, not the $149 one.

Largest Figma kit: Shadcn Studio

shadcnstudio.com · 800+ Pro blocks in Figma · 1000+ component variants · $219 to $1299, one time

The biggest Figma kit by count, and the widest toolset of any paid option here. MCP, IDE extension, theme generator, drag and drop builder, a Figma plugin with AI codegen. Figma Slots, which let you swap section content without detaching instances, are a genuinely good idea that more kits should steal. There's a free open source tier, so you can read the code before paying anything.

Where it falls short. Same caveat as above: this is about the design, not the code. Look at the blocks the way a design reviewer would, at the type scale, the spacing, how a section hangs together, and a lot of the catalog looks AI-generated. Not wrong, just generic, the way a first pass looks before someone with taste has been through it. Like Shadcnblocks, this is a developer-led product, and at 800+ blocks, that first-pass look is what you should expect going in.

A few practical things too. Figma is gated to the $359 tier, the most expensive route to a kit in this post. Their block count reads 800+ on their own site and 550+ on their entry in shadcn's Figma docs, so one of those is stale. And the pricing page has been running a "30% off for the next 500 users" banner long enough that I'd treat the list price as decorative.

Best open source: ReUI

reui.io · 1,051 free components plus 20 in-house primitives · 492+ Pro blocks and templates, paid, one-time

The widest free coverage there is, and the free tier is not a teaser. The in-house primitives, data grid, Kanban, Gantt, event calendar, filters, stepper, tree, are free, on both Radix and Base UI, from a public registry with no auth wall. If your budget is zero and you need application components rather than marketing sections, start here. The paid side, 492+ Pro blocks across SaaS, dashboards, fintech and e-commerce, sits on the same foundation if you outgrow it.

Their MCP deserves a mention on its own. Hosted, free with an account, and it does things most registry MCPs don't bother with: search that tells you why a result matched, a tool that reads real component APIs so the agent wires props from documentation instead of guessing, validation before code gets written. If an agent does most of your assembly, that's worth something.

Where it falls short. Breadth without much of a design voice, which is the usual price of open source at this scale. And the Figma side is a community file rather than a maintained kit, so there's no real design story.

Best for marketing sites: Tailark

tailark.com · hundreds of blocks · complete pages in 4 styles · core free and open source, Pro in early access at pro.tailark.com

The best answer to a very specific worry, which is that your landing page will look like every other shadcn site on the internet. The design language is deliberately more bespoke than the default, and the four themes hold a whole site together without you re-tweaking each section. Radix and Base UI both supported. The core is free, so you can form your own view before paying for Pro.

Where it falls short. No Figma. Marketing surfaces only. And the pages carry less production functionality than they appear to at first glance.

Best for motion: beUI

beui.dev · 51 free MIT components · Pro adds 17 block groups and 5 templates

Ships roughly a component a day, and made the unusual call to drop the shadcn and Radix dependency entirely, so everything is standalone and sits beside whatever you already have. Listed in shadcn's official registries index. beUI Studio, a WebGL background editor with 23 shaders that exports React source, has no equivalent anywhere else in this list.

Where it falls short. No Figma, no team or enterprise licensing, and no license or refund page that I could find at time of writing. It's one person's project. Set your support expectations accordingly.

Best for interaction detail: chanhdai.com

chanhdai.com · 36 components · MIT · free

Disclosure first: Chánh Đại is shadcncraft's design engineer, which is exactly how I know this work well enough to point you at it.

This is craft, not catalog. Thirty-six components built to a standard most libraries don't attempt. And the endorsements aren't mine to hand out: shadcn, Vercel's CEO and Vercel's founding designer have all praised it publicly, it's backed by the Vercel OSS Program, and his React Wheel Picker does 30k+ weekly downloads and sits in the official shadcn registry.

Where it falls short. It's 36 components. A supplement, not a foundation.

Best for advanced application components: Kibo UI

Kanban boards, Gantt charts, timelines, complex data visualization. The components most libraries skip because they're hard, and that most SaaS products end up needing at least one of. Narrow on purpose, and no Figma.

FAQ

What is the best shadcn/ui library in 2026?

Depends whether a designer is involved. If yes, shadcncraft, because all 245 blocks exist in both Figma and React with matching names, which is what makes handoff and AI codegen work rather than approximate. If you're a developer working alone and want the largest catalog, Shadcnblocks, which covers marketing, app UI and e-commerce.

Which shadcn library has the most blocks?

Shadcnblocks, with 1780. Shadcn Studio has 800+ Pro blocks. shadcncraft has 245, and Tailark's core has hundreds more, all marketing-focused.

Which shadcn library has the best Figma kit?

Shadcn Studio is the largest by count. shadcncraft is the most complete relative to its own code library, since all 245 blocks have a matching Figma frame. Shadcnblocks ships 484 Figma designs against 1780 blocks in code, a gap its own pricing FAQ acknowledges. Tailark, beUI, ReUI and Kibo UI have no maintained Figma kit.

Which shadcn library has real Figma to code parity?

shadcncraft. Figma layer names match React data-slot values, so an agent reading the Figma file resolves frames to real registry components and installs them instead of generating approximations. Shipping a Figma kit is not the same thing as parity, and the difference shows up the moment you point an AI tool at the file.

Which shadcn library works best with AI workflows?

shadcncraft on the design side: agent skills for Claude Code, Cursor and Codex, MCP-ready blocks, Figma to React through the plugin, and an offline Storybook build agents can read locally. ReUI on the code side, with a hosted MCP that reads real component APIs and validates props before code is written. Different halves of the same problem.

Which shadcn library lets you switch icon libraries?

shadcncraft, across five sets: Lucide, Tabler, Hugeicons, Phosphor and Remix. They switch from Figma's variables panel, and the registry installs React blocks with the matching set, so the choice made in design reaches the codebase. Sitsiilia's free shadcn/ui create plugin also switches icon sets inside Figma, but there's no paired registry on the code side.

Which shadcn libraries support Base UI?

Shadcnblocks was first, on February 5, 2026. shadcncraft followed on April 26, two months before shadcn/ui made Base UI the default on July 3. Shadcn Studio, ReUI and Tailark support both. shadcn/ui also added React Aria as a third first-class base in July, and nothing in this list supports it yet.

Which shadcn library is best for dashboards and application UI?

Most of the ecosystem is marketing-heavy. For application surfaces: ReUI for free coverage including data grids and Kanban, Kibo UI for Gantt and timelines, shadcncraft for dashboards and data tables with matching Figma, Shadcn Studio for its dashboard and app shell layouts.

Are there free shadcn libraries?

More than people expect. ReUI, chanhdai.com, Tailark's core and beUI's core are open source. Shadcn Studio has a free tier. On the Figma side, Obra's free community kit is the largest by a wide margin, and shadcncraft has a free starter kit plus 8 blocks and 16 components in the registry, no license key.

shadcncraft vs Shadcnblocks: which should I buy?

They're optimized for different buyers. Shadcnblocks has 1780 blocks against shadcncraft's 245, the best browsing and install tooling in the ecosystem, and a faster release pace. shadcncraft has complete Figma coverage (all 245 blocks have a matching frame, against 484 of 1780), two-way theme sync between Figma and code, and layer names that match React data-slot values so AI tools resolve designs to real components. Developer working alone who wants the biggest catalog: Shadcnblocks. Designer and developer working together, or an AI-assisted design-to-code workflow: shadcncraft.

Do these libraries lock me in?

No. They all ship source into your project through the shadcn CLI, so you own the code and can mix libraries freely. What you inherit is the maintenance. Check GitHub activity and Tailwind v4 compatibility before adopting anything.

Bottom line

If a designer and a developer are both working on the product, pick for parity. The translation layer between Figma and code is where the time actually goes, and most kits don't have one. That's shadcncraft. Yes, I built it. That's also why every number above is one you can check without asking me.

Developer working alone who wants the biggest catalog: Shadcnblocks. Budget of zero: ReUI. Marketing site that doesn't look like every other shadcn site: Tailark. Motion: beUI.

Claude Cowork has changed managing a Figma design system library forever

Hamish O'Neill — 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

Hamish O'Neill — 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

Hamish O'Neill — 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

Hamish O'Neill — 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

Hamish O'Neill — 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)

Hamish O'Neill — 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.

DEV Community: Hamish O'Neill

How to manage your design system with the UI Rules Agent

Review every design system change before it lands

Write design guidelines by describing the change

Control what your AI tools can see

Add your logo alongside its guidelines

Refine rules and scan your website with Pro

Where to start

How to keep AI aligned to your design system

Keep accessibility and usability decisions in the build

Make your documentation available to AI tools

Markdown files and Notion pages get out of sync

It gets worse with a team

One place your tools read from

Write rules that explain what matters

Guidelines for your components

Give your tools access to current guidelines

For brand managers

Where to start

How to use your brand styles in AI coding tools

Design tokens are the values, rules are the guidance

What a new brand starts with

Import design tokens from Figma

Paste your CSS variables

Paste a preset code

Use your styles in a connected AI tool

How to share your design system rules with AI coding tools

What a design rule actually is

Design guidelines you get out of the box

Writing and editing design system rules

Try your rules in a connected AI tool

The best shadcn/ui libraries in 2026

TL;DR

How I evaluated these

Best overall: shadcncraft

Largest block library: Shadcnblocks

Largest Figma kit: Shadcn Studio

Best open source: ReUI

Best for marketing sites: Tailark

Best for motion: beUI

Best for interaction detail: chanhdai.com

Best for advanced application components: Kibo UI

FAQ

What is the best shadcn/ui library in 2026?

Which shadcn library has the most blocks?

Which shadcn library has the best Figma kit?

Which shadcn library has real Figma to code parity?

Which shadcn library works best with AI workflows?

Which shadcn library lets you switch icon libraries?

Which shadcn libraries support Base UI?

Which shadcn library is best for dashboards and application UI?

Are there free shadcn libraries?

shadcncraft vs Shadcnblocks: which should I buy?

Do these libraries lock me in?

Bottom line

Links

Claude Cowork has changed managing a Figma design system library forever

What this is, in one paragraph

Two customer pain points this directly solves

What Cowork is genuinely great at

Variable management, rebinding, and managing states

Auditing collections and detecting drift

Writing Figma plugins for you

What Cowork cannot do

It cannot "see" your file

It cannot order your variables

It is happy to confidently break things at scale

The workflow rules that make it work

Do small, specific, scoped tasks

Chunk down large tasks

For big repetitive jobs, ask for a plugin

Store reference files in the project folder and point the agent at them

Keep a CLAUDE.md in the project folder

Get it to validate its own work

Make regular backups in Figma version history

Plan for token cost

Three new workflows worth knowing about specifically

Drift detection against your code-side tokens

Per-variable reference docs generated from the live Figma file

Custom plugins for your most repetitive jobs