Claude Design to Claude Code: the handoff bundle explained

Most design-to-code handoffs are translation problems. A design tool describes a rectangle, and something on the other side has to guess whether that rectangle was meant to be a card, a section or an accident.

Claude Design does not have that problem, and the reason is structural: the thing that made the design and the thing that writes the code are the same model. The handoff is the shortest one currently shipping. It is worth understanding what that closeness actually buys, because it is not everything.

What Claude Design is, precisely

It is a canvas for visual work — prototypes, wireframes, design explorations, decks, one-pagers, microsites — from Anthropic Labs. It can read an existing codebase to extract a design system and generate new interface work that matches your product rather than the statistical average of all products.

Three constraints belong at the top, because they decide whether any of this is available to you:

• It is in research preview, available to Claude Pro, Max, Team and Enterprise subscribers.
• For Enterprise organisations it is off by default and requires an administrator to enable it.
• It draws on your existing subscription limits rather than being separately metered.

If you are on a free plan or waiting on an enterprise admin, the rest of this is reading for later.

The handoff bundle

The intended route is not an export at all. When a design is ready to build, Claude packages the work into a handoff bundle that you pass to Claude Code with a single instruction.

The distinction from a file export matters. A PNG or an HTML file is an artefact that has to be interpreted — the receiving agent reconstructs intent from the output. A bundle is assembled by the thing that made the design, while it still has the reasoning in context. There is no lossy step in the middle, because there is no middle.

It also runs in both directions. The /design command works inside Claude Code, and /design-sync moves work between the two, so the design need not be the first step. You can build first and design against what exists, which is closer to how most product work actually happens.

The routes out to somewhere else

Claude Code is the tightest path but not the only one. A design exports to PDF, PPTX or standalone HTML, shares as an org-scoped link, or saves as a folder. Connectors cover Adobe, Base44, Canva, Gamma, Lovable, Miro, Replit, Vercel and Wix.

Claude Code

The bundle, and the only route where nothing is reconstructed from an artefact. Use /design to work from the terminal, or /design-sync to move a piece of work between the two without either becoming the sole source of truth.

Lovable and Replit

Both are connectors, which makes this the shortest path into either that currently exists. Worth contrasting with the other direction: Lovable is not in Figma's MCP catalog, so getting a Figma file into it means going through the Builder.io plugin and accepting a one-time snapshot. Originating the design in Claude Design skips that entirely.

Vercel and Wix

Deployment-shaped destinations rather than agent-shaped ones. Useful when the design is the deliverable — a landing page, a microsite — and there is no ongoing codebase for it to become part of.

Canva, Adobe, Miro and Gamma

Sideways moves into other document tools, for when the work continues as a deck or a board rather than as software. If it then has to come back toward code, the Canva route is the relevant one, and it is a considerable step down in fidelity from where you started.

Anything else

Standalone HTML is the honest export. It is a real rendering with the structure intact, which is more than a flat image gives an agent and less than a bundle assembled with intent.

Where the closeness runs out

Here is the part worth thinking about, and it is not a criticism of the handoff — the handoff is excellent. It is a consequence of generation itself.

A Figma file has a durability problem in one direction: the file records what things look like and never records why. Claude Design has the opposite one. Ask it for a settings page on Monday and a billing page on Thursday, in two sessions, and it will make two defensible sets of decisions. Both will be competent. They will not necessarily be the same.

This is the correct behaviour for a generative tool and it is exactly what makes it fast. But it means the design system is being re-derived rather than consulted. Codebase extraction narrows the drift — it reads what you have built and matches it — and that inference is only as good as what is already there. On a young product, the second screen defines the system as much as the first, and neither of them was decided so much as arrived at.

The failure shows up later than the Figma one, and is harder to see. Nothing looks wrong. Each screen is internally coherent. It is only across six screens and three weeks that the accent starts appearing in two roles, the heading face acquires a second personality, and the empty states begin addressing a different reader than the errors do.

What has to exist outside the session

The fix is not a better prompt, and it is not more context pasted at the start of each session. It is a small set of decisions recorded once, in a form the model consults rather than re-derives.

Not many. Ten decisions honoured beat forty averaged out:

• The typefaces, and the sizes each one owns — including the ones it is banned from.
• The palette with a job per colour. #E8511E is a hex code; "#E8511E, primary action, never body text" is a rule, and a rule generalises to the screen nobody has designed yet.
• The spacing and motion numbers. "320ms ease-out" survives translation; "snappy" does not.
• Who the copy is written for, by name. See write your UI copy for one named customer.
• What you would never ship. Negative constraints do the most work per word, because they close off the defaults the model would otherwise reach for.

That is the argument in how to teach a coding agent your design taste, and it applies with more force here, not less. A tool that generates the design and the code will honour a strong opinion completely and the absence of one just as completely.

Where that record lives is the practical question. A short list of non-negotiables belongs in the file the agent already reads, and the rest behind a call it makes when a task touches type, colour, copy or brand — the split argued in where design rules belong. A few properties are worth insisting on in anything holding those decisions, and which moodspec's endpoint enforces: it is read-only, the token is scoped to a single canvas rather than an account, and an agent can only ever propose an edit through propose_change, which a person approves. The docs are one block of config.

The test

Open a fresh session with no preamble. Ask for a screen you have not designed yet — a settings page, a billing history, a failed-payment state.

Then put it beside something you made three weeks ago and check three things: is the accent doing the same job, is the heading face at the same size and tracking, and do the two empty states sound like they were written by one person.

If yes, the system is being consulted. If each is individually good and collectively a different product, it is being re-derived every time — and that gap widens with every screen, because nothing in the process is pulling them back together.

Further reading

• Introducing Claude Design — the announcement, availability and the handoff-bundle description
• Claude Design — the product page, with the connector list and the sync commands
• Claude Code memory — how CLAUDE.md loads, and why size affects adherence
• Model Context Protocol — the standard behind fetch-on-demand context