The /design Skill Turns Claude Code Into a Canvas

The /design Skill Turns Claude Code Into a Canvas

The first thing I typed was /design a landing page for Robo Nuggets, dark and light mode. No brief. No reference images. No colour hex codes. Nothing but a silly product name I made up on the spot because I wanted to see what the model would invent when I gave it almost nothing to work with.

What came back was not a code file. It was a canvas — artboards laid out side by side, pannable and zoomable, with a hero section, a product grid, a footer, and a working dark/light pair that actually shared a coherent palette rather than the usual "invert everything and hope" result. I clicked a heading. It selected. A properties panel opened. I changed the font weight from 600 to 700 and the change happened right there, in the design, without a rebuild, without a diff, without me touching CSS.

That is the part worth sitting with. The Claude Code /design skill is not "Claude writes you a nice HTML page." It is a real design surface running inside the tool where your codebase, your CLAUDE.md, and your brand files already live. And that context inheritance is the whole story — bigger than the canvas, bigger than the pretty output, bigger than any single feature in the properties panel.

I'll come back to why the context part matters more than the canvas. First, what the thing actually is.

What the Claude Code /design skill actually does

The /design skill creates a multi-artboard design canvas from a prompt inside Claude Code, published as an Artifact you can edit visually — click to select an element, adjust it in a properties panel, edit text inline, undo and redo. It is an early preview of Claude Design's canvas editor brought into Claude Code, usable from the terminal or the VS Code extension.

I want to be precise about what I'm working from, because there's a lot of hand-wavy coverage of this. Here is the skill's own declared behaviour, straight out of the skill listing in my install:

Create a design canvas — a multi-artboard visual design published as an Artifact that runs Claude Design's canvas editor (an early preview of Claude Design inside Claude Code). You DRAFT the design as .dc.html artboards laid out on one pan/zoom canvas; where saving is enabled for the user's account they refine every element visually (click-to-select, a properties panel, inline text editing, undo/redo) and Save publishes a new version for everyone, otherwise they get a view-and-export (PNG/PDF) preview of your draft.

A few things fall out of that description that matter more than they look.

The artboards are .dc.html files. Not a proprietary binary. Not a locked scene graph. HTML documents with a design-canvas extension, sitting in your working directory where you can read them, grep them, and commit them. That single format choice is why the rest of the workflow composes so well — I'll get to that.

It is multi-artboard by default. You are not getting one page. You are getting a canvas with several boards on it, which is the right primitive for the thing designers actually do: put the mobile version next to the desktop version next to the dark variant and look at them together. Single-output AI design tools have been getting this wrong for two years.

Save publishes a new version for everyone. The canvas is a shareable artifact with permission controls and live commenting. Somebody with the link can leave a comment on a specific element, the way they would in Google Docs or Figma. That is the difference between "I generated a mockup" and "my client reviewed the mockup."

And there is a graceful downgrade. If saving isn't enabled on the account, you still get a view-and-export preview — PNG or PDF out. You don't hit a wall; you hit a narrower door. I appreciate tools that degrade honestly instead of erroring.

The canvas covers more than websites, too. UI mockups and screen flows, landing pages, marketing and social graphics, and print pieces — posters, flyers, brochures as single-page artboards, memos and reports as one flowing artboard. It is a general layout surface that happens to be very good at web.

That's the mechanics. Now the part that actually changes how you work.

Why this beats standalone Claude Design: it starts warm

Here's the thing about standalone Claude Design at claude.ai — and I say this as someone who has genuinely enjoyed using it: every session starts cold.

You open it. It knows nothing about you. It doesn't know your brand uses #8B5CF6 through #06B6D4 on a slate background. It doesn't know your body copy is Inter and your display face isn't. It doesn't know that your four brands each have a distinct palette and that mixing them is the one unforgivable sin. So you tell it. Then you look at what comes back, and you tell it again, more specifically. Then a third time. By round four you're usually there, and you've spent most of your session re-teaching a tool facts you already wrote down somewhere.

Now run the same request through /design inside Claude Code.

Claude Code already read your CLAUDE.md. It already has access to your design system files, your brand book, your stored tokens, your memory files, your business data — every artifact sitting in the workspace. The skill inherits that whole context. So the first output isn't a generic guess it has to iterate away from. It's already using your typography scale, your colour ramp, your spacing rhythm, your voice in the placeholder copy.

The iterative back-and-forth doesn't get faster. It largely stops being necessary.

I've written before about how context beats configuration when working with AI agents, and this is the cleanest demonstration of that principle I've hit in a design tool. The model didn't get better at design between the standalone app and the skill. It got better inputs. Same engine, warm start.

Which raises an obvious and slightly uncomfortable question: what happens when your workspace context is thin?

The uncomfortable part: garbage context in, generic design out

If your repo has a three-line CLAUDE.md that says "this is a Next.js app, use TypeScript," then /design inherits three lines of nothing and produces something that looks like every other AI-generated landing page. Purple gradient. Big centred hero. Three feature cards. Rounded-2xl everything.

I've seen that output. It's competent and it's forgettable, and it's not the skill's fault.

The context inheritance is a multiplier, and multipliers work on whatever you feed them. This is why the "second brain" framing that keeps circling this topic isn't fluff — it's the actual prerequisite. If you want /design to produce something that could only be yours, you need to have written down what "yours" means, in files, in the workspace, before you ever type the slash command.

Concretely, the files that pay off:

• CLAUDE.md — project conventions, stack, and critically the tone. Mine says things like "no filler comments" and "match existing project conventions first." Design output picks up on that discipline.
• A design system file — tokens, not vibes. Colour ramps with names and hex values. A type scale with actual sizes. Spacing units. Border radius values. Shadow definitions. If it's ambiguous to a human designer, it's ambiguous to the model.
• A brand book — the stuff that isn't tokens. What the brand sounds like. What it refuses to look like. Reference sites you admire and, more usefully, the reason you admire them.
• Business data — real product names, real pricing tiers, real testimonials. This is the difference between "Lorem ipsum feature" and a hero section you could ship on Tuesday.

I built mine incrementally, the same way I built the second brain that writes my PRs — one file at a time, each one added the first time I noticed myself explaining the same thing twice. That's the trigger. Explaining something twice means it belongs in a file.

Side note — I resisted writing a brand book for about a year on the grounds that it felt like corporate theatre for a one-person operation. I was wrong, and specifically I was wrong in a way that cost me hours. Every AI design session I ran was me verbally reconstructing a brand book from memory, badly, under time pressure. Writing it down once was strictly cheaper.

Which brings us to what I actually built with the thing.

The Robo Nuggets test: what the canvas gave me

The prompt was deliberately underspecified. I wanted to see the floor, not the ceiling.

What came back was a landing page with a dark mode and a light mode, and the first thing I checked was whether the light mode was a real design or a dark mode with the colours flipped. It was a real design. The contrast relationships had been reconsidered — the accent colour that popped against a near-black background had been darkened for the light variant so it still carried against white. That is a small thing that separates people who understand colour from people who understand CSS.

Then I started editing.

Click-to-select works the way you'd expect from a design tool, not the way you'd expect from a code tool. Click a heading, the heading selects. Not the section. Not the wrapper div. The heading. The properties panel opens on the right with the properties that actually apply to that element — typography controls for text, spacing and fill for containers.

Inline text editing is direct. Double-click, type, done. No round-trip through the model, no "please change the headline to X" prompt, no waiting for a regeneration that might quietly restyle three other things while it's in there. This is the single biggest quality-of-life difference from prompt-only design tools, and it's not close. Prompt-only editing for small changes is like editing a document by describing your edits to someone over the phone.

Undo and redo exist and behave. I say this like it's a low bar. It is a low bar. A remarkable number of AI generation tools do not clear it.

Where I pushed and found the edges: the further you get from "web layout" the more you're steering. Print pieces work — the skill explicitly handles posters, flyers, brochures as single-page artboards — but the typographic conventions of print are less native to it than the conventions of a landing page. Complex multi-state screen flows need you to be explicit about the states you want boarded. It does not read your mind about interaction design, and I'd be suspicious of any tool that claimed to.

Also worth saying plainly: this is an early preview. The skill's own description says so. Treat it as a workflow you're adopting early, not a stable dependency you're betting a client deadline on without a fallback.

Now the part I didn't expect.

Skill composition: calling other skills from inside the design flow

This is where /design stops being a design tool and starts being something more interesting.

Skills compose. The design flow can invoke other skills mid-stream. The example that made this click for me: you're building a hero section, you want a background video behind it, and instead of leaving to generate a video somewhere else, downloading it, and wiring it in, you call a video-generation skill from inside the design flow and the result drops into the layout.

Think about what that implies structurally. Claude Code isn't a design tool with an integration. It's a skill platform where design is one skill among many, and skills can call each other. The design canvas is a participant in your toolchain, not a destination you visit.

That composition model is why the .dc.html format choice matters so much. Artboards that are HTML files can be read by any other skill, transformed by any script, committed to git, diffed in a pull request, and post-processed by whatever you want. A proprietary format would have made composition a vendor feature. HTML makes it a property of the system.

I've been mapping this pattern across my whole setup — how Claude Code quietly became a design platform through exactly this kind of accumulation. /design is the most visible piece of that, but it's the composition that carries the leverage.

If you'd rather have someone build this setup — the context files, the design system, the skill composition — from scratch for your team, I take on that kind of engagement. You can see what I've built at fiverr.com/s/EgxYmWD.

There's one more step in the loop, and it's the one that closes it.

From prompt to live site without leaving the terminal

The canvas is nice. The canvas that ships is the point.

Because you're already inside Claude Code, deployment is a command away — one instruction hands the finished site to a host like Vercel and you get a live URL. No manual export. No downloading a zip. No copying files into a separate repo, fixing the paths, and re-testing. The design lives in the same workspace as the deploy tooling, so the handoff between "designed" and "deployed" is just... not a handoff.

Count the tool switches in a conventional flow: design tool → export → code editor → repo → build → host → browser. That's six context switches, and every one is a place where something gets lost in translation or a decision gets quietly re-litigated.

The /design flow collapses that to: prompt → canvas → refine → deploy. Same window.

I want to be careful not to oversell this. Deployment being one command doesn't mean your production concerns evaporate. You still need to think about performance — an AI-generated hero with an uncompressed background video will wreck your Largest Contentful Paint regardless of how elegant the layout is. You still need to check the render on a real phone, not a resized browser window. You still need to verify contrast ratios against WCAG rather than trusting that the palette "looks accessible." The skill removes the friction of shipping. It does not remove the responsibility of shipping well.

That distinction is the one I'd tattoo on the inside of my eyelids after two years of watching people ship AI-generated frontends. Speed to production is not the same as readiness for production.

Where the Claude Code /design skill does not replace your existing tools

I'd be doing you a disservice if I let the last section stand without the counterweight, so here's the honest boundary.

It is not a Figma replacement for team design work. Figma's value at this point isn't the drawing surface — it's the component library, the variants, the shared file history, and the fact that four people can be in the same file arguing about a button at the same time. The /design canvas has commenting and permissions, which covers review. It doesn't cover collaborative authoring at that depth, and I don't think it's trying to.

It is not a substitute for a component system. The artboards are HTML. Beautiful, editable, exportable HTML — but a landing page composed on a canvas is not the same artifact as a typed React component library with props, states, and tests. For marketing pages and one-off layouts, that gap doesn't matter. For a product surface that fifteen engineers will extend for three years, it matters enormously. Use the canvas to decide what it should look like, then build the real components.

It inherits your context, including your bad context. If your design system file contradicts itself — two competing greys, a type scale with a gap in it — the output will faithfully reproduce your confusion. There's a version of this where the skill becomes a diagnostic: generate something, look at what's inconsistent, and trace it back to the file that's lying. I've actually used it that way twice now, and both times the design problem was a documentation problem.

And the review loop still needs humans. Commenting on an artifact is not the same as a designer looking at the kerning on your wordmark. I've written at length about why AI web design still needs human oversight, and nothing about a faster canvas changes that argument. It changes how quickly you arrive at the thing a human should review.

None of these are complaints. They're the shape of the tool. Knowing the shape is what lets you use it at full speed without walking into a wall.

What I'd tell you to do this week

If you want /design to give you something worth keeping rather than something worth screenshotting, do these four things in this order:

1. Write the design system file first. Before you touch the skill. Tokens with names and values — colours, type scale, spacing, radii, shadows. Half a page is enough to start. Ambiguity in this file becomes genericness in the output.
2. Put your real content in the workspace. Actual product names, actual copy, actual pricing if it exists. The model will use what's there. Give it something better than lorem ipsum to reach for.
3. Run /design on something low-stakes first. An internal dashboard. A side project landing page. A Robo Nuggets. Learn where the properties panel is faster than a prompt and where the reverse is true, on work where being wrong costs you nothing.
4. Then check the boring things. Contrast ratios. Mobile render at 375px. Image weight. Focus states on every interactive element. The canvas will not do this for you and neither will the deploy command.

Do those and the thing that surprised me will probably surprise you too: the output stops looking like AI output. Not because the model got better, but because you finally told it who you are in a form it could actually read.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io