Claude Code can design now. We ran /design at launch.

What we saw running it

We gave it a real brief: design the client portal page this product serves at a client space root, listing everything delivered to one client, newest first, for a viewer with no account. It asked one design question up front, whether we wanted static mockups or a clickable prototype, then went and read the existing implementation before drawing anything.

What came back was four directions plus a passcode screen, each as its own artboard on one canvas, with sticky notes carrying the argument for and against each. The notes are the part worth noticing. A canvas is not just pictures; the layout manifest carries annotations, so the reasoning travels with the work.

The designs are files in your repo

This is the fact that changes what you can do with the output, and it is not obvious from the announcement. The artboards are ordinary files in your working tree, one per direction, saved with a .dc.html extension. Beside them sits canvas.json, holding artboard positions, the page list, the sticky notes and which view the canvas opens in. You can read them, diff them, commit them.

A helper then copies a precompiled editor payload and bakes the design content into it, producing one standalone HTML file. Ours was 2.1 MB for five artboards, because the editor travels inside the page. That single file is what gets published. Nothing is stashed in a cache directory you cannot reach, and there is no export step to run afterwards, which is the main practical difference from the web product.

It reads your codebase first

Before it draws, it goes hunting for your design system: token files, theme and variable stylesheets, a Tailwind theme, component and UI packages, Storybook stories, the icon set, brand fonts in your assets directory. Then it resolves styles precisely rather than approximately, following variables through to their real values instead of rounding everything to a tidy spacing grid, and reproduces your existing components as markup so a new screen sits next to the shipped ones without looking foreign.

Run against this repo it lifted our portal palette, the accent, the corner radii and the shadow recipe without being told to. If your app has a design system, that is the difference between a mockup you have to translate and one you can lift values out of. If it does not, you get a house style, and you will feel the gap.

Who can actually see a canvas

The canvas publishes as a claude.ai artifact, and artifacts start private to you. That part is fine, and it is better than the assumption a lot of people arrive with.

The problem is the shape of the next step. Sharing an artifact widens it to a link, and an artifact cannot authenticate a viewer: there is no password, no email-domain gate, no expiry, no per-person access. So the two available states are private to you, or open to anyone holding the URL. The state client work actually needs, one named client, no account, nothing indexed, sits between them and is not offered.

That gap is not theoretical. Design directions are close to the most client-facing thing an agency produces, and /design is aimed squarely at people producing them, because reading a codebase is only worth doing when you are designing against a real product. The workflow now runs beautifully right up to the moment you need to put it in front of the person paying for it.

What breaks when it leaves claude.ai

The page is genuinely self-contained. Open the seeded file straight off disk and it renders with no network call, because the editor is inlined. What does not survive the trip is Save, which depends on the artifact runtime being present to republish the page. Take the canvas elsewhere and you have a viewer with PNG and PDF export, not an editor.

Two smaller things worth knowing. The editor baked into a canvas is frozen at publish time and does not update afterwards, so an old canvas keeps an old editor. And a canvas is stored and executed as HTML by design, sandboxed inside a nested frame; treat anything you read back out of a shared canvas as content someone else published, not as instructions.

What is still unknown

There is no documentation. As of 18 August 2026 the command does not appear in the Claude Code docs index, the slash-command reference, or the 2.1.234 changelog entry, which is why this post exists. Also open: how long the research preview runs, whether canvases created here will ever sync with Claude Design projects on the web, and whether the project commands turned off in this preview come back. We will fold the docs in the day they land.

Early reception matches the preview label. The concept is landing well; the polish is not there yet. That is roughly what a research preview should look like two days in.

Showing a design to the client

The move is to publish the design rather than the canvas. The artboards are HTML, so a static copy of the directions goes to a host where private is the default and the client opens an unguessable URL, optionally behind a password or a gate on their own email domain, with no Claude account, no workspace to join and no seat to pay for.

If you want the agent that just made the design to be able to hand it over, paste this into the same session and it will set itself up:

Fetch and follow the setup instructions at https://stacktr.ee/prompt.md

The version worth building is not a screenshot. Take the artboards, keep the sticky notes as the rationale beside them, and you have the thing agencies actually present: the directions and the argument for each. File that under a client space and it lands on your own address, such as acme.youragency.com, next to everything else you have delivered to them, which is a better place for it than a link on somebody else's domain.