CLAUDE.md Examples and Template (2026)
Why CLAUDE.md examples matter more than the docs
The official CLAUDE.md docs explain syntax. They do not show you what a high-leverage CLAUDE.md actually looks like. The difference between a file that meaningfully improves Claude Code's output and a file that wastes tokens shows up in the structure, not the syntax.
This page does two things: it gives you a clean CLAUDE.md template you can copy and paste into any project right now, then walks through three annotated production examples to show what the sections look like when filled in. If you want the syntax-level reference rather than examples, our CLAUDE.md explained guide covers how the file works. For broader setup steps, the Claude Code setup guide has the full picture.
A CLAUDE.md template you can copy and adapt
Before diving into annotated examples, here is a clean starter template. Copy it, drop it in your project root as CLAUDE.md, and fill in the bracketed sections. Every section is optional but earns its place when filled in honestly.
# CLAUDE.md
## Project overview
[One to two sentences: what this project does and who it is for.]
[Example: "B2B SaaS for automated invoice reconciliation. Node 20 + React 18, deployed on Railway."]
## Tech stack
- Language: [TypeScript / Python / Go / etc.]
- Framework: [Next.js 15 / FastAPI / Express / etc.]
- Database: [Postgres via Drizzle / SQLite via better-sqlite3 / etc.]
- Auth: [NextAuth / Lucia / custom JWT / etc.]
- Infra: [Vercel / Railway / AWS / etc.]
- Key packages: [list 3 to 5 non-obvious dependencies]
## Architecture
[Where files go. Focus on decisions that are not obvious from package.json.]
- src/app/: Next.js app router, pages and layouts only
- src/components/: React components, client-side unless suffixed .server.tsx
- src/lib/: Pure functions, no framework imports
- src/db/: Drizzle schema and migrations only, never import elsewhere
- src/api/: API routes
[For monorepos, map each workspace instead:]
- apps/web: customer-facing Next.js app
- apps/api: Fastify backend
- packages/ui: shared components, maintain backward compatibility
- packages/db: only place that imports from your ORM
## Key commands
- Dev: `[your dev command]`
- Test: `[your test command]` (run before every commit)
- Lint: `[your lint command]`
- Build: `[your build command]`
- Migrate: `[your migration command]` ([note any env restrictions, e.g. staging only])
- Deploy: `[your deploy command or trigger]`
## Conventions
[The rules your linter does not enforce. Be specific.]
- Named exports only, never default exports
- Barrel files (index.ts) per feature directory
- Database queries in src/db/queries/, never inline in components
- File naming: kebab-case for files, PascalCase for components, camelCase for functions
- Error handling: [Result pattern / throw and catch / custom Error classes]
- [Add 2 to 4 more conventions specific to your team]
## Do NOT
[The hard constraints. These are more valuable than any positive instruction.]
- Never modify the database schema without explicit approval
- Never commit .env or .env.local
- Never use `any` type, find or create the correct type
- Never add new dependencies without asking first
- Never put secrets or credentials in committed files
- [Add your project-specific constraints here]
## Memory and agents
[Remove this section if you do not use Claude Code memory or agents.]
Always read .claude/memory.md before taking action.
Available agents (see .claude/agents/ for full definitions):
- [agent-name]: [one-line description of what it does]
## Notes for Claude
[Optional: communication preferences, output format, uncertainty handling.]
- When uncertain, say so and ask rather than guessing
- When listing options, recommend one and give the reason
- Keep explanations concise unless asked to expand
That template covers the sections that matter for most projects. Trim anything that does not apply. The goal is under 100 lines of genuinely useful context, not an exhaustive document. For a deeper look at what each section does mechanically, see the CLAUDE.md best practices guide.
Now here are three real production CLAUDE.md files annotated to show what good looks like in practice.
Example 1: Solo SaaS founder
This is the CLAUDE.md from a solo founder shipping a Next.js + Postgres SaaS. About 80 lines, no fluff.
# Claude Context
You are working on Cleancoder, a SaaS for automated PR review.
Stack: Next.js 14 (app router), Postgres (Neon), Drizzle ORM,
Stripe billing, Vercel deploys. TypeScript everywhere.
Always read .claude/memory.md before taking action.
## Quick Start
- Run /sync at the start of each session
- Run /deploy for any Vercel push (never bare git push)
- Run /test before declaring a task done
## Hard Rules
- Never modify db/migrations/: apply migrations via drizzle-kit only
- Never hardcode Stripe price IDs: use the constant in lib/stripe.ts
- Never commit .env or .env.local
- All API routes have rate limiting via lib/rate-limit.ts
- Errors return 4xx/5xx with structured JSON, never raw stack traces
## Architecture map
- app/: Next.js app router, page + layout files
- components/: React components, all client-side unless suffixed .server.tsx
- lib/: Pure functions, no React imports
- db/: Drizzle schema + migrations only
- api/: Next.js API routes
What is doing work: the stack declaration (so Claude knows the conventions), the hard rules (so it does not modify migrations or hardcode IDs), the architecture map (so it places new files correctly).
What is decoration: there is none. Every line earns its place.
What is missing: voice rules, output style preferences. The founder relies on Claude's defaults for tone and chooses to add specifics only when an output gets corrected.
Example 2: Team-of-five startup
This is the CLAUDE.md for a team building a B2B SaaS. About 160 lines, including team-shared agent definitions referenced from the file.
# Claude Context: InternalCo
This project uses a team-shared Claude Code configuration. See .claude/
for agents, skills, and hooks. Always read .claude/memory.md before
taking action.
## Tech stack
- Frontend: React 18, TypeScript, Tailwind, TanStack Query
- Backend: Fastify (Node 20), Drizzle ORM, Postgres (RDS)
- Infra: AWS (ECS Fargate), Terraform, GitHub Actions
- Observability: Datadog, Sentry, Honeycomb
## Team conventions
- All commits use conventional commits format
- All PRs reference a Linear ticket (LIN-XXX)
- Branch naming: <author>/<linear-id>-<kebab-summary>
- Tests are colocated with source (foo.ts + foo.test.ts)
- No barrel files (index.ts re-exports). Import from the actual file.
## Hard Rules
- Never run drizzle-kit push against production
- Never commit secrets or env files (gitignored already)
- Never bypass the auditor before merging: the auditor runs on every PR
- Database migrations must be reversible (provide both up and down)
- All third-party SDK calls go through lib/clients/ wrappers, never direct
## Voice & output
- Direct, technical, no marketing speak
- When listing options, recommend one and say why
- When uncertain, say "I'm not sure" and ask, do not guess
## Available agents
See .claude/agents/ for full definitions:
- auditor (quality gate before any merge)
- error-whisperer (translates cryptic errors into fixes)
- pr-ghostwriter (generates PR descriptions from diffs)
## Memory architecture
See .claude/memory.md for active context.
See .claude/knowledge-base.md for team-shared rules (auditor-gated).
What is doing work: team conventions (consistency across developers), hard rules (especially the no-drizzle-kit-push rule, which has prevented a production incident), voice rules (this team has had voice drift complaints from non-engineering reviewers), and the auditor reference (load-bearing for their PR process).
What is decoration: the tech-stack list could be shorter. Most of it is implied by file extensions Claude can read.
What is missing: explicit subagent model assignments. They could be saving 30-40 percent on tokens by routing specific tasks to Haiku, but they have not formalised this yet.
Example 3: Enterprise monorepo
This is from a 50-engineer team running a Turborepo monorepo. About 250 lines, with heavy delegation to skills and per-package CLAUDE.md files.
# Claude Context: MegaCo Platform
This is a Turborepo monorepo with 14 packages. See packages/<package>/CLAUDE.md
for package-specific guidance. This file covers cross-cutting concerns only.
Always read .claude/memory.md before any action.
## Repository structure
packages/web : Next.js customer-facing app
packages/api : Fastify backend API
packages/shared : Shared TypeScript types and utilities
packages/data : Database client and migrations
packages/agents : Agent runtime (LLM orchestration)
... (9 more)
## Cross-cutting Hard Rules
- Use the shared package for any utility used in 2+ packages
- Never copy types between packages: use shared
- Never bypass the auditor (PR pipeline gate)
- Never modify .github/workflows without security team review
- All packages publish to internal npm registry, never public
- Database migrations only via packages/data/migrations/
## Specialist agents
- auditor: quality gate, runs before every merge
- pr-ghostwriter: PR descriptions from diffs
- error-whisperer: error translation
- onboarding-sherpa: for new-to-codebase tasks
- archaeologist: for "why does this code exist" questions
- yak-shave-detector: catches scope creep on PRs
- monorepo-router: picks the right package for new code
## Per-package context
Read the CLAUDE.md inside each package directory before working in it.
The root CLAUDE.md (this file) covers cross-cutting concerns only.
## Token budget
- Haiku for routing decisions, classification, audit hooks
- Sonnet for code generation, refactoring, design discussions
- Opus reserved for architectural reviews and critical-path debugging
See .claude/agents/ for explicit per-agent model assignments.
What is doing work: the package structure (Claude does not need to grep), cross-cutting rules (the no-direct-type-copying rule prevents a class of bugs), specialist agent inventory (developers know which agent to invoke for which task), and explicit token budget (saves ~50 percent vs default routing).
What is decoration: the package descriptions could be shorter. The shorter the per-line descriptors, the more Claude actually reads them rather than skimming.
What is missing: voice rules. This team should add them: at 50 engineers, voice drift is a real risk.
What every CLAUDE.md should have
A minimum viable CLAUDE.md, regardless of team size:
- Stack declaration. Two to four lines. Tells Claude the conventions.
- Architecture map. Where files go. Stops Claude from creating components in api/.
- Hard rules. The genuinely-important constraints. Five to ten lines max.
- Memory pointer. Tells Claude to read memory.md first.
- Skills/agents reference. If you have them, point to them.
That is the floor. About 50 lines done well beats 500 lines done poorly. Every additional line is context budget the model spends to read instead of to produce output. Trim aggressively.
What to avoid
Three patterns that show up in CLAUDE.md files that hurt rather than help:
Restating the obvious. "We use TypeScript" is implied by .ts files. Cut it.
Unenforceable preferences. "Write clean code" is not a rule, it is a wish. Either make it specific (function names use camelCase, components use PascalCase) or drop it.
Unverified claims. Including outdated info (like "we use Drizzle 0.28") locks Claude into stale patterns. If you cannot verify it on every commit, do not claim it.
Where CLAUDE.md ends and skills begin
CLAUDE.md is for things every session needs to know. Skills are for things some sessions need to know. The decision rule:
- Read by Claude every session → CLAUDE.md
- Read by Claude when invoked → Skills
A 500-line CLAUDE.md that loads 90 percent unused content per session is wasted spend. Move the situational stuff into skills, keep the universal stuff in CLAUDE.md.
This split is exactly the architecture Claudify ships out of the box. The CLAUDE.md is tight (under 100 lines), the heavy lifting happens in skills, memory systems, and custom agents loaded only when needed.
Quick checklist
A CLAUDE.md self-audit:
- Under 200 lines (ideally under 100)
- Stack declaration in first 5 lines
- Hard rules in a clear section, max 10
- Architecture map (one file path per line)
- Memory.md read pointer at the top
- No "we use X" statements that are obvious from file extensions
- No vague preferences ("write clean code")
- No outdated version numbers
If you can answer all of these yes, your CLAUDE.md is doing its job.
Next steps
CLAUDE.md is the entry point. Skills, memory, and agents are where the leverage compounds. Doing all four together is what separates a functional Claude Code setup from a high-leverage one.
Get Claudify. The Claude Code operating system that ships with a tight CLAUDE.md, structured memory, agent definitions, and audit hooks already wired up.
More like this
Ready to upgrade your Claude Code setup?
Get Claudify
