I build this site in Claude Code, and the design work around it always happened somewhere else. Colors and typography are pinned down in DESIGN.md, and everything else emerged in conversation: I described what I wanted, looked at the result in the browser, and adjusted. That works. What it never gives me is a moment where I see three directions side by side. I see one, the one the model reached for first.
On 17 August, Anthropic announced a /design skill for Claude Code, in research preview. You type /design, you get editable artboards for your UI, you pick one, you tweak it, and then Claude builds it. In the CLI and in the desktop app, built on artifacts.
That is the news. The mechanism underneath it is the better story, and it appears in none of the coverage I read.
What is actually new, and what is not
Claude Design has existed as a standalone product since 17 April 2026, then in research preview and powered by Opus 4.7. I wrote earlier about what it is and who it helps. It went to beta on 17 June, and I tested it that same day. That June announcement already said you could “begin in Claude Code” with /design. Last week’s announcement calls it research preview again, this time specifically for the artboard workflow in the CLI and the desktop app.
Those two descriptions do not contradict each other, but they do not line up either. I am sticking with the primary sources and recording both.
| Date | What was announced | Status |
|---|---|---|
| 17 April 2026 | Claude Design as a standalone product, on Opus 4.7 | Research preview |
| 17 June 2026 | /design-sync and /design in Claude Code, canvas editor, connectors | Beta |
| 17 August 2026 | Artboard workflow in CLI and desktop, on artifacts | Research preview |
Available on Pro, Max, Team and Enterprise. On Enterprise it is off by default; an admin turns it on in organization settings.
The plan boundary is the real story
Alongside /design there is /design-sync, and underneath that sits a tool I can inspect in my own session. It talks to your design system projects on claude.ai, and the order of operations is fixed:
- Read. List projects, list file paths, optionally read one file.
- Lock the plan. You commit to the exact list of paths you will write and delete, plus the local directory uploads may read from. That returns a
planId. - Write. Every write or delete has to carry that
planId, and every path has to be in the plan. A path outside it is rejected.
The user sees that path list and that source directory independently of whatever the model says about them. That is the whole point of the construction: the model cannot describe the list more favorably than it is, because you get the list itself.
Files go up by local path where possible, so their contents never pass through the model’s context at all. And the tool carries an explicit warning: a file you read back from the project was written by someone else in your organization, so it is data, not instruction. If it reads like a command aimed at the model, that is a signal something is wrong.
Hard limits: 256 KiB per file read, 256 files per write call. Larger bundles get split across calls under the same plan.
The cards in the Design System pane now come from a comment on the first line of each preview file rather than a separate registration step. The source of truth lives in your files, not in some index kept elsewhere.
The number, and the number that is missing
Anthropic reported that over a million people used Claude Design in its first week. That is a first-party count over the week following 17 April, and there is no definition of “used”: opening it once almost certainly counts. There is no retention figure, no count of designs that reached production, and no measure of how often an artboard survived to implementation.
The number that suits Anthropic less well sits in the same announcement, framed as an improvement: since June, Claude Design shares usage limits with chat, Cowork and Claude Code. That is presented as more headroom. It also means every artboard you generate draws on the same budget as your coding that day. Generate a dozen directions before you start building, and you build afterward with less.
The caveat
First, this moves where the design decision happens. A dozen directions in minutes sounds like more choice, but it changes the nature of the choice. Picking from what a model offered is not the same as working out what should be there. “Which of these four” is a more comfortable question than “what do we actually want here”, and the second one is what quietly disappears.
Then there is responsibility, which lands on a list of paths. The plan boundary is well designed, and at the same time your approval covers paths, not content. Approve 256 files in one go and you are approving the process, not the files. That is exactly the kind of approval that becomes reflex on the third repetition. The boundary protects against a model that oversteps. Not against a person who says yes too fast.
And what flows out is your design system. To make this work well, your brand DNA has to go in: colors, typography, components, and preferably your whole repository. That is company property, and it goes to one vendor that already reads your code. For me personally the tradeoff is manageable. For the organizations I work with during the day this is exactly where the conversation gets hard, and “an admin can switch it off” answers a different question than the one being asked.
What I am doing
I am not setting aside DESIGN.md and its sidecar. Those stay the source of truth for how sparkone.nl looks, and an artboard gets to propose, not decide. Concretely: the risograph treatment, the spot inks and the fixed 2px borders live in that file, and I am not pulling them back out of a canvas.
Nothing changes for the carousels I render for Instagram. Those stay HTML in my own directory, and I look at every rendered PNG with my own eyes before it goes anywhere. An artboard workflow does not take that over, because the mistakes that happen there are typesetting mistakes and no automated check catches those.
The seven design skills already in Claude Code keep doing what they did. They judge what exists; /design makes what comes next. Two different moments, and I would not blur them.
I am going to reach for /design at the point where I currently start building straight away, to see whether three visible directions make me pick something I would otherwise have skipped past. I will write down what comes of that, including the case where the answer is nothing.
Frequently asked questions
Do I need Claude Design to use /design?
You need a paid Claude plan (Pro, Max, Team or Enterprise) and an updated Claude Code. Claude Design and the command in Claude Code share the same underlying projects, so in practice you are working with one system from two directions.
What is the difference between /design and /design-sync?
/design is the side where you design: generate artboards, pick one, adjust it, have it built. /design-sync is the side where you bring an existing component library into a design system project, one component at a time and never as a wholesale replacement. The first makes new work; the second keeps existing work aligned.
Does this cost extra on top of my subscription?
No, it is included. Since June it shares usage limits with chat, Cowork and Claude Code, so it draws from the same budget as the rest of your work. If you want to go past the limit, you can enable extra usage.
Can an admin turn this off for an organization?
On Enterprise it is off by default and an admin enables it in organization settings. Since June there is also an admin role that can approve one standard design system and lock further edits.
Sources
- Announcement by @ClaudeDevs on X, 17 August 2026 (timestamp 23:57) — x.com/ClaudeDevs
- “Claude Design now stays on brand for daily work”, 17 June 2026, accessed 19 August 2026 — claude.com/blog
- “Introducing Claude Design by Anthropic Labs”, 17 April 2026, accessed 19 August 2026 — anthropic.com/news
- Claude Design product page, accessed 19 August 2026 — claude.com/product/design
- Claude Code CHANGELOG, checked through 2.1.235 on 19 August 2026 — github.com/anthropics/claude-code
Checked on 19 August 2026. I read the announcement itself on X, including the follow-up reply stating availability on Pro, Max, Team and Enterprise. The remaining replies in that thread sit behind a login, so I left them out. The description of the plan boundary, the 256 KiB and 256 file limits and the warning about files read back all come from the tool as it exists in my own session (Claude Code 2.1.233), not from a documentation page; there is no public page that states it this way. Two things do not quite line up: the 17 June blog post already lists /design as available in beta, while the 17 August announcement calls the artboard workflow a research preview. I have left that difference standing rather than picking a side. Beyond that, the public Claude Code changelog mentions neither the /design command nor the word artboard anywhere, including in the newest release at the time of writing. I could not test the artboard workflow myself: the command does not appear in my installation’s skill list.