One File That Changes How Claude Knows You

The session always started the same way. I'd open Claude Code, load the Dead Letter codebase, and spend the first ten minutes re-explaining the stack. Next.js App Router. Supabase SSR client — not the old one. Anthropic SDK directly, no LangChain. RLS always on. Zod for all input validation. No Firebase suggestions. No Prisma suggestions.

Then I'd get a reasonably good answer. Then the next session I'd do it again. Then again. Forty sessions a week across four products. Same explanation. Different Claude instance. No memory.

This is the actual cost of AI-assisted development that nobody talks about: not the token cost, not the hallucination rate, not the occasional wrong answer. It's the context tax. The overhead of re-establishing who you are, what you're building, and what you're not allowed to build — every single session.

That's roughly 400 minutes a week. Six-plus hours. One full workday, every week, spent re-explaining the same architecture to a model that already knows how to use it — I just haven't told it yet.

WHAT CLAUDE.MD ACTUALLY IS

Claude Code reads a file called CLAUDE.md at session start. If you place one in your project root, Claude reads it before you type a word. If you place one at ~/.claude/CLAUDE.md, it fires before every session, every project, globally.

Most people who know about this use it like a system prompt. "Be concise." "Use TypeScript." "Prefer functional components." That's not wrong, but it misses what the file can actually do.

A system prompt tells Claude how to respond. A CLAUDE.md file tells Claude who you are.

These are different jobs. One shapes tone and output format. The other shapes the entire operating context — what you're building, what you've already tried, what you're not allowed to build, what the naming conventions are, what the deployment target is, what the database schema looks like, what the brand tokens are.

Done right, a CLAUDE.md file means the first response Claude gives you in any session is as good as the response you'd get mid-session after an hour of context building. The context is already there. It's in the file.

THE STRUCTURE THAT WORKS

I've iterated on this across four products and hundreds of sessions. The structure that consistently produces the best results has six sections, in this order:

1. Identity and stack

Who you are, what you're building, exactly what technologies are in play at version-level specificity. Not "I use React" — "I use Next.js 14 App Router with TypeScript. Not Pages Router. Never Pages Router."

2. What not to build

This is the section most templates skip. It's also the most valuable. Every experienced developer has patterns they fall into — refactoring working code, researching instead of shipping, suggesting alternative libraries when the current one is fine. Name these explicitly. Claude will flag them when they appear in a session.

## What Not To Build

NEVER suggest these unless explicitly asked:
- Alternative libraries to what's already in the stack
  (no Prisma, no tRPC, no React Query, no Zustand)
- Refactors of code that ships correctly
  (if it deploys and doesn't break, leave it)
- Abstractions before they're needed
  (three uses minimum before extracting)
- Documentation for unbuilt features
  (document what exists, not what's planned)

Flag these as GRAVEL if they appear in session scope.

3. Naming conventions and vocabulary

Every codebase has naming patterns. Every product has doctrine vocabulary. When Claude knows both, it uses them consistently across every response. Database tables start with dl_ on Dead Letter. Components follow a specific casing convention. The doctrine vocabulary — BRICK, GRAVEL, POUR — appears in comments, commit messages, and session logging consistently because it's defined in the file.

4. Deployment and infrastructure

Where does the code run. How does it get there. What the environment variables are called. What the Supabase project URL structure is. Which Vercel project maps to which product. Claude stops suggesting Firebase the first time. It never suggests it again.

5. Session types

Not all sessions are the same. A BUILD session has different constraints than a FIX session or a THINK session. Declaring the session type at open means Claude knows whether to produce deployable output, debug aggressively, or explore architecture options. The behavioral constraints adjust accordingly.

6. Enforcement rules

What Claude should flag. When it should push back. What constitutes scope creep in this specific project. The enforcement section turns Claude from a yes machine into something closer to a senior engineer who knows when to say "that's out of scope for today."

THE COMPOUND STACK

After two years of iterating on this across four live products, I packaged what works into ten templates. Not role definitions — behavioral systems. Each one is a complete CLAUDE.md file with the full six-section structure, [CUSTOMIZE] markers where your specifics go, and enforcement rules that came from real sessions where things went wrong.

Plus three behavioral skills — Gravel Detector, BRICK Logger, Scope Guard — two session rituals, and a README with setup guide and combination patterns.

One-time. $27. Instant ZIP. No account required.

The [CUSTOMIZE] sections are explicit — you fill in your stack, your product names, your specific not-to-build list. In most cases that takes under 20 minutes. After that, every session starts with Claude already knowing who you are.

BEFORE (session cold start):
Me:    "Help me build a webhook handler"
Claude: [generic Express.js code, wrong stack,
         suggests firebase-admin, imports Prisma]
Me:    "No, Next.js App Router, Supabase service client,
         no ORMs, Zod for validation, HMAC verify..."
Claude: [10 minutes later, actually useful response]

─────────────────────────────────────────────
AFTER (CLAUDE.md loaded):
Me:    "Help me build a webhook handler"
Claude: [Next.js route handler, Supabase service client,
         HMAC-SHA256 verify, Zod schema, correct patterns]
         First response. No correction required.

The context tax doesn't disappear entirely. You still need to state what you're working on in each session. But the infrastructure knowledge — the stack, the constraints, the enforcement rules — that's in the file now. It loads before you type a word.

Six hours a week was the cost. One file was the fix.