How to make Claude Code build new pages that match your existing app

Description and use

A step‑by‑step workflow enabling Claude Code to generate pages that match an existing design system, preventing clashes with colors, fonts, and components.

Problem

Claude Code often generates pages that clash with an existing codebase, adding new fonts, colors, and styles that do not match the current design.

Outcome

Using the match-existing-style workflow reduced hard‑coded hex colors from 17/30 to 0, eliminated new fonts, increased use of project token classes, and cut page length from 499 to 247 lines.

Workflow

• 1. Provide a design source of truth (e.g., design-system.md) or rely on existing pages if no doc exists.
• 2. Survey the project: read design rules, tokens, component kit, two sibling pages, and copy voice.
• 3. Write a short style fingerprint (token names, fonts, radius, spacing, components, snippet).
• 4. Build by reusing existing components and tokens, avoiding new fonts, colors, or button styles.
• 5. Self‑check with grep for raw colors, palette classes, <button> tags, and font imports, and compare visually with sibling pages.

Evidence

Ask Claude Code to "add a pricing page" to a project that already has ten pages, and you often get a beautiful page that belongs to a different website.

Source

I hit this enough times across my own side projects ... that I stopped fixing pages after the fact and started fixing the instructions instead.

Source

The fix is to reverse the order: read the project first, write a short summary of its style, build only from what already exists, then check.

Source

I ran a small test: same project, same prompt, two subagents in separate git worktrees. One followed the official frontend-design skill, the other followed match-existing-style.

Source

In round 2 the generic-skill page also dropped the site's header (logo, language switch, sign-in) entirely, and came in at 499 lines versus 247.

Source