Skip to main content

The /design Command: Artboards Before Code

Intermediate

Anthropic dropped a slash command into Claude Code that skips coding on purpose. /design publishes a canvas of editable UI artboards from a plain-English brief; you pick one, tweak it, and only then does Claude turn it into real code. It is the first Claude Code feature where the deliverable is not code — the design phase is the artifact.

What you'll learn
  • Understand what an artboard is and why it changes the coding-first flow
  • Run /design correctly on the first try (version, plan, prompt shape)
  • Know the three phases: draft → pick+edit → implement
  • Avoid the three known traps: token cost, style drift from your repo, and the free-tier wall
  • Pair /design with the Concise output style that shipped the same week

What it actually is​

/design is a skill — not a plain slash command. When you invoke it, Claude Code hands off to Claude Design's artboard workflow and prints a link to a published canvas. An artboard is a working screen you can act on: change the color, move a block, widen a gap. It is rendered on the artifacts runtime, so it lives in your Claude account, not as files in your repo.

That distinction matters. The output of /design is a URL, not a diff. Nothing lands in git status until you tell Claude to implement.

What you'll learn
  • Availability: Pro, Max, Team, Enterprise. Not free. Requires Claude Code v2.1.233 or later. Ships in both the CLI and Claude Code Desktop.
  • Status: research preview — expect the invocation shape, output format, and included artboard count to shift.

The three phases​

Guided walkthrough1 of 3
  1. Run /design with a brief that says what the screen is for. Claude publishes several artboard variants side by side, each editable. You get a link; open it in a browser.

The prompt shape that works​

/design rewards briefs that describe purpose and audience, not pixel targets. Two patterns:

/design — feature brief

/design a few options for the sign-in screen. Users are engineers on mobile.
Optimize for one-hand thumb reach; SSO is the primary path, email/password
secondary. Show a state for a locked-out account.

/design — redesign an existing surface

/design redesign our composer based on what people actually use it for:
drafting long messages, attaching files, and switching model. The current
version buries the model picker; make it a first-class control.

Two things that quietly do a lot of work in those briefs:

  • Naming the user and constraint ("engineers on mobile", "one-hand thumb reach") pulls Claude off the statistical-average layout it defaults to.
  • Naming a failure state ("locked-out account") forces the artboard to cover empty/error/edge cases, not just the happy path.

The three traps​

1. It is token-hungry. Multiple full-fidelity artboards per invocation eats budget faster than a normal chat turn. Research-preview users report this consistently. Save /design for real decisions, not throwaway sketches.

2. It does not match your codebase. Claude Design generates from a generic aesthetic, not from your existing components. If you want the artboard to feel like the rest of your app, front-load a DESIGN.md at the repo root (fonts, spacing scale, color tokens, existing components) and reference it in the brief — the same trick that keeps /design's implementation phase from re-inventing your button primitives.

Reference DESIGN.md before /design

Before you draft anything, read DESIGN.md and list the type scale, spacing
scale, and named color tokens you'll use. Then /design a settings screen
that respects those tokens.

3. Free-tier wall. /design is gated behind paid plans (Pro and up). If your team pays for Claude Code seats but a contractor is on free, /design silently isn't there for them.

Pair it with Concise output style​

Anthropic shipped the built-in Concise output style the same week (v2.1.237). It makes Claude lead with results and skip preamble — a good pair for /design, because the handoff turn ("implement option 2") does not need narration:

~/.claude/settings.json
{
  "outputStyle": "Concise"
}

Concise still keeps full detail for error reports, security warnings, and destructive-action confirmations — you lose narration, not safety rails.

When /design wins vs. writing code directly​

Use /design whenSkip it when
The visual decision is the hard part (new surface, unclear layout)You already know the layout; you just need the code
You want to compare 3+ directions cheaply before committingYou are iterating on an existing screen's logic, not shape
The stakeholder needs a clickable-ish artifact to approveThe screen must match an existing design system 1:1
The failure/empty/loading states matterYou are prototyping throwaway internal tooling

Non-obvious mechanics​

  • The canvas URL is shareable. Because artboards live on artifacts, the link works for anyone with access to your Claude account view — you can send it to a designer or PM without exporting anything.
  • Iteration is dual-channel. You can edit on the canvas and keep prompting in the Claude Code thread. Both feed the same context.
  • Implementation still respects your repo. Once you say "implement", Claude Code goes back to normal repo-aware behavior — it will use your Tailwind config, your components, your file structure. The artboard is the target; your codebase is the terrain.
Press Enter or Space to flip the card. Use the left and right arrow keys to move between cards.Term shown.
1 / 7

Check yourself

0/4
  1. Where do artboards from /design live?
  2. You are on Claude Code v2.1.230 and a free Claude account. What happens with /design?
  3. Which brief shape gives /design the best chance of a useful artboard?
  4. Why is Concise output style a good pair for /design?

Sources & further reading​

Next​

  • Custom Slash Commands — how /design sits alongside the commands you build yourself.
  • Output Styles — the Concise style that pairs with /design handoffs.
  • Ship a Beautiful Site — the DESIGN.md pattern in depth, plus anti-slop constraints for whatever /design hands off to.