Claude Code Design Skill: Draft UI Artboards in the CLI

September 2, 2026 claude-codeskills

/design <brief> makes Claude Code draw your UI before it writes it. You give a brief, Claude drafts several variants as artboards on one canvas, publishes that canvas to a URL, and prints the link. You open it, pick the artboard you like, then tell Claude to implement that one. Until this shipped, Claude Code could only reach a UI by writing code and letting you look at the result.

The short version before the detail.

• What it is: a bundled skill, /design [brief], described in the commands reference as drafting "UI mockups, screen flows, landing pages, or posters as artboards on one canvas". It is a research preview.
• What it produces: an artifact, not files in your repo. The published page runs a research preview of Claude Design's editor.
• Gates: Claude Code v2.1.234 or later, a Pro, Max, Team, or Enterprise plan, and a session signed in with /login. An API-key session cannot publish one at all.
• Editing: where saving is enabled for your account you can select an element, change it, and save a new version. Otherwise you view the draft and export PNG or PDF.
• The catch worth knowing up front: artboards are a picture. Nothing is wired to your codebase until you ask Claude to implement the one you picked.

Verified against the Claude Code docs on 2026-09-02: the commands reference, the artifacts page (its "Draft a design canvas" and "Availability" sections), and the Week 34 release notes. Where a detail comes from the shipped skill's own tool definition rather than a documentation page, it says so.

What an artboard canvas actually is

An artboard is a working canvas showing one screen, the same idea Figma and Sketch use. /design puts several of them side by side on one page so you can compare, which is the whole point: the value is not one mockup, it is four mockups you can reject.

That page is an artifact. Artifacts are how Claude Code publishes visual output: a single self-contained HTML page hosted at a private URL on claude.ai, which updates in place as the session continues. So /design is not a new publishing mechanism bolted onto the CLI. It is a skill that produces a particular kind of artifact, and every artifact rule applies to it.

Two consequences fall straight out of that, and they are the ones people trip on.

The canvas is not in your repository. Unless you name a location, Claude writes the page to a temporary directory outside your project and publishes from there. Your git status does not change. If you want the design preserved in the repo, export it or ask Claude to write the implementation.

Publishing goes through your permission mode. In manual or accept-edits mode Claude Code asks first, with a prompt naming the file, the upload to Anthropic's servers, and the page title. In auto mode the classifier reviews the publish instead of prompting you, so a canvas can go up without you seeing anything. After you approve one publish, republishing to the same artifact happens without asking again, with named exceptions: if the page declares a runtime capability such as connector calls, or if you have since shared it publicly or with your organization at the latest version.

The requirements that will actually stop you

Most "why can't I run /design" cases are one of the artifact prerequisites rather than the skill itself. All of these must hold at once:

The authentication row is the one that catches developers, so it is worth stating plainly: if you run Claude Code on a Console API key, an LLM gateway token, or cloud-provider credentials, you cannot publish artifacts, which means /design has nothing to publish to. That is not a bug to work around, it is how the feature is scoped. Same for a session in the Agent SDK, a GitHub Action, or an MCP-server context, where artifacts are off by default.

The tell when a prerequisite is missing is specific and easy to misread: Claude says it cannot publish, or it writes a local HTML file and gives you no link. If you get a local file, stop looking for a flag and check the table above.

Running it

The brief names what you want drawn. The documented example is exactly this shape:

/design a settings screen for a mobile banking app

The release notes' own example is instructive because it is not a layout spec at all:

/design redesign the composer based on what people actually use it for

That is the useful habit. Describe the feature, the user, and the job the screen does, and let the variants disagree with each other. A brief that dictates pixels gets you one layout drawn four times, which wastes the only thing the multi-artboard format buys you. If you want variants that genuinely diverge, say so: ask for options that vary density, or grouping, or which action gets primary weight.

When it finishes, Claude prints the URL and your browser opens the page. Two navigation details are worth memorizing:

• Ctrl+] reopens the most recent artifact from the terminal.
• /artifacts lists every artifact you own or that has been shared with you. Press o to open, c to copy the link, Enter to attach it to the current session.

That last one matters more than it sounds. A different session, or the same session after /clear, has no idea your canvas exists. Give Claude the URL or attach it with /artifacts, or it will publish a brand new canvas instead of updating yours. Set CLAUDE_CODE_ARTIFACT_AUTO_OPEN=0 if you would rather it not open a browser tab each time.

Make the artboards look like your product

By default the drafts look like Claude's taste, not yours. There is a documented fix, and it is cheap.

Claude applies a built-in design skill when it builds any artifact (v2.1.182 or later), and that skill looks for an existing design system in your project before choosing its own. So record your design tokens (the named color, typography, and spacing values your product reuses) somewhere Claude reads, such as CLAUDE.md or a theme file:

## Design system

- Colors: primary #1a4d8f, accent #f59e0b, surface #f8fafc
- Typography: Inter for body, JetBrains Mono for code
- Spacing: 8px scale, 6px border radius

The heading and format are an example, not a schema. Any clear list of colors, fonts, and spacing works. What is fixed is the precedence: your prompt beats your design system, and your design system beats Claude's own choices. So the tokens set a floor for every draft, and a one-off instruction in the brief still overrides them.

One typography constraint follows from the artifact CSP rather than from /design: Google Fonts is the only external font source an artifact page can load from. Any other typeface gets inlined as a @font-face data URI, and every typeface gets a fallback stack. Name the font in your prompt or your design system if it matters.

From artboard to code

The loop /design is built for is: brief, variants, pick, refine, implement. The refine step is where accounts differ.

Where saving is enabled for your account, the published canvas is an editor. Select an element on an artboard, change it, and save; that publishes a new version, and anyone with the page open sees it update in place. Everyone else gets a view-and-export preview: the draft plus PNG or PDF export.

Either way, the handoff back to code is a sentence in the terminal. Tell Claude which artboard to implement and it goes and writes it, in the same session that drew it, with your repository in context. That is the actual argument for designing here rather than in a separate tool: the thing that drew the mockup already knows what your components are called.

Worth being clear about what this is not. An artifact has no backend, cannot store form input, and cannot serve multiple routes. /design output is a mockup you then build, not a running app. If what you want is a hosted, working application generated from a prompt, that is a different product category, and our Lovable and Claude Code comparison covers that fork properly.

The other half: /design-sync

Two related skills ship alongside it, both in the commands reference:

• /design-sync [hint]: "Convert your repo's React design system and upload it to Claude Design."
• /design-login: "Authorize design-system access for /design-sync."

The direction of travel is the reverse of /design. Instead of drafting a screen and implementing it, this pushes your existing React component library up to a design-system project on claude.ai/design, so later drafts are drawn from your real components.

From the skill's own tool definition (not a documentation page, so treat this as the shipped behavior rather than a documented contract): the sync is deliberately incremental, one component at a time rather than a wholesale replace. It targets a project whose type is a design system, and that type is fixed when the project is created, so pushing into an ordinary project does not convert it. Writes are also gated behind a plan step: the exact set of paths to write and delete, and the local directory uploads may be read from, are locked and shown to you before anything uploads. That last part is the design decision worth appreciating. You see the structured file list independent of whatever the model told you it was about to do.

Is it worth using?

Yes for anything where the layout is the open question, no for anything where it is not.

The cost is real and it is tokens. The docs say it outright for artifacts in general: a styled page is more token-intensive than the same content as terminal text, with inline CSS, interactive controls, and images embedded as data URIs as the main contributors. Four artboards of a screen you already know how to build is money spent drawing something you could have written. Four artboards of a screen nobody has agreed on yet replaces an argument.

The other honest caveat is the label. This is a research preview, and neither the release notes nor the skill description publishes flags or artboard limits. Expect the workflow to move.

FAQ

Does /design write files into my project? No. Unless you name a location, Claude writes the page to a temporary directory outside your project and publishes it from there. The output is a URL, not a commit. Ask Claude to implement an artboard when you want repository changes.

Why does Claude say it cannot publish, or give me a local HTML file with no link? That is the standard signal that an artifact prerequisite is not met. Check the version (v2.1.234 or later for /design), the plan, and above all the authentication: sessions on an API key, an LLM gateway token, or cloud-provider credentials cannot publish artifacts at all.

Can I share a canvas with my team? A new artifact is visible only to you. Sharing depends on the plan. On Team and Enterprise you can grant access to specific people or the whole organization, and make someone an editor. On Pro and Max, a public link is the only sharing option. On Team and Enterprise, public sharing stays off until an Owner enables it for the organization.

Can reviewers comment on the artboards? Only on an artifact shared within your organization, which needs a Team or Enterprise plan and Claude Code v2.1.221 or later. Comments are not available while an artifact is shared publicly. Claude can read and reply to a thread once someone who can edit sends it to Claude or mentions @claude in it.

What is the difference between /design and the design skill Claude already used for artifacts? They are two different things with confusingly similar names. The built-in design skill (v2.1.182 or later) is what gives any artifact a deliberate palette, typography, and layout without being asked, and it is what reads your design tokens. /design is a separate bundled skill that draws artboards and publishes a canvas running Claude Design's editor. The built-in one styles pages Claude was already building; /design exists to produce mockups.

Can I use /design without touching Claude Design? Yes. /design needs artifacts, not a design-system project. /design-sync and /design-login are the two skills that involve claude.ai/design projects, and they are optional.

How do I get back to a canvas tomorrow? Run /artifacts, select it, and press Enter to attach it to the session (or o to just open it). Claude Code reads that list from your claude.ai account, so it survives a new session and a /clear. Attaching it, or pasting its URL, is what makes Claude update the existing canvas instead of publishing a new one.