The Claude Code design skill arrived as a research preview this week: run it, get your UI drafted as editable artboards, pick a direction, adjust, hand it back to be implemented. Available on Pro, Max, Team and Enterprise.
The demo is the artboards. Read the documentation and something more useful appears, which is that the artboards are not the hard part and Anthropic has already shipped the thing that is. If you are new to the tool itself, our explainer on Claude Code covers the permission model everything here runs inside.
The Claude Code design skill is not in the documentation
Worth being precise here, because the gap is itself informative.
Anthropic’s commands reference lists bundled skills alongside built-in commands. As of writing, it does not contain a /design entry. Neither does the skills documentation, and there is no design or artboard page in the documentation index at all.
What the commands reference does contain is two closely related entries:
/design-sync, described as "Convert your repo’s React design system and upload it to Claude Design, so designs it produces use your real components."
/design-login, described as "Authorize design-system access for /design-sync with your claude.ai account."
So the supporting infrastructure is documented and the headline feature is not. That is normal for a research preview and it is not a criticism. It is also, if you read it closely, a fairly complete description of how the thing works.
/design-sync is the load-bearing part
Read that description again with the emphasis in a different place: "so designs it produces use your real components."
That clause is the entire difference between a useful tool and a slide deck. Anything can generate a plausible interface. The reason design-to-code has failed repeatedly for two decades is not that machines cannot draw rectangles. It is that the drawn rectangle has no relationship to the button component that actually exists in your repository, with your spacing scale, your variants, your states and your accessibility behavior. Implementation then becomes translation, and translation is where the time goes.
/design-sync is the step that closes that loop. It converts the design system you already have and uploads it so the generated output is expressed in your vocabulary rather than a generic one.
It says React, and that matters
One word in that documentation line does a lot of scoping work: "your repo’s React design system."
That is what is documented. It is not a statement that other frameworks are unsupported, and a research preview may well broaden. But if you are building in Vue, Svelte, Angular, Blade or a server-rendered PHP theme, the component-fidelity half of this is not currently described as covering you. You can still generate artboards. What is not documented is the part that makes them map to your code.
For agencies in particular, that is a portfolio question rather than a preference question. A shop whose work is mostly WordPress and Blade templating gets a different tool from this than a shop standardized on a React component library, and the difference is not one you would discover from the announcement.
Uploading your design system is a decision
"Upload it to Claude Design" is doing something specific, and /design-login confirms it: authorization is a separate step, tied to a claude.ai account, and scoped to design-system access.
A design system is not usually secret in the way credentials are. It is also not nothing. It encodes unreleased product direction, client work under NDA, brand assets with licensing terms, and in many agencies, the actual differentiating asset of the business. Uploading it somewhere is a decision that deserves to be made deliberately rather than absorbed as a setup step.
None of that is an argument against doing it. It is an argument for knowing you did it, and for checking the terms if you work under client agreements that say where their materials may go. Agencies should assume a client will eventually ask.
Because it is a skill, it behaves like one
The mechanics here are documented, and they answer several practical questions the announcement does not.
Bundled skills are "prompt-based: they give Claude detailed instructions and let it orchestrate the work using its tools," rather than executing fixed logic. You invoke one by typing / and the name. Notably, "Claude invokes some bundled skills automatically when relevant," while others run only when you ask, and the docs give /verify as an example of the second kind precisely because longer-running work should stay under your control.
Bundled skills are available in every session and can be turned off with the disableBundledSkills setting, which disables all of them except /doctor, or individually through skillOverrides. If you administer Claude Code for a team and do not want design-system uploads happening ad hoc, that is where the lever is.
They also follow the Agent Skills open standard, which Claude Code extends with invocation control, subagent execution and dynamic context injection. That is worth knowing because it means a skill is a portable artifact rather than a proprietary feature, a point we covered when looking at what AI skills actually are.
What "research preview" is telling you
This publication has spent the past fortnight tracking a specific pattern: capability shipping ahead of the tooling that would let anyone evaluate it. Text watermarking arrived before any detection API existed. Vendor benchmarks arrive before independent replication.
A research preview whose headline command is not yet in the documentation is a mild version of the same shape, and the appropriate response is neither cynicism nor enthusiasm. It is to note that behavior may change without a changelog entry, that the surface is not yet stable enough to build a team process around, and that anything you learn this month may not hold next month.
The counterweight is that the plumbing being documented first is genuinely reassuring. /design-sync and /design-login existing as described suggests the component-fidelity problem was designed for rather than deferred, which is more than most entrants in this category have managed.
Whether to try it
Five positions, in the order I would take them.
Run the sync before you judge it. Testing the Claude Code design skill on a cold repo tells you about a drawing tool. The interesting question is whether the output lands in your components, and you cannot answer that without /design-sync.
Check your framework before you plan around it. The documented path is React. If you are not on React, treat the component round trip as unproven for your stack rather than assuming it generalises.
Decide the upload question at the team level. Once, deliberately, with whoever owns client agreements. Not per developer, per repo, in the middle of a task.
Expect it to move. Undocumented and in preview means the surface can change. Do not build a documented internal workflow on it yet, and do not let it become load bearing in a client deliverable.
Judge it on implementation, not on the pictures. The output that matters is the code that comes back after you hand the chosen direction over, running in a real app. That is the same standard we applied to where Claude Code actually executes, and it is the only test that distinguishes this from the last five tools that promised the same thing.
Frequently Asked Questions
What does the Claude Code design skill do?
Per Anthropic’s announcement, it drafts your UI as editable artboards inside the terminal or the desktop app. You choose a direction, adjust it until it is right, then hand it back to Claude Code to implement. It is described as a research preview available on Pro, Max, Team and Enterprise plans, and it requires an updated version of Claude Code.
Is it documented?
Not as of writing. The commands reference and the skills documentation contain no `/design` entry, and there is no design or artboard page in the documentation index. What is documented is the surrounding infrastructure: `/design-sync` and `/design-login`. Undocumented preview features are common and not alarming, but it does mean behavior can change without notice.
What is /design-sync?
A bundled skill documented as converting your repository’s React design system and uploading it to Claude Design “so designs it produces use your real components.” It is the step that connects generated output to the components that actually exist in your codebase, which is the part that historically determines whether design-to-code tooling saves any time.
Do I have to use it if I am not on React?
The documentation describes `/design-sync` in terms of a React design system. That does not necessarily mean other frameworks fail, and a preview may broaden its support. It does mean the component-fidelity path is currently only documented for React, so teams on Vue, Svelte, Angular or server-rendered templates should treat that half as unproven for their stack until it is stated otherwise.
Where does my design system go?
It is uploaded to Claude Design, and `/design-login` exists specifically to authorize design-system access with your claude.ai account. Whether that is acceptable depends on your circumstances, particularly under client agreements that constrain where materials may be sent. It is worth deciding once at team level rather than leaving it to whoever happens to run the command first.
Can an administrator turn this off?
Bundled skills as a category can be disabled with the `disableBundledSkills` setting, which turns off every bundled skill except `/doctor`, and individual skills can be hidden through `skillOverrides`. That is the documented control surface for bundled skills generally. If your concern is design-system uploads specifically, that is where to look.
Is this the same as other AI design tools?
The generation part is not unusual. What is different is the documented attempt to close the loop back to real components in a real repository, and the fact that drafting and implementation live in the same tool rather than requiring an export. Whether that produces better results than a design file plus a separate implementation step is exactly what the preview period should establish.
Should we adopt it now?
Try it, do not standardize on it. A research preview with an undocumented command is not a stable base for a team process or a client deliverable, and behavior can change between versions. Running the sync and evaluating whether the returned code lands correctly in your components is a genuinely useful experiment to run now; writing it into how your team works is premature.
