I design every page on my site in Claude Design first, then Claude Code builds it as native WordPress blocks. The designs live in the same Git repository as the theme, so the mockup and the code that builds it sit side by side.
In short:
- A page starts as an HTML mockup in Claude Design, using my real colours, fonts and photos.
- A skill turns the design into WordPress’s own blocks, matching every value to the theme’s design system first.
- The goal is what the WordPress editor would write itself, not a pixel-perfect copy.
What is Claude Design?
Claude Design is a tool where Claude builds visual designs, like web pages, from a conversation. I describe a section, it produces a mockup, and I tweak it in chat until it looks right. When it’s done, I export a handoff: a zip with the HTML, the CSS, the images and a short README describing the design.
The first one I built was my home page header, hero and footer, on 29 September. The About page followed on 9 October, then the blog in late October.
What does Claude Design start from?
A style guide. Claude Design can keep a design system: the colours, fonts, spacing and shapes of a site, plus a written brand book with rules. Mine is one page, and you can look at it here.
It’s short on purpose. The whole look is off-white, ink and one orange, set in one typeface. The brand book turns that into rules Claude can follow, like “every heading is regular weight”, “anything clickable is a pill” and “no gradients”. It also covers how I write: first person, sentence case, and honest placeholders instead of invented numbers.
Every mockup starts from it, so a new page looks like my site without me repeating myself. It’s also what the build step later checks values against (see “How a design becomes blocks”).
The loop
- Design. Claude writes the mockup, using my real design system and my own images.
- Preview. I look at it, sometimes with two versions to compare.
- Choose. I pick one version and mark the other as not chosen.
- Upload the images. Photos go into WordPress’s media library before anything is built.
- Build. Claude turns the design into blocks and checks it in light mode, dark mode and at phone width.
- Review, then push. I check it on my laptop, and only then does it go live.
Why the designs live in Git
The designs sit in a design/ folder inside the theme’s repository. They have one history with the code, and anyone working on the theme can see them. The deploy from part 4 skips that folder, so the designs never reach the live server.
Most teams keep designs in Figma. Mine are plain HTML files, which Git handles well, so keeping them with the code was simpler.
Sample content is marked as sample. Real titles and dates come from my old site. Where something is missing, the mockup shows a dashed “to fill in” box instead of invented text.
How a design becomes blocks
A design export is just HTML. WordPress pages are built from blocks: a heading, a paragraph, an image, a group of columns. Turning one into the other is the job of a skill called design-to-blocks. I pass it the zip and say “use the design-to-blocks skill”. No other instructions.
The most important step happens before any blocks are written. Every value in the design gets matched to the theme’s design system, the colours, sizes and spacing in theme.json. A value that’s close to an existing one gets rounded to it. A value that’s genuinely new gets added. A value that does nothing gets dropped. So 28px gaps in a mockup become 30px, because 30px is a size the theme already has.
Then Claude builds with the plainest tool that works, in this order:
- A setting from
theme.json. - A style every block of that type shares.
- A named style I can pick in the editor, like “Card” or “Dark panel”.
- A few lines of CSS, only for what WordPress can’t do on its own.
- A custom block, as a last resort.
Why “native” matters
You can make a WordPress page look like any design by writing lots of custom CSS. It works until someone opens it in the editor. Then the editor doesn’t recognise the code, shows “Attempt recovery” warnings, and styles can’t be changed with the controls.
Building with the editor’s own blocks and settings avoids that. On 17 October I rebuilt my header, footer and About page this way. My extra CSS file went from 182 lines to 27.
Claude also checks each block with the same test the editor runs, before I open the page. That caught a hand-written size on my logo that would have triggered “Attempt recovery”.
Where it still needs me
- Breakpoints differ. WordPress stacks columns at its own screen width, not the design’s. Some layouts shift a little on tablets.
- Rounding is visible if you look. Matching values to the design system means a few things are a couple of pixels off the mockup. I’d rather have that than one-off values everywhere.
- Taste. Claude makes the mockups, but I still decide what goes on the page, and say when something feels off.
Skills I used
These are the skills I used for this part. A skill is a set of written steps Claude follows when a job comes up.
design-to-blocks: turns a Claude Design export into native WordPress blocks, matching every value to the theme’s design system first.
Skills or documentation?
I also keep a living note in my vault about this workflow. Every time a design hits a case the skill didn’t cover, I add the nuance to the note, and Claude reads it as reference. It’s another way to give Claude knowledge, and it works differently from a skill:
| Skill | Documentation note | |
|---|---|---|
| What it holds | The steps for one job | Background, reasons and exceptions |
| When Claude uses it | When that job comes up | When I point it at the note |
| How it changes | I edit it when the steps change | It grows with every new case |
| Best for | Jobs that go the same way each time | Cases with many exceptions and judgement calls |
I use both. The skill carries the steps. The note carries the why and the edge cases, because there are too many of them to fit into a fixed list of steps, and I’m still finding new ones.
Next in the series: what happens when you edit a page in WordPress’s editor, and why that’s a problem for tracking changes.
