Claude Design can draw with your real components

Ask an AI design tool for a screen and it draws a button that only looks like yours, built from hand-picked classes like px-4 py-2 rounded bg-blue-600, so a developer has to rebuild every piece, as a step-by-step guide on Nitayneeman points out. The fix it walks through is /design-sync, a Claude Code command that compiles your real component library into a mirror Claude Design builds with.

At a glance

• Running /design-sync in Claude Code bundles your components, stylesheet, fonts and a copy of React into a self-rendering mirror, then uploads it to Claude Design once you approve.
• Before uploading, Claude screenshots each preview in Chromium and grades it against the matching Storybook story as match, close or mismatch; in the guide's test, all nine stories came back as match.
• The mirror is a one-way snapshot: nothing changes in Claude Design until the next sync, and even a re-sync may leave a component you deleted from the library sitting in the mirror.

If you haven't tried it, Claude Design is Anthropic's design tool inside Claude. It turns a plain-language prompt into a screen, a prototype, a slide deck or a one-pager, either on a canvas at claude.ai/design, in a regular conversation or through /design in Claude Code. Out of the box, it doesn't know your design system: the React components, the tokens and the typography already in your code. The sync is how you hand those over.

The mirror carries a compiled bundle, not your source files

The mirror holds no source code. It is one compiled bundle with every component, plus the stylesheet, the fonts and a copy of React, so the components can run on their own. Each component also gets a small folder with its types, so Claude knows which props and variants exist, a standalone preview page shown as a card in Claude Design, and a generated usage guide. On top sits a README with your own usage rules.

After you approve the upload, the mirror appears under Settings > Design systems, and Claude can use it in any conversation, Claude Code included. On Pro and Max it stays personal. On Team and Enterprise, publishing makes it the organization's, and Enterprise admins can limit who publishes, set the organization's default or delete it. Getting a finished design back into code is a separate flow through /design.

Storybook turns a self-graded check into a side-by-side comparison

The sync reads its settings from a .design-sync/ folder, opens each preview in a real browser, takes a screenshot and grades it. Without Storybook, every component starts as a placeholder card with nothing to compare against. In that case the sync catches only obvious faults, such as a blank preview, a nearly empty one or variants that all look the same, and then Claude grades each card against a rubric for you to review.

With Storybook, the stories become both the previews and the reference. By default the sync captures up to six stories per component, and Claude compares each preview with its matching story, grades it match, close or mismatch, and fixes what it can before upload. A close is not a pass. Compare proofreading a copy against the original manuscript with reading it cold and hoping the typos jump out.

Three shadcn components produced nine stories, all graded match

The guide's example is deliberately small: a Vite project with React and TypeScript, Tailwind v4 installed as a Vite plugin, and three shadcn/ui components, Button, Card and Input. shadcn doesn't create a single entry file, so the guide writes src/index.ts by hand to re-export the three components and the cn() helper. A component missing from that file never reaches Claude Design, and nothing warns you.

The sync also finds components through their type definitions, generated into dist/index.d.ts. Without them it finds nothing and drops every story. Story titles must match the exported name, so Button and not Buttons. Storybook's preview.tsx needs one import of src/index.css added by hand, because otherwise the reference screenshots come out unstyled too and a passing grade proves nothing.

With Playwright and Chromium installed for the screenshots, all nine stories came back as match. If Claude Code's Bash sandbox is on, it blocks the local server and the browser, and /sandbox turns it off for the run. When asked for a sign-in screen, Claude Design built it from Card, CardHeader and Button variant="outline" instead of hand-rolled divs.

Styles, layout classes and fonts each need their own route into the mirror

Previews in Claude Design need a real CSS file. Storybook with @tailwindcss/vite doesn't produce one, so the guide compiles ds.css with the Tailwind CLI. Token imports matter here. Tailwind v4 inlines a string @import but leaves a url() import as an external reference, which breaks after upload and makes every shadcn component arrive unstyled.

The compiled file holds only the utilities found in your sources. Three components scan to a couple of hundred classes. That covers the components but not the layout Claude writes around them, like grid-cols-3, gap-6 or max-w-4xl. Tailwind v4.1's @source inline(...) generates utilities from patterns instead, and an empty option in {sm:,md:,lg:,} yields both gap-6 and md:gap-6.

Fonts imported from CSS point into node_modules and get lost in the upload. So shadcn's Geist font goes into extraFonts, and the sync copies the woff2 files and rewrites the @font-face rules. A conventions file adds rules such as using variant and size instead of hand-styling. Without it, Claude can render a correct Button and still write className="bg-blue-600 px-4".

Oddly, even a re-sync doesn't always clean up: a component you delete from the library may stay in the mirror, so the guide suggests checking the file list yourself. The grading admits its own limits too. Claude may judge only each component's primary story and trust the rest, it can't tell that a perfect screenshot of a closed dropdown shows the wrong state, and a variant without a story arrives unchecked.

What the next /design-sync touches

Every code change waits for the next /design-sync. Thanks to the projectId saved after the first run, that sync updates the same design system instead of creating a new one. The guide doesn't say whether stale components will ever be removed automatically. If you keep a separate CSS entry for the sync, diff it against Storybook's before each run: a new @layer base rule in the original leaves the copy rendering the old design without any warning.