Anthropic brought Claude Design's artboard workflow into Claude Code itself on August 17, 2026. The new /design command — a research preview — lets you generate a few editable UI options straight from a coding session, pick the one you like, tweak it, and have Claude implement it. No more switching tabs to claude.ai/design and pasting code back in.
Nate Parrott, who works on Anthropic's design team (previously at Browser Company), made the announcement on X:
Today we're releasing an early preview of the /design command in Claude Code! from CC Desktop or CLI, try something like "/design a few options for " before you build — pick your fave artboard, edit it and implement.
@ClaudeDevs framed the mechanics plainly: "Claude Code can design now. The new /design skill (research preview) brings Claude Design's artboard workflow into the CLI and Desktop, built on artifacts. Run /design to get editable artboards for your UI — pick one, tweak it, then have Claude implement it." The announcement post crossed 398K views within hours.
TL;DR
| Question | Answer |
|---|---|
| What is it? | /design — a Claude Code command that generates editable UI artboards before you write implementation code |
| Built on | Claude Design's artboard/canvas workflow, running on Artifacts |
| Where | Claude Code Desktop and CLI |
| Plans | Pro, Max, Team, Enterprise |
| Status | Research preview — expect rough edges |
| How you run it | /design a few options for {feature} |
| Workflow | Generate artboards → pick one → edit inline → implement |
| Known limitation | Token-hungry; doesn't automatically match your existing code style |
How /design actually works
The command follows the same shape Anthropic used to describe Claude Design's June 2026 update and /design-sync — except now the artboard step happens inside the coding session itself rather than requiring a separate trip to claude.ai/design.
- Prompt with intent, not pixels. Nate Parrott's own example:
/design a few options for {feature}. You describe the feature or screen, not exact layout specs. - Claude generates multiple artboards. These are editable UI options rendered through the Artifacts runtime — the same underlying mechanism Claude Code Artifacts uses to turn session output into shareable, live-rendered pages.
- You pick a favorite. Rather than regenerating from scratch with a new prompt, you select the artboard closest to what you want.
- You edit it inline. Direct manipulation on the canvas, consistent with the WYSIWYG editing Claude Design added in June.
- Claude implements it. The selected, edited artboard becomes the target for real code — in your repo, using your stack.
That last step is the point of putting this inside Claude Code specifically, rather than Claude Design's standalone web app: there's no export-then-paste. The artboard and the implementation live in the same session.
/design vs Claude Design: which one do I actually use
This is the real question worth answering, and it's the one Jaren B. (@jarenoid) asked directly on X: "so when exactly I should use this skill and when should i prefer the claude design instead?"
| Situation | Use /design in Claude Code | Use full Claude Design at claude.ai/design |
|---|---|---|
| You're already mid-session in your repo | Yes — no context switch | No — separate app |
| You need to hand a mockup to a non-technical stakeholder | No | Yes — PDF, PowerPoint, Canva export |
| You want your imported design system applied automatically | Not yet confirmed in the preview | Yes — design system import shipped in June |
| You want the fastest path from idea to shipped code | Yes — implementation happens in the same session | Slower — requires /design-sync handoff |
| You're exploring a full multi-screen flow for review | Partial — "a few options" per feature | Yes — canvas is built for this |
The short version: /design is the lightweight, developer-embedded version of what Claude Design already does. If you're going to implement the result yourself in the next five minutes, use /design. If you need export formats, design-system import, or a canvas a PM can review without touching a terminal, claude.ai/design is still the more complete surface.
The token-cost complaint is real, and worth taking seriously
Not every reaction was positive, and the honest ones are worth repeating rather than filtering out. Jordan (@jstamby) put it bluntly: "Design feature is still way too token hungry."
That complaint predates /design — it's been leveled at Claude Design's canvas workflow generally — but it applies with extra force inside Claude Code specifically, because a coding session is already spending context on your codebase, chat history, and connected tools. Generating multiple artboards on top of that is not free. If you're running close to a context or usage limit mid-session, /design is not the low-cost option; a plain "sketch this layout in a code comment" prompt is cheaper.
Practical read: treat /design like /agents or /background — a deliberate tool for a specific moment (kicking off a new screen, exploring layout options before committing to one), not something you reach for on every small UI tweak.
What people are asking
"It already could do this — I've been doing it in CLI for at least a month." Automa Dynamics (@automadynamics) is right that the underlying capability — generating a UI mockup and implementing it via Claude Code — was reachable before, by manually chaining Claude Design output with Claude Code prompts, or by asking Claude Code to draft an HTML/SVG artboard directly. What /design adds isn't a new capability so much as a packaged, one-command version of a workflow power users had already been assembling by hand. That's a legitimate distinction — it lowers the bar for everyone else, even if it changes nothing for someone already running the manual version.
"Does the output look good?" Early feedback is positive on visual quality. Thien Nguyen (@Stevie_658jjh) said the design output "still look[s] really good" — consistent with Claude Design's Opus-class vision positioning since its April 2026 launch. Designer Oliur (@UltraLinx) called it "what us designers needed" — a notable reaction from someone in the target audience for artboard-level exploration, not just developers.
Does it match my existing components? Not confirmed yet. Claude Design's full workflow can import a design system from your repo (shipped June 2026) so generated screens inherit your actual tokens and components. Whether /design inside Claude Code inherits that same import automatically, or whether you need to attach CLAUDE.md and component paths manually the way you would for any AI-generated UI, isn't spelled out in the initial announcement. Treat the first artboard as a draft to review against your real design tokens — same rule as any AI-generated frontend code.
Getting started
- Update Claude Code.
/designrequires a recent build; run your package manager's update command (npm install -g @anthropic-ai/claude-code@latestor the Desktop app's auto-update) if the command isn't recognized. - Confirm your plan. Pro, Max, Team, and Enterprise are named as eligible; check
/release-notesor your account settings if you don't see it. - Try a small feature first.
/design a few options for a settings pageis a safer first test than a full multi-screen flow, given the token-cost feedback above. - Point Claude at your components. Reference
@packages/uior your actual component library in the follow-up prompt when you move from artboard to implementation — don't assume automatic design-system matching in a research preview. - Review before merge. Same bar as any AI-generated UI: run a visual diff or Storybook snapshot, and check accessibility (contrast, reading order) before shipping.
Bottom line
/design doesn't introduce a new model capability — it repackages Claude Design's artboard workflow, running on Artifacts, as a one-command detour inside Claude Code. For developers who were already bouncing between claude.ai/design and their terminal, that's a real time save. For anyone tight on context budget, the token-hunger complaint that has followed Claude Design since its canvas editing update is worth weighing before reaching for /design on every small screen. It's a research preview: expect the command to change shape, and expect the first artboard to need real review against your actual codebase before it ships.
Related reading
- Claude Design (Anthropic Labs): prototypes, slides, and one-pagers — the April 2026 launch this command builds on
- Claude Design June 2026 update: design systems, canvas editing, /design-sync — the WYSIWYG canvas and repo sync
/designinherits from - Claude Code Artifacts: shareable AI sessions — the runtime
/designartboards are built on - Claude Code commands: complete slash command reference (2026) — where
/designsits alongside/planand every other command - DESIGN.md templates for professional UI with AI agents — feeding brand and component intent into any design-capable agent
- What are agent skills? Complete guide —
/designships as a skill, not a hardcoded CLI command
Official: Claude Design → claude.ai/design
Availability, token cost, and design-system matching for /design are still changing during this research preview — confirm current behavior in your own Claude Code session before it becomes part of a production workflow.