The demo is always the easy part.
You prompt Claude Code, it builds something that looks polished. You show it to someone and they're impressed. Then you try to build a second page. Or you come back to the project the next day. And slowly — sometimes all at once — the brand starts slipping. Different fonts. Made-up spacing. Components that don't match what you built last week.
That's not a Claude Code problem. That's an architecture problem. And there's a straightforward fix.
The Real Issue: Claude Code Has No Memory
Every session starts completely blank. It doesn't know what fonts you chose yesterday, which components are approved, what copy voice you've been building, or what mistakes it made on the last build — unless you tell it. Every. Single. Time.
Most people respond to this by prompting harder. Better system prompts, longer instructions, more context pasted into the chat. It helps — but it doesn't scale. And it breaks the moment someone else opens the project.
The better response is to stop relying on prompts and start building a system.
That system is what we call the Context Stack.
"The Context Stack is a seven-file system that gives Claude Code persistent memory across build sessions — so every page stays on-brand without re-prompting from scratch."
What the Context Stack Is
The Context Stack is a set of seven files that live directly in your project repository. Claude Code reads them before every build session. Together, they give it everything it needs to remember: design tokens, component rules, copy voice, approved patterns, and a living log of mistakes it's already made.
The result: output that stays consistent across sessions, across pages, and across people. Once the files are in place, you're not fighting the tool — you're directing it.
This isn't a plugin. It's a file structure and a process. Seven markdown documents and one CSS file. The sophistication is in what goes inside them and how Claude Code is instructed to use them.
The Seven Files
File 1: CLAUDE.md — The Briefing
This is the only file Claude Code reads automatically at the start of every session. It's the briefing that happens at the top of every meeting. Keep it under 40 lines. Its job: tell Claude Code what project it's working on, which other files to load, and what's already been built.
Think of it as the session handoff document. It answers: Where are we? What are the rules? What's still open?
# [PROJECT NAME] — Claude Code Context
## What this project is
[One sentence. What the site is for and who it's for.]
## Files to read before every build
- design-tokens/tokens.css — all CSS variables. Use these for everything.
- [CLIENT]-BUILD-RULES.md — 10 design rules. Follow them without exception.
- COPY-VOICE-RULES.md — language rules, banned words, CTA patterns.
- [CLIENT]-component-blueprint.html — the only components you may build.
- docs/GOTCHAS.md — mistakes made on this project. Do not repeat them.
## Current build state
- [ ] Component blueprint
- [ ] Home page
- [ ] About page
- [ ] [Add pages as needed]
## Critical rules
1. Never build a component that isn't in the blueprint.
2. Never use hardcoded pixel values — tokens only.
3. Never write copy that isn't in the page doc.
4. When in doubt, ask before building.Keep this file up to date as pages are completed. That build state checklist is what tells Claude Code what it has already done and what's still open.
File 2: [CLIENT]-BUILD-RULES.md — The Non-Negotiables
Ten numbered rules. Each one eliminates a category of design decision so Claude Code cannot improvise. The key is specificity. "Use good spacing" is not a rule. "All section padding uses var(--space-section) — no hardcoded pixel values, ever" is a rule. One correct behavior. Zero ambiguity.
After every build, review these rules. If Claude Code found a way around one, close the gap and document it.
# [CLIENT] Build Rules
Read this file before every build. These rules are not suggestions.
1. All colors must use CSS variables from tokens.css. Never use hex codes directly in HTML or CSS.
2. All spacing (padding, margin, gap) must use spacing tokens from tokens.css. No hardcoded pixel values.
3. Only build components that exist in the component blueprint. Do not invent new layouts or patterns.
4. Follow the section background alternation pattern: [dark/light/dark/light OR light/dark/light/dark].
Do not break this pattern.
5. Typography: one display font for headings, one body font for body copy. No other fonts.
6. One accent color for all interactive elements: buttons, links, hover states. Never use a second color
for CTAs.
7. Border radius: [your value, e.g., "4px sharp" or "8px soft"]. Apply it everywhere, consistently.
8. No background patterns, gradients, or decorative elements unless they exist in the blueprint.
9. Mobile-first. Every section must work at 375px minimum without horizontal scroll.
10. Never write copy that isn't provided in the page doc. Use visible [TODO: copy needed] placeholders.
File 3: COPY-VOICE-RULES.md — The Brand Voice Filter
Without this file, every page sounds like it came from an AI marketing generator — transform, results-driven, unlock your potential. With it, every page sounds like the brand.
The most important section is the banned phrases list. "Don't sound corporate" is not actionable. "Never use: transform, elevate, unlock, seamlessly, results-driven, game-changer" is. Be specific. Every brand has a list. Build yours.
# [CLIENT] Copy Voice Rules
## Brand voice in three words
[Example: direct, skeptical, specific]
## Who is reading this
[One paragraph. Job title, pressure they're under, what they're trying to get done.
Write it like a person, not a persona card.]
## How this brand sounds
- Short sentences. No more than 20 words as a rule.
- Specific over general. Numbers beat adjectives.
- Active voice always.
- No throat-clearing. Get to the point.
## Phrases this brand never uses
Never write any of the following:
- "Transform your [anything]"
- "Unlock [anything]"
- "Seamlessly"
- "Best-in-class"
- "Game-changer"
- "Results-driven"
- "Take it to the next level"
[Add your own. Every brand has a list of these.]
## CTA rules
- Primary CTA: [label] → [destination]
- Secondary CTA: [label] → [destination]
- CTA copy should say what happens next, not what the user will feel.
Right: "See a 15-minute demo"
Wrong: "Experience the difference"
## Headlines
- Lead with the problem or the outcome, not the feature.
- If it could appear on a competitor's site, rewrite it.
File 4: design-tokens/tokens.css — The Single Source of Truth
Every color, font, spacing value, border radius, and shadow lives here. One CSS file. Everything else points to it.
The rule is absolute: nothing in HTML or CSS uses a hardcoded value that belongs in tokens. If Claude Code outputs padding: 48px instead of padding: var(--space-section), that's a violation — and it goes directly into GOTCHAS.md.
When the brand decides to change a color, it's one line in this file. Every page updates. No hunting through components.
/* ============================================================
[CLIENT] Design Tokens
Single source of truth for all visual values.
Every other file reads from here.
============================================================ */
:root {
/* — Colors — */
--color-bg-primary: #[your dark or light base];
--color-bg-secondary: #[your surface color];
--color-bg-accent: #[your accent/CTA color];
--color-text-primary: #[your main text color];
--color-text-muted: #[your secondary text color];
--color-border: #[your border color];
/* — Typography — */
--font-display: '[Your heading font]', sans-serif;
--font-body: '[Your body font]', sans-serif;
--text-xs: 0.75rem; /* 12px */
--text-sm: 0.875rem; /* 14px */
--text-base: 1rem; /* 16px */
--text-lg: 1.125rem; /* 18px */
--text-xl: 1.25rem; /* 20px */
--text-2xl: 1.5rem; /* 24px */
--text-3xl: 1.875rem; /* 30px */
--text-4xl: 2.25rem; /* 36px */
--text-5xl: 3rem; /* 48px */
/* — Spacing — */
--space-1: 4px;
--space-2: 8px;
--space-3: 12px;
--space-4: 16px;
--space-6: 24px;
--space-8: 32px;
--space-10: 40px;
--space-12: 48px;
--space-16: 64px;
--space-20: 80px;
--space-section: 96px; /* standard top/bottom padding for full sections */
/* — Border radius — */
--radius-sm: 4px;
--radius-md: 8px;
--radius-lg: 12px;
--radius-full: 9999px;
/* — Shadows — */
--shadow-sm: 0 1px 2px rgba(0,0,0,0.05);
--shadow-md: 0 4px 12px rgba(0,0,0,0.10);
--shadow-lg: 0 8px 24px rgba(0,0,0,0.15);
/* — Layout — */
--container-max: 1200px;
--container-padding: var(--space-8);
}
File 5: [CLIENT]-component-blueprint.html — The Approved Component Library
Every layout pattern Claude Code is allowed to use, rendered in a single HTML file. If a component isn't in here, it doesn't get built. Full stop.
You don't write this file manually — you generate it in Claude Code after tokens.css is in place, review it in a browser, correct anything wrong, then lock it. Once it's locked, it's law.
The prompt to generate it:
Read design-tokens/tokens.css and [CLIENT]-BUILD-RULES.md.
Build a single HTML file called [CLIENT]-component-blueprint.html that demonstrates
every major component for this project. Include:
- Navigation (desktop + mobile state)
- Hero — full-width variant
- Hero — split layout (content left, visual right)
- Feature cards — 3-column grid
- Stats / metrics row
- Testimonial block
- CTA section — centered variant
- FAQ accordion
- Footer
For each component:
- Use only tokens from tokens.css. No hardcoded values.
- Add an annotation box below each component showing: component name,
key CSS variables used, any layout notes.
- Mobile-optimize everything.
Do not invent any components not in this list. Do not use placeholder images —
use solid color blocks with dimensions noted.Review the output carefully before moving on. Every component you let slide here will compound across every page you build.
File 6: docs/pages/[page-name].md — The Page Brief
One file per page. Written by a human before every build session. This is the brief Claude Code executes from.
The most important rule: write the actual copy before building. Don't ask Claude Code to write copy. It will produce serviceable AI copy that sounds like every other AI copy. Write the headlines yourself. Write the CTAs yourself. Put them in the page doc. Claude Code places them on the page exactly as written.
The quality of this document determines the quality of the page.
# [Page Name] — Page Doc
## What this page does
[One sentence. What is the visitor supposed to understand or do by the end of it?]
## Conversion goal
[One action. What does success look like?]
## Section sequence
### 1. Navigation
Standard nav. Read from blueprint.
### 2. Hero
Headline: [Your actual headline here]
Subhead: [Your actual subhead here]
Primary CTA: [Button label] → [URL or anchor]
Secondary CTA: [Button label] → [URL or anchor]
Visual: [Describe what goes here — photo, screenshot, illustration]
### 3. [Section name]
Purpose: [What this section needs to accomplish]
Headline: [Copy]
Body: [Copy]
[Add as many content fields as needed]
### 4. [Next section]
[TODO: copy needed]
[Use this placeholder when copy isn't ready. Claude Code will build the section
with a visible placeholder and not invent content.]
## Notes for this build
[Any specific constraints, things to watch for, or decisions that differ from defaults]
File 7: docs/GOTCHAS.md — The Institutional Memory
Start this file empty. It grows as you build.
Every time Claude Code makes a mistake you catch and correct, add one line. What it did wrong. What it should have done instead. After 15–20 builds, this file becomes one of the most valuable things in the project. Each entry is a mistake that will never happen again — on this client or any client.
# GOTCHAS — [CLIENT]
Read this file before every build. Do not repeat any mistake listed here.
[Start adding entries as they happen. Examples:]
- Used letter-spacing: 1px hardcoded in trust bar label. Use var(--tracking-wide) instead.
- Built a 4-column grid that isn't in the blueprint. Only use components from the blueprint.
- Wrote hero copy instead of using [TODO] placeholder when page doc said copy wasn't ready.
- Applied background-color: #1a1a2e directly instead of var(--color-bg-primary).
- Used padding: 96px instead of var(--space-section).The Build Loop
Once the Context Stack is in place, every page follows the same sequence:
- Write the page doc first. Section order, approved copy, conversion goal. This is the human work. It happens before the machine work.
- Open Claude Code and confirm it loaded context. Start every session with: "Read CLAUDE.md and confirm you understand the project. Tell me which pages are complete, which are in progress, what files you've loaded." If anything sounds off, paste CLAUDE.md directly and confirm before building.
- Run /build-page [page-name]. Claude Code reads all spec files and builds the HTML. Output goes to your project folder.
- Open the HTML in a browser. Check it against the component blueprint side by side. Look for anything that doesn't match.
- Run /review-page [page-name]. This QA pass catches what the eye doesn't — token violations, hardcoded values, components that don't exist in the blueprint.
- Run /commit. Creates a PR in GitHub. Review and merge.
- Log every mistake before closing. One line per mistake in GOTCHAS.md. Don't skip this step. The compounding value is real.
The Skill Files
The /build-page, /review-page, and /commit commands are custom skills — markdown files stored in .claude/skills/[skill-name]/SKILL.md in your repo. Claude Code reads them when you type the slash command.
Here's the starter for /build-page:
# Skill: /build-page
When this skill is triggered with a page name, do the following in order:
1. Read design-tokens/tokens.css
2. Read [CLIENT]-BUILD-RULES.md
3. Read COPY-VOICE-RULES.md
4. Read [CLIENT]-component-blueprint.html
5. Read docs/GOTCHAS.md
6. Read docs/pages/[page-name].md (use the page name provided)
Then build the page as a single HTML file named [page-name].html in the project root.
Rules:
- Only use components that exist in the blueprint
- Only use tokens from tokens.css — no hardcoded values
- Only use copy from the page doc — use [TODO: copy needed] for any missing sections
- Mobile-first. Every section must work at 375px minimum
- On completion, list every component used and confirm each exists in the blueprint
What This Produces
The first time you run a full build with the Context Stack in place and get back a page that actually looks like the brand — consistent tokens, correct components, right voice — the investment makes sense immediately.
But the compounding effect is what matters. We've used this approach to build production-ready landing pages where the component blueprint built on day one drives every page variation with zero drift. When the brand needs five campaign landing page variants, they build in hours instead of days.
We're also applying the same approach to a Pardot export skill — one command outputs any page into Pardot-formatted table code, ready to drop into the ESP. Ten pages, thirty seconds.
The system isn't magic. It's structure. Claude Code is capable of high-quality output — it just needs the scaffolding to stay consistent. The Context Stack is that scaffolding.
Getting Started
You don't need all seven files before your first build. Here's the fastest path to a working system:
- Start with tokens.css. Make your brand decisions and lock them here. This is the foundation everything else references.
- Write the build rules. Ten rules. No vague ones. If a rule can be interpreted two ways, rewrite it.
- Generate the component blueprint. Use Claude Code to build it, review it carefully, then lock it.
- Set up CLAUDE.md. Keep it short. Point to the three files above.
- Write one page doc. Just one. Build the page. See what breaks.
- Start GOTCHAS.md. It begins with zero entries. That's fine.
The copy voice rules and page docs grow with the project. Everything else is set up once.
The files shared here are starters. The real ones for your project will be more specific, more opinionated, and more valuable — because they'll reflect design decisions you've actually made and mistakes you've actually caught.
That's the whole point. The system gets smarter every build. The output gets tighter. And the gap between "AI-generated website" and "production-ready brand asset" closes fast.
If you're building with Claude Code and want to see how Mighty & True uses this approach to build client programs — see how our systems work →
