Claude Code's /design Command: Sketch Interfaces Before Building

Humans plan, Claude executes

Anthropic looked at about 400,000 Claude Code sessions from roughly 235,000 users, and the division of decisions was lopsided. People made around 70% of the planning calls, meaning what to build. Claude made around 80% of the execution calls: which file, which syntax, which command. Across the seven months studied, sessions about repairing broken code dropped from 33% to 19%, while operating software and analysis grew.

That split explains the feature Anthropic shipped this week. Once an agent owns execution, the bottleneck moves up to the part people still own, and for anything with a screen, planning is visual. Typing "build the settings page" can't mean anything precise when nobody has seen the settings page yet. It's like describing furniture for a room nobody has entered.

So most of us build the thing to find out. Idea, code, render, dislike, rewrite. Each rejected idea gets paid for in the costliest currency there is.

What changed

Claude Code and Claude Design could already talk to each other. You register the design MCP server and sign in:

claude mcp add --scope user --transport http claude-design https://api.anthropic.com/v1/design/mcp
/design-login

Once connected, a design can be pulled into your codebase, your code can become a live prototype, and work can travel in both directions. All of that predates this week.

What's new is the /design command itself. Anthropic put an early preview of it into Claude Code on August 17, 2026. Nate Parrott, the product designer who created Claude Design, announced it, and the Claude Code team backed that up the same day. In the CLI or the desktop app, Claude now produces a handful of editable UI mockups, called artboards, displayed as an Artifact. You select one, adjust it, and tell Claude to build it. Pro, Max, Team and Enterprise plans have it, and claude update fetches it.

"The two products can sync" versus "the artboards live in your terminal" sounds like plumbing, but it changes what a rejected idea costs: four hundred lines of JSX before, about nine seconds of looking now. The loop becomes an idea, six visual possibilities, five discarded, one coded.

Where exploring used to go

Before the command you had two options, and neither was cheap.

The first was to write the interface out in prose and cross your fingers. Three paragraphs on card spacing and hierarchy go in, Claude returns a component, localhost opens, and something's off in a way the prompt had no chance of predicting. You then end up editing code to fix a layout decision that thirty seconds of looking would have settled.

The second was to open claude.ai/design, prototype there, and reconcile the result with your actual components back in the repo. It's a good route and often still the right one. The trouble is the switch between tools, and that switch is what kills exploration: you accept one direction and skip six, because opening another tab felt like committing.

Parrott's own history shows why. Back in late 2025 he was the lone designer on Claude Code for VS Code, next to two engineers. Opus 4.5 landed that November, the engineers sped up considerably, and he had to match their pace. Pasting terminal output and screenshots into Claude and asking for a design was his first attempt, and by his account it went badly. The fix was to hand Claude an HTML canvas rather than a text box, because HTML is a rich visual medium and Claude writes it remarkably well. That turned into Claude Design, and /design carries the same artboard workflow into the terminal, next to the code.

Habits that make it work

Parrott published his own best practices in July. They transfer almost entirely to the CLI and are more useful than any feature list.

Think before you prompt. He spends real time composing prompts ahead of designing, sometimes dictating them and sometimes typing them into a phone's Notes app from the couch. Working out what you want is a separate activity from asking for it, and a vague prompt burns usage on something you'll reject.

Describe the look. Left alone, Claude drifts toward a few favorite aesthetics, and you'd recognize them at once. Give it fonts and colors, a moodboard, or ask it to propose font and color pairings and debate with it until one fits. This habit alone is what makes output look like your product and not like every AI-generated landing page from the last year and a half.

Start with wireframes when fidelity can wait. They're faster and keep Claude focused on structure and away from visual detail. While you're still deciding between a sidebar and a top bar for filters, gradients only add noise. Try eight structural ideas before you polish one.

Ask for ten, then remix. Most won't be good, and that's expected. Parrott's follow-up wording goes along the lines of liking option B plus a bit of option D and asking for five riffs that combine them.

Do the last mile by hand. Direct edits on the canvas, such as rearranging, deleting, resizing and changing text or colors, cost no tokens. Prompting for the same changes costs plenty, and alignment is easier to eyeball than to describe. Stop writing sentences about padding.

Sketch and point. If a layout exists in your head without words, draw it on paper and photograph it. Rather than writing a paragraph about which element you mean, click it and talk.

Anatomy of a prompt that works

Those habits boil down to a reusable shape with five slots. Skip one and you'll get a predictable failure.

Count. The number of directions you want. Give a figure or you'll get one. Six works for wireframes and three for high fidelity.

Fidelity. Wireframe or polished. Say which, since the model tends to reach for polish and polish is where time and usage disappear.

The thing. One bounded, named surface, such as a notification preferences panel, a first-run empty state or an invoice detail view. "The dashboard" is too big.

Constraints from your code. Which existing components must appear. This is where the CLI earns its place, because Claude can read them. Name them anyway, since pointing beats hoping.

Aesthetic direction, or a stated deferral. Name the fonts and colors, or write "structure only, ignore visual styling for now". Staying silent is the one choice that reliably backfires, since silence gets you the house style.

/design 6 wireframe options for the invoice detail view.
Reuse DataTable and StatusPill from src/components.
Structure only, no styling yet.

Compare that with what people usually type first, /design an invoice page. The command is the same and the return is very different.

Anthropic's own prompting advice for Claude Design overlaps with this and is worth keeping beside it: state the goal, the layout, the content and the audience. The five slots above are tuned for divergence, while Anthropic's version suits producing one good artifact, so use it when you already know what you want.

A quick test of whether the prompt did its job: scan what came back and ask if the options differ on hierarchy or just on color. Six takes on the same information architecture signal a prompt that was too narrow or asked for polish too early. Six truly different answers to "what does this screen prioritize" are the goal. What you're paying for is different decisions, not different palettes.

Connecting your real design system

/design-sync brings your local design system into Claude Design, so what it generates is assembled from your real components and Claude doesn't make up a button class from scratch. It can read from a GitHub repo, design files, uploads or the local codebase, and you can name the system in the same breath: /design-sync Acme DS.

Two points deserve planning. Anthropic's command reference says a first sync verifies every component and may run for a few hours on a large repo, so kick it off before lunch and not right before a demo. The help center also names large codebases as a source of lag and recommends linking them via Claude Code instead of the browser. And since the implementation currently focuses on React, Vue and Svelte projects depend on Claude reading components directly in the session.

One admin snag: Claude Design is off by default on Enterprise plans, and an admin must switch it on before any of this works.

What it costs

Claude Design no longer has its own allowance to track. Usage comes out of the pool shared with Claude chat, Claude Code and Cowork, and Anthropic is explicit that complex projects, big codebases and lots of iterations consume more. A separate weekly allowance existed earlier, and it's gone.

The CLI feels this more than the web does. By the time you request several full mockups there, the session already carries an indexed codebase and a running conversation. If you reach your limits, Claude Design is unavailable until they reset.

The way to ease the cost is the good-practice list turned around: bounded features and not multi-screen flows, wireframes before high fidelity, and manual canvas edits for the final 10%, which are free.

What /design doesn't do

Parrott draws the scope plainly. Claude Code is for writing production software, and Claude Design covers the rest, meaning early ideation, collaboration and winning buy-in before anyone commits to a build. He said that before /design existed, and a canvas inside the terminal erases the boundary. What still holds is a different split: divergence on one side, convergence on the other, both in a single session.

The command doesn't take over the build loop. What it adds is a visual planning step in front of it. You explore directions on the canvas, choose one, and return to ordinary Claude Code for implementation, tests, refactoring and the rest of what makes software real.

It's only days old and shows it. Designs move into the build step but still need to be saved by hand. /design is missing from the official Claude Code commands reference, while /design-login and /design-sync are listed. Behavior will probably change.

Which surface to use

Use /design in Claude Code when the output is headed into a repo you have checked out, soon. Being close to your code is the whole point.

Reach for claude.ai/design when the audience is a person: a deck, a one-pager, a landing page, or a click-through prototype for user testing, basically anything a stakeholder can open in a browser with no terminal. It exports PDF, PPTX, standalone HTML and .zip, and sends work to Canva, Miro, Replit, Vercel and Figma-adjacent tools, among others.

The two round-trip, so work begun in one can move to the other. A designer without a local dev environment should treat the web app as home base, with handoff as the bridge. An engineer who thinks in repos gets /design.

If Figma is your source of truth

Choosing isn't required. On February 17, 2026, Figma and Anthropic released Code to Canvas, which sends the running, rendered UI from Claude Code to Figma as frames you can edit, not as static screenshots. Install the plugin:

claude plugin install figma@claude-plugins-official

Then open /mcp in a session, connect the remote Figma server and authenticate. If a figma-desktop entry shows up, disable it, since it's the local read-only server and clashes with the remote one. After that, saying "send this to Figma" calls generate_figma_design.

Some people have hit trouble here. Threads on Figma's community forum describe captures stuck in an endless processing loop that ended in blank files, though at least one developer got it working after simplifying the page. Test on something disposable before you promise a designer anything.

In short, /design explores before any code exists, and Code to Canvas takes code that does exist and puts it back on a canvas for the team to debate.

Your first run

Pick a feature you've been circling without building, and keep it bounded: a panel, a modal, a settings page. Run claude update, open a session in the right repo, and begin with:

/design 6 wireframe options for a notification preferences panel.
Use our existing card and toggle components. Structure only,
no color or polish yet.

Review all six and check that they truly disagree on hierarchy. Cut four. Request five remixes of the two that remain. Choose a winner, ask for one high-fidelity pass with your fonts and colors spelled out, and fix spacing on the canvas by hand and not through description. Say "implement this" only after that.

Time it. The full exploration should cost less than one round of "can you move the toggles to the right side" would have in code, and the layout you end with is one you picked and didn't settle for.

That's the real shift, and it's smaller and more practical than the industry-transformation talk these releases usually draw. AI coding had already made implementation cheap. Now bad ideas are cheap to throw away too. The agent covers most of the how, and seeing the options sharpens your sense of the what, which has always been your job.