Clone a design you love — with the right guardrails

Lea's new project: a site that turns heads

Lea's content system runs on its own — and her traffic is climbing. Problem: her homepage, cobbled together two years ago, can't keep up. She's spotted the site of a Japanese tea brand whose design dazzles her: an airy layout, a soft palette, elegant typography. She'd love that level of polish for her own brand. The good news: Claude Code reads images. This chapter's method lets her analyze that design, extract its principles, and rebuild her version — not a copy.

Hold on to this distinction right now, because the whole chapter rests on it: you don't clone a site, you clone what makes it good — its grid, its proportions, its rhythm, its visual hierarchy. The content, the brand colors, and the images will be Lea's. It's the difference between learning from a master and plagiarizing their painting.

Step 1: capture and analyze

Start with screenshots of the admired site: the full page, then zooms on the key areas (header, hero section, product grid, footer). Drag them straight into Claude Code — it reads images natively, in the extension and in the terminal. But don't ask "make me the same site": you'd get a rough imitation. First request a structured analysis, because that's what turns a visual impression into usable specifications:

analyze this website screenshot like a senior designer.
give me a structured analysis:

1. LAYOUT: page structure, grid (number of columns, gutters), max content width
2. PALETTE: each color in hex, its role (background, text, accent, borders), usage ratios
3. TYPOGRAPHY: likely families, sizes (heading/subheading/body), weights, line height, casing
4. SPACING: the vertical rhythm between sections, the internal paddings of cards/buttons
5. HIERARCHY: in what order the eye travels, and which devices create that order (size, contrast, space)
6. SIGNATURE: the 3 choices that give this design its personality

generate NO code for now.

The "generate no code for now" is deliberate: it's chapter 2's Plan Mode applied to design. You first want to validate that the analysis captures what you love about this site. Read point 6 in particular — the "signature" — and correct it if needed: "no, what I love most is the contrast between the huge photos and the tiny text." That conversation frames everything that follows.

Step 2: extract the design tokens

Analysis validated, we convert it into design tokens: CSS variables that codify every visual decision (colors, sizes, spacing). This is the step that changes everything compared to naive cloning: tokens separate the design system (reusable) from the values (which Lea will replace with her own). Here's the full prompt:

from your analysis, generate a tokens.css file containing the design tokens as CSS variables:

:root {
  /* colors: background, surface, text, text-secondary, accent, accent-hover, border */
  /* type: families, sizes (modular scale), weights, line heights */
  /* spacing: a scale (xs, sm, md, lg, xl, 2xl) consistent with the observed rhythm */
  /* misc: radius, shadows, max content width */
}

constraints:
- every variable is commented with its role
- the spacing scale must be a real scale (constant ratio), not random values
- then propose a SECOND palette: same contrast logic, but with my brand colors (sage green #87A96B, cream #F5F0E8, brown #5C4033)

Look closely at the last constraint: we request the transposition to Lea's palette at this very step. The admired design provides the contrast logic (light background, saturated accent used sparingly, text almost black but not quite); the values become the brand's. This is the precise moment the project stops being a copy and becomes an informed creation.

Step 3: rebuild YOUR version

Only now do we build — with Lea's content: her products, her photos, her texts (which your /post skill already knows how to write in her voice). Request a page that consumes the tokens exclusively: no hard-coded color or size in the HTML. This discipline pays off twice: changing a token updates the whole site, and you can evolve the palette without touching the structure.

build my homepage in HTML/CSS using exclusively
the variables from tokens.css (no hard-coded values).

structure: clean header, hero section with my sunscreen line photo,
3-product grid, "commitments" banner, footer.
content: use the texts from content/home.md.
images: only the ones in the assets/ folder (my photos).

respect the analyzed layout and rhythm, NOT the original site's content.

Step 4: iterate by gaps

The first version will be close but not right — that's normal, and the worst reaction would be to ask for everything again in bulk ("it's not there yet, start over"). The right method is gap-based iteration: compare systematically, list, fix point by point. It's the same refinement loop as chapter 4 for the brand voice, applied to the pixel:

here's a screenshot of MY current page and the screenshot of the reference site.
compare the two like an art director and list the 10 most visible
differences, ranked by decreasing visual impact.

for each difference: what the reference does, what my version does,
and the precise fix (which token or CSS rule to change).

then fix them ONE BY ONE, showing me the result at each step.

The "one by one" serves the same purpose as in chapter 3's scoping: it makes every change observable. If a fix degrades the whole (it happens — the reference's perfect spacing can smother your denser content), you reject it in isolation instead of throwing out the whole batch. Two or three passes of this loop are usually enough to go from "resembling" to "professional polish."

Going further: analyzing the real structure of a public page

Screenshots show the rendering, not the mechanics. To understand how an effect is achieved (that grid that reorganizes elegantly on mobile, that header that condenses on scroll), you can ask Claude to fetch a public URL and analyze the real HTML/CSS — that's the WebFetch tool, which you authorized in chapter 2:

fetch https://example-brand.com and analyze the structure:
- how the product grid is built (grid? flex? breakpoints?)
- how the header handles scroll and mobile
- which CSS variables or naming conventions they use

goal: understand the TECHNIQUE to apply the same logic
to my page, with my tokens. copy no content and no assets.

flowchart LR
  A["Screenshot of the admired site"] --> B["Structured analysis (senior designer)"]
  B --> C["Design tokens: tokens.css"]
  C --> D["Rebuild with YOUR content and YOUR palette"]
  D --> E["Side-by-side comparison: 10 gaps"]
  E -->|"Fixes one by one"| D
  E -->|"Polish reached"| F["Lea's page goes live"]

The ethical and legal line: inspiration, not copying

Let's talk frankly about the line not to cross, because it's sharper than people think. Design ideas — a grid, proportions, a spacing rhythm, the principle of a soft palette — can't be owned: the whole web takes inspiration from the whole web, and that's how standards progress. By contrast, assets are protected works: logos, illustrations, photos, custom-drawn icons, texts. Copying them isn't inspiration, it's infringement — regardless of whether it was "just for inspiration" or whether Claude did it for you.

Technical guardrails: locking the project with allow/deny

A redesign project involves lots of commands: installing dependencies, local servers, file manipulations. It's the right time to deepen chapter 2's permissions with a real allow/deny policy written in .claude/settings.json — therefore committed and shared with anyone who joins the project:

{
  "permissions": {
    "allow": [
      "Bash(npm run:*)",
      "Bash(npm install:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "WebFetch(domain:fonts.google.com)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Read the deny list line by line, because each rule tells the story of an accident avoided: rm -rf (the recursive delete that takes out a whole folder on a badly built path), git push --force (which can overwrite shared history), and reading .env — yes, you can forbid Claude from reading a file: your API keys will never enter the context, and therefore never appear in a reply. And remember chapter 2: deny always beats allow, even if a broad allow rule covers it.

Complement it with CLAUDE.local.md for your personal project preferences: "the preview server runs on port 4321," "my reference screenshots are in ~/Desktop/refs/." Those details belong to you; they have no place in the project's shared memory.

Permission or hook: two complementary locks

You now have two protection mechanisms, and it's useful to see precisely how they fit together:

The division rule: what's forbidden always and everywhere belongs to permissions — it's binary, so declare it once. What depends on the content ("does this post exceed the limit? does it respect the voice?") belongs to a hook, because you have to examine to decide. The two layers together, plus human validation at the leverage point (chapter 7), form your system's defense in depth: Lea can let Claude work fast precisely because the guardrails never sleep.