What Is Claude Code's /design Skill?
/design is a research preview skill that brings an artboard-based design workflow into Claude Code, in both the CLI and the desktop app. You describe what you want built or redesigned, and instead of writing one version of the UI and hoping it matches what you meant, Claude publishes a canvas of several editable artboards for you to look at and choose between. It runs on Claude Code v2.1.233 or later, on Pro, Max, Team, and Enterprise plans, and it is built on the same artifacts system that already powers shareable Claude Code output.
The shift is small to describe and large in practice. Before this, asking Claude Code to redesign a screen meant it picked one direction and built it, and if that direction was wrong you were editing code to correct a design decision. /design separates those two steps: you compare layouts first, on a canvas, before a single line of implementation code gets written.
How the /design Workflow Actually Works
- Open the desktop app's Code tab (or the CLI) in a session attached to your project, and type /design followed by a real brief, not just a screen name.
- Claude prints a link to a published canvas. Open it and you see a set of artboards, editable draft layouts for the thing you described.
- Look at each artboard the way you would look at design comps. Nothing is implemented yet, this is still the compare stage.
- Pick the one you want, tweak it on the canvas if you need to, then tell Claude which option to implement.
- Claude writes the actual code for the artboard you chose, and it lands in your project as a normal set of file changes, reviewed the same way you review any Claude Code diff.
The CCC Artboard Loop
We teach members a short discipline for this instead of running /design and shipping whatever comes back. Call it the Artboard Loop, and it is three steps, none of them optional.
- Name the constraint in the brief. A vague brief produces artboards that all miss the same thing. State the actual use pattern, the device it has to work on, or the one element that cannot move, before you hit enter.
- Compare before you commit. Open every artboard on the canvas, not just the first one that loads. The point of this workflow is comparison, and skipping straight to the top result throws away the reason to use it.
- Review the implementation like any other diff. Picking an artboard tells Claude what to build, it does not exempt the resulting code from review. Read the diff, run the app, and check it the way you would check a change Claude made without /design.
What It's Actually Good For (and Where It Still Needs You)
This is a research preview, so the honest scope matters more than the pitch. It is genuinely useful for the moment where you know a screen needs to change but cannot describe the fix in one sentence, or where you have a vague sense of better and no mockup to hand Claude. Publishing three real, comparable options turns a fuzzy request into a decision, which is a faster loop than describing, building, disliking it, and re-describing.
- Good for: exploring layout directions fast, getting a non-technical stakeholder to point at an option instead of trying to describe one in words, and unsticking a redesign that has stalled because nobody can agree on the brief.
- Still needs you for: a real design system with locked components, an accessibility pass, and pixel-level brand execution. A research preview is a draft generator, not a design review.
How This Changes Client Work
For anyone building client work in Claude Code, the practical win is the canvas itself. Clients rarely have the vocabulary to describe a layout they want, but almost everyone can point at one of three real options and say that one, move that button up. Sending a canvas link instead of a screenshot of one attempt turns a design round into a five-minute decision instead of a back-and-forth email thread. The implementation step after that is exactly like any other Claude Code change: you still own the review, the diff, and the decision to ship it.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
What is Claude Code's /design skill?
It's a research preview command that turns a written brief into a canvas of editable UI options called artboards, built on Claude Code's artifacts system. You compare the artboards, pick one, and tell Claude to implement it, which separates choosing a layout from writing the code for it.
Does /design work in the terminal or only in the desktop app?
Both. It works in the Claude Code CLI and in the Claude Code desktop app's Code tab. The desktop app makes the canvas easier to open and compare since you are already working in a windowed view.
Do I need a paid plan to use /design?
Yes. It's available on Pro, Max, Team, and Enterprise plans, and it requires Claude Code v2.1.233 or later. Update Claude Code first if the command doesn't show up.
What happens after I pick an artboard?
You tell Claude which artboard to implement, and it writes the real code for that option into your project as a normal set of file changes. From there it's the same review loop as any other Claude Code diff, read it, run it, and check it before you ship.
Is /design production ready?
It's a research preview, so treat the output as a strong draft rather than a finished design. It's good at generating real, comparable layout options fast. It doesn't replace an accessibility pass, a locked design system, or a final brand-level review.
Last reviewed by David Iya on August 25, 2026
