Give Claude a Brand Kit, Not a Prompt: The Spec File That Keeps 30 AI-Generated Pages From Looking Like 30 Different Agencies

I don't have live web search access in this session, so I'll write from established, well-documented practice around design tokens (W3C Design Tokens Community Group draft format, Tailwind config conventions, CSS custom properties) without inventing specific statistics or citing URLs I wasn't given. Any figures are kept general or framed as variable.

---

title: Give Claude a Brand Kit, Not a Prompt: The Spec File That Keeps 30 AI-Generated Pages Consistent slug: give-claude-a-brand-kit-not-a-prompt-spec-file excerpt: One Claude-built landing page looks great. Thirty of them, built across weeks and campaigns, drift into thirty different fonts, blues, and button styles. The fix isn't a better prompt — it's a design-token spec file the LLM consumes on every build. categories: AI-Native Publishing, Landing Pages, Brand Consistency metaTitle: keep AI-generated landing pages on brand with a design token spec metaDescription: Stop re-briefing Claude on your fonts and colors every build. Use a design-token spec file so every AI-generated landing page stays visually on brand. author: Michael Sacca

Here's the problem nobody warns you about until it happens: the first landing page Claude builds you is gorgeous. On-brand, tight, exactly the vibe. The tenth one — built three weeks later, for a different campaign, from a different conversation — uses a blue that isn't quite your blue, a heading font that isn't your heading font, and a button radius that's definitely not your button radius.

By page twenty you've got what looks like thirty different agencies competing for the account. Nobody did anything wrong. That's just what happens when every page is built from scratch inside a chat window with no memory.

We've covered pieces of this before — The Ad Is the Brief: How to Feed Your Ad Copy Into Claude So the Landing Page Mirrors It Word for Word solved message drift, and One Agent, Twenty Accounts: Running an MCP Landing Page Pipeline Across Client Campaigns solved scale. This post solves visual drift: the failure mode where every page is individually fine but the portfolio doesn't match.

The prompt isn't the system. The spec is.

Most people try to fix brand consistency the obvious way: they write a long prompt describing the brand and paste it at the top of every conversation. "Use our brand colors: navy #1B2A4A and coral #FF6B5B. Headings in a geometric sans-serif. Rounded buttons, generous whitespace..."

This works. Until it doesn't. Every conversation starts fresh, so the description has to be perfectly complete and perfectly consistent every time. Miss "the buttons are 8px radius, not 12px" once and you've got a page that's off. Claude has to interpret your prose every single build, and interpretation varies.

The fix is to stop describing the brand in words and start handing over a file that defines it in values. Designers have a name for this: design tokens. It's the same idea behind the config file in Tailwind or the :root variables block you've seen in CSS — one source of truth that every page consumes instead of re-deciding.

A token file looks like this:

{
  "color": {
    "brand.primary": "#1B2A4A",
    "brand.accent": "#FF6B5B",
    "surface.default": "#FFFFFF",
    "surface.muted": "#F5F6F8",
    "text.default": "#111827",
    "text.muted": "#6B7280"
  },
  "font": {
    "heading": "'Archivo', sans-serif",
    "body": "'Inter', sans-serif"
  },
  "radius": {
    "button": "8px",
    "card": "12px"
  },
  "spacing": {
    "section": "96px",
    "card-padding": "24px"
  }
}

Every value lives here. Nothing lives in the prompt. Nothing lives in Claude's memory of your last conversation. When the file changes, every future build changes with it — you don't hunt through thirty pages.

The spec file has three layers

What makes this actually work at scale is splitting the file into three tiers, from most stable to most flexible:

1. Core tokens (nobody touches these, including you)

Colors, fonts, logo rules, the exact button style. These are the brand. They change maybe once a year, and when they do, everything changes. Claude has no permission to alter these — not "slightly," not "for contrast on this one page."

2. Component definitions (the recurring parts)

Most of your pages share the same building blocks: a hero, a logo bar, a testimonial, a pricing block, a footer with the compliance language legal insists on. Define each one once, structurally:

hero:
  - h1, max 2 lines, uses font.heading
  - subhead, max 90 characters, text.muted
  - primary CTA button (style: core.button.primary)
  - optional secondary text link
  - background: surface.muted, no image by default

This is what stops the structural drift that's harder to spot than color drift — the page where the hero is suddenly centered when every other page is left-aligned, or the testimonial section that mutates into a carousel on one build and a static quote on the next. If you want the sections themselves to follow proven conversion structures rather than Claude's defaults, Landing Page Examples That Actually Convert — Steal the Structure, Then Have Claude Rebuild It for Your Offer pairs well with this layer: the example breakdown tells you what the sections should do, the spec file locks in how they look.

3. Campaign variables (the only thing that changes per page)

Headline copy, the offer, the image, the CTA text, the accent applied from the approved palette. This is the only part of the brief that should vary from page to page. If a build needs something that isn't in this layer, that's a signal the spec is missing something — fix the spec, not the page.

How to make Claude actually consume it

Having the file isn't enough. The failure mode is that Claude reads it once, nods, and then improvises the moment things get complicated. Three rules keep it honest:

Rule 1: Attach the file, don't paste it. Whether you're using Projects, a CLAUDE.md-style instruction file, or an MCP server that fetches the spec, make it a file the model loads — not prose it paraphrases. A file is a reference; a pasted paragraph is a suggestion.

Rule 2: Forbid new values explicitly. The most useful single sentence in your instructions is something like: "Use only the values in this spec. If a needed value is missing, stop and ask — do not invent a color, size, or font." Without that, Claude will quietly generate #3B82F6 because it's a blue it has seen a million times, and you'll never notice until the audit.

Rule 3: Make the output consume the tokens. Ask Claude to output CSS custom properties from your token file and reference them, rather than hardcoding hex values throughout:

:root {
  --color-brand-primary: #1B2A4A;
  --color-brand-accent: #FF6B5B;
  --radius-button: 8px;
}

.cta-button {
  background: var(--color-brand-accent);
  border-radius: var(--radius-button);
}

This is the quiet superpower of the whole approach: when a page hardcodes your colors, a rebrand means rebuilding thirty pages. When every page consumes the same variables, a rebrand means editing one file and re-rendering.

The drift audit: your five-minute pre-launch check

Even with a spec, builds drift — the fix is catching it before the page ships instead of after a client does. Add this to your review pass (it slots neatly into the checklist in Before You Deploy: The 12-Point Checklist for Code ChatGPT or Claude Handed You):

1. Grep for hex codes. Search the built page's CSS for #. Every hex you find should either be in your token file or inside the :root block. Anything else is drift.
2. Check font-family declarations. Same rule — only your two (or three) families should appear.
3. Screenshot-compare against the reference page. Pick your best page as the canonical reference. New pages should look like siblings, not cousins.
4. Check the shared sections. Footer, legal language, logo treatment — identical to the last build, character for character.
5. Confirm the component classes match. If page seven renamed .testimonial to .quote-block with slightly different padding, that's the structural drift starting.

This catches the mechanical drift. It can't catch the stuff the spec can't encode — that a page feels off because the imagery got moodier or the headline got shoutier. For that, you still need a human who knows the brand looking at the thing for thirty seconds. The spec makes that human review fast; it doesn't replace it.

One spec per client, one process for all of them

If you're running the multi-account pipeline, the token file is also what makes that pipeline safe. Each client gets their own spec; the agent loads the right one per account, and suddenly "build a landing page for campaign X" produces output that's automatically in that client's brand, because the brand isn't in the prompt — it's in the file the prompt points to.

The mental shift is this: a prompt is a one-time instruction to one conversation. A spec is a system that outlives the conversation. Prompt Claude, and you get a page. Hand Claude a brand kit and a set of component rules, and you get a production line — thirty pages, one brand, built across months, that still looks like it came from one very consistent agency.

Which, conveniently, is you.