5 Real CLAUDE.md Files You Can Copy Today (With Templates)

My first CLAUDE.md was 200 lines of garbage. Generic instructions like "write clean code" and "follow best practices." Claude ignored most of it. The breaking point came when I spent 30 minutes explaining the same project structure for the third time in one session. I realized the official docs show a minimal example, but nobody explains what belongs in a real project.

I deleted everything and started over. This time, I looked at what I actually kept explaining to Claude. Project structure. Where files live. What commands exist. Which tools to use when. Within a week, I had 5 different CLAUDE.md templates - one for each project type I work on. Now I spin up new projects in minutes instead of hours.

New to Claude Code? Start with the complete setup guide - it covers CLAUDE.md basics, memory systems, and agent orchestration.

The Blank Page Problem

The official Claude Code docs show a 10-line CLAUDE.md example. It's technically correct but useless for real projects. Most people fill the gap with generic programming advice that Claude already knows. The result? You explain the same context every session, Claude guesses wrong about file locations, and you waste time correcting assumptions.

The real question isn't "what CAN go in CLAUDE.md?" It's "what context would I repeat every single session if I didn't write it down?" That's your CLAUDE.md content.

Five Template Categories

After building 12 production systems, I identified 5 distinct CLAUDE.md patterns. Each solves a different context problem.

1. Minimal (Solo Projects)

Best for: Single developer, one codebase, no external tools.

# Project Overview
SaaS dashboard - Next.js 15 + Supabase

## Stack
- Frontend: Next.js 15, Tailwind, shadcn/ui
- Backend: Supabase (PostgreSQL + Auth)
- Deploy: Vercel

## Key Files
- Database schema: /supabase/schema.sql
- Auth config: /lib/auth.ts

That's it. 15 lines. Claude knows the stack, where files live, and what database you use. No fluff.

2. Agent-Heavy (Multi-Agent Systems)

Best for: Projects using Claude Code's delegation features extensively.

# Delegation Rules
Score >= 3 → Auto-delegate (no confirmation)
Exploration/Search → ALWAYS use Explore agent

## Agent Types
- Explore: built-in, follows the main model, codebase questions
- debugger: sonnet, systematic debugging
- researcher: sonnet, web research with citations

The built-in Explore agent has no Haiku default. It uses the main conversation's model. When the main conversation runs Fable, the model depends on how you connect: with a Claude subscription, an Anthropic Console account or an LLM gateway reached through ANTHROPIC_BASE_URL, Explore runs on the Opus model that the opus alias resolves to. On Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, Claude Platform on AWS or a Claude apps gateway, it stays on the main conversation's model. A user or project subagent named Explore overrides the built-in and keeps its own model field, so define one with model: haiku to run exploration on Haiku.

This is where agent delegation rules live. My component count two days before this post listed 88 agents. Without explicit delegation config, Claude would ask permission every time.

3. MCP-Powered (External Tool Integration)

Best for: Projects using Model Context Protocol servers for databases, APIs, or browsers.

# Available MCP Tools
- Notion: mcp__notion__API-post-search (search pages)
- Browser: mcp__claude-in-chrome__read_page (scrape content)
- Filesystem: mcp__filesystem__list_directory (read directories)

## Tool Usage Rules
- Database queries → Use Notion MCP, NOT web search
- Page scraping → Use Browser MCP with explicit URL

Without this, Claude might web-search for database content instead of querying directly. Or try to scrape pages with curl instead of using the browser MCP.

4. Monorepo (Multi-Package Workspace)

Best for: Monorepos with shared packages, distinct apps, or complex folder structures.

# Workspace Structure
apps/
  web/ - Next.js frontend
  api/ - Express backend
packages/
  ui/ - Shared React components
  utils/ - Shared TypeScript utilities

## Cross-Package Rules
- Imports: Use workspace:* protocol
- Types: Export from packages/types
- Shared components: Import from @repo/ui

This prevents Claude from creating duplicate utilities or importing from the wrong package. Monorepos break without explicit structure documentation.

5. Scenario-Based (Multi-Project Orchestration)

Best for: Systems where one Claude Code instance orchestrates multiple projects.

# Project Context
This is the landing page for Product X
Main system: /Users/me/system/
Memory: /Users/me/system/_memory/projects/product-x.json

## Available Commands
/launch - Phase dashboard + metrics
/blog-post - Write SEO-optimized post
/status - Current phase + next action

My Evolving system uses this. One CLAUDE.md orchestrates my projects. On 12 February 2026 my component count listed 10 scenarios and between 108 and 110 commands, depending on the update that day. Each project's CLAUDE.md points back to the central memory system for coordination.

Generic vs. Project-Specific

Here's what changed when I switched from generic instructions to project-specific config:

The generic version tells Claude things it already knows. The project-specific version tells Claude things it can't guess - where your files live, what auth system you use, how API routes work in your specific setup.

Real-World Results

After switching to template-based CLAUDE.md files:

• Context setup time: 30 minutes → 2 minutes (15x faster)
• Wrong file location guesses: ~40% of sessions → ~5%
• Commands available: 0 → 104 (across all projects)
• Agents configured: 0 → 86 (domain-specific delegation)
• Projects orchestrated: 1 → 6 (from one Claude instance)

The biggest gain wasn't speed. It was consistency. Claude makes the same correct assumptions every session. I don't re-explain project structure. I don't correct file paths. I start working immediately.

What About Advanced Patterns?

These 5 templates cover 90% of projects. But there's a deeper layer - score-based delegation, trait systems, memory bootup rituals, scenario orchestration, MCP tool chaining. My production CLAUDE.md files include sections for:

• Auto-delegation scoring (when to hand off to sub-agents)
• Memory loading priorities (which context to load first)
• Session resume protocols (how to continue after /clear)
• Cross-project syncing (when one project affects another)
• Security tier checks (what requires confirmation)
• Planning frameworks (how to catch gaps before execution)

Those patterns are too complex for a blog post. Evolving Lite includes production-ready templates with full delegation config, memory integration, and orchestration rules. These simplified versions get you 80% of the benefit with 20% of the complexity.

Want to see how the pieces fit together? The templates, the memory system, the delegation rules, the orchestration layer - it's all in Evolving Lite. Free and open source.

If you also use Cursor, the Claude Code vs Cursor comparison notes that your CLAUDE.md files work in both environments.

Updated 2 October 2026: the description of which model the built-in Explore agent runs on was brought in line with the current Claude Code docs. The agent, command and scenario counts now match my component count from 12 February 2026, and the project count, which that count does not include, was removed.