CLAUDE.md Template: A Ready-to-Use Starter (2026)

Updated July 2026

A CLAUDE.md template is a ready-made starter file you drop into your project root so Claude Code opens every session already knowing your stack, conventions, commands, and constraints. This page gives you a complete, production-grade CLAUDE.md you can copy in one click, a section-by-section breakdown so you know what to keep and what to cut, and a free starter kit you can download. Copy the full template below, replace the bracketed placeholders with your project's details, save it as CLAUDE.md in your repository root, and you are done.

TL;DR

• Copy the complete CLAUDE.md template below into a file named CLAUDE.md at your project root, then replace every [bracketed placeholder] with your own details. That is the whole job.
• A strong CLAUDE.md has seven sections: project overview, tech stack, conventions, commands, architecture notes, key files, and an explicit "Do NOT" block. The "Do NOT" section is the highest-value part.
• Keep it under about 150 lines. Claude reads the whole file every session, so bloat competes with your actual code for context.
• Want more than a single file? The free claude-code-skills-starter kit (MIT, now in Anthropic's plugin marketplace) ships this template plus four working starter skills you can copy-paste.
• This is the copy-and-download template page. For the deeper "what is a CLAUDE.md and how does it work" explanation, read the CLAUDE.md file explained; for more worked examples by stack, see CLAUDE.md examples.

What a CLAUDE.md template gives you

Without a CLAUDE.md, Claude Code reads your files and makes reasonable guesses about your architecture, your conventions, and which commands to run. With one, it stops guessing. It knows your ORM is Drizzle and not Prisma, it runs pnpm test instead of inventing npm test, and it respects the constraint that says "do not touch the payments code without asking."

A template just saves you the blank-page problem. Instead of remembering every section a good CLAUDE.md should have, you start from a complete file and delete what does not apply. The version below is the one to copy. It is structured so Claude can parse it fast, it uses headings Claude recognizes, and it leads with the sections that change Claude's behavior the most.

The complete CLAUDE.md template

Copy this entire block into a file named CLAUDE.md in your project root. Replace anything in [square brackets] with your project's real details, and delete any line that does not apply to you. Everything here is a starting point, not a rule you must keep.

# CLAUDE.md

This file is read by Claude Code at the start of every session. Keep it current and
under ~150 lines. The goal: Claude opens with the context a new senior teammate would need.

## Project overview

[Project name] is a [one-sentence description of what it does and who it is for].
[Second sentence: the single most important thing to know before editing, e.g. "This is
a multi-tenant SaaS where each customer is a subdomain," or "This is a CLI tool with zero
runtime dependencies, keep it that way."]

- Status: [production / beta / prototype]
- Primary users: [who uses this]
- Repo layout: [monorepo / single app / library]

## Tech stack

- Language: [e.g. TypeScript, strict mode]
- Framework: [e.g. Next.js 15, app router]
- Database: [e.g. Postgres via Drizzle ORM, schema in src/db/schema.ts]
- Auth: [e.g. NextAuth v5, GitHub + Google providers]
- Styling: [e.g. Tailwind CSS, no component library]
- Package manager: [e.g. pnpm, NOT npm or yarn]
- Hosting: [e.g. Vercel, auto-deploy on push to main]

## Conventions

Rules a contributor should follow that are NOT captured by the linter:

- [e.g. Named exports only, never default exports]
- [e.g. Database queries live in src/db/queries/, never inline in components]
- [e.g. Server components by default; add "use client" only for real interactivity]
- [e.g. All money stored as integer cents, formatted at the display layer]
- [e.g. File naming: kebab-case for files, PascalCase for components]
- [e.g. Prefer editing existing patterns in src/ over introducing new ones]

## Commands

The exact commands for THIS project (getting these wrong causes real problems):

- Dev: `[e.g. pnpm dev]` (port [3000])
- Build: `[e.g. pnpm build]` (runs type-check first)
- Test: `[e.g. pnpm test]` (run before every commit)
- Test one file: `[e.g. pnpm test -- {filename}]`
- Lint: `[e.g. pnpm lint]` ([e.g. Biome, not ESLint])
- Typecheck: `[e.g. pnpm typecheck]`
- DB migrate: `[e.g. pnpm db:push]` ([e.g. Drizzle push, NOT migrate])
- Deploy: `[e.g. push to main triggers Vercel automatically]`

## Architecture notes

The non-obvious decisions worth knowing before editing:

- Entry point: [e.g. src/app/layout.tsx wraps every route]
- [e.g. All external API calls go through src/lib/api-client.ts, which handles retries]
- [e.g. Webhooks are in src/app/api/webhooks/; they must stay idempotent]
- [e.g. The build step generates src/generated/, never edit those files by hand]
- Gotcha: [e.g. the seed script assumes an empty DB; run db:reset first]

## Key files

- `[src/db/schema.ts]`: [single source of truth for the database schema]
- `[src/lib/auth.ts]`: [auth config and session handling]
- `[.env.example]`: [required env vars; credentials live in .env.local, read it when needed]
- `[src/components/ui/]`: [shared UI primitives]

## Do NOT

The constraints that prevent whole categories of mistakes:

- Do not modify [the database schema] without explicit approval.
- Do not install new dependencies without asking first.
- Do not use the `any` type; find or create the proper type.
- Do not commit secrets, API keys, or `.env` files.
- Do not [touch the payments / auth / migration code] without confirming the change first.
- Do not add debug `console.log`; use [the logger at src/lib/logger.ts].

That is a complete, working CLAUDE.md. The bracketed placeholders are the only thing you need to change. If your project is smaller, delete the sections you do not need and keep the file lean. If you want an even shorter starting point, the minimal version further down is five lines.

Get the free starter kit (with this template inside)

The template above ships inside a free, open-source repository you can clone right now: the claude-code-skills-starter kit. It is MIT licensed, it is listed in Anthropic's plugin marketplace, and alongside the starter CLAUDE.md.example it includes four working Claude Code skills you can copy-paste: a conventional-commits writer, a pre-PR code-review pass, a test writer that follows your existing patterns, and a README generator.

Clone it and copy the pieces you want:

git clone https://github.com/claudifytech/claude-code-skills-starter
cd claude-code-skills-starter

# use the starter memory file
cp CLAUDE.md.example /path/to/your/project/CLAUDE.md

# and the starter skills
mkdir -p /path/to/your/project/.claude/skills
cp -r skills/* /path/to/your/project/.claude/skills/

It is a genuine starting taste rather than the full system, which is exactly what a starter should be. Take what is useful, ignore the rest.

The sections of a strong CLAUDE.md (and why each matters)

Here is each section from the template with a short snippet and the reason it earns its place. Use this to decide what to keep when you trim the file down.

Project overview

## Project overview
Acme is a multi-tenant billing dashboard for indie SaaS founders. Each customer is a
subdomain. This is production; treat the Stripe integration as load-bearing.

Why it matters: the first thing Claude needs is the mental model. One or two sentences that frame what the project is and the single most important fact about it stop Claude from making category errors, like reaching for a component library on a project that deliberately has none.

Tech stack

## Tech stack
- TypeScript strict, Next.js 15 app router
- Postgres via Drizzle (schema in src/db/schema.ts)
- pnpm, NOT npm

Why it matters: this is the highest density of behavior-changing information per line. Naming your ORM, your router, and your package manager removes the three most common wrong guesses in one place. The pnpm, NOT npm note alone prevents phantom package-lock.json files.

Conventions

## Conventions
- Named exports only, never default exports
- All money stored as integer cents
- Reuse existing patterns in src/ over introducing new ones

Why it matters: conventions are the rules your ESLint config does not capture, the human knowledge that usually lives in your team's heads. Be specific. "Follow best practices" tells Claude nothing it was not already trying to do. "Named exports only" is a rule it can apply every single time.

Commands

## Commands
- Test: `pnpm test` (run before every commit)
- DB migrate: `pnpm db:push` (Drizzle push, NOT migrate)

Why it matters: Claude Code can run commands, but only if it knows the right ones. If it runs drizzle-kit migrate on a project that uses drizzle-kit push, it creates problems. The annotations in parentheses ("NOT migrate") are as important as the commands themselves.

Architecture notes

## Architecture notes
- All external API calls go through src/lib/api-client.ts (handles retries)
- Files in src/generated/ are build output, never edit by hand

Why it matters: this is where you record the non-obvious wiring, the things a reader cannot infer from the file tree. The "never edit the generated files" note is the kind of gotcha that saves an entire wasted session.

Key files

## Key files
- src/db/schema.ts: single source of truth for the schema
- .env.example: required env vars (credentials in .env.local)

Why it matters: pointing Claude at the files that matter most means it does not have to explore blindly. It jumps straight to the schema instead of grepping for it.

Do NOT (the most valuable section)

## Do NOT
- Do not modify the database schema without approval
- Do not commit secrets or .env files
- Do not touch the Stripe webhook handler without confirming first

Why it matters: this is arguably the single most valuable block in the file. Claude is eager to help, and without explicit constraints it will sometimes "improve" things you did not want touched. One "do not modify the schema without asking" prevents a whole category of problems that positive instructions cannot cover. For more on structuring these guardrails alongside automated checks, see our guide to Claude Code hooks.

A minimal starter when you want something tiny

You do not need to fill in everything on day one. This five-part version still makes a real difference, and you can grow it as you discover gaps:

# CLAUDE.md

## Stack
- [framework] + [language], [database] via [ORM]

## Commands
- Dev: `[dev command]`
- Test: `[test command]`

## Do NOT
- [your single most important constraint]

Save that, start a session, and add a line every time Claude guesses something wrong. The best CLAUDE.md files are not written in one sitting; they accrete from real friction.

Where the file goes and how to keep it good

Save the template as CLAUDE.md in your project root and commit it to git so your whole team shares the same Claude Code behavior. You can also keep a personal, global file at ~/.claude/CLAUDE.md for preferences that apply to every project; when both exist, the project file wins on conflicts and the rest merges. For the full explanation of precedence and the wider .claude/ directory, read the CLAUDE.md file explained.

A few rules keep a template from turning into dead weight:

• Keep it under ~150 lines. Claude reads it every session, so length is a real cost.
• No secrets. The file is committed. Point Claude at .env.local instead of pasting keys.
• Stay specific. Vague advice adds tokens without changing behavior.
• Do not fight your linter. If ESLint enforces semicolons, do not write "no semicolons" here.
• Do not duplicate config. Claude reads package.json and tsconfig.json already; describe the decisions those files do not capture.

For the full checklist of what strong Claude Code configuration looks like in practice, see our Claude Code best practices guide.

FAQ

What is a CLAUDE.md file?

A CLAUDE.md file is a plain markdown file that Claude Code reads automatically at the start of every session. It tells Claude how to work with your specific project: your tech stack, coding conventions, exact build and test commands, key files, and constraints it should respect. Without it, Claude guesses from your source files. With it, Claude behaves like a teammate who has read your project brief. The template on this page is a ready-to-use starting point.

Where does CLAUDE.md go?

Put it in your project root, in the same directory as package.json or your top-level config, named exactly CLAUDE.md, and commit it to git so your team shares it. You can also keep a personal global file at ~/.claude/CLAUDE.md that applies to every project. When both exist, the project file overrides the global one on any conflict, and non-conflicting instructions from both are merged.

What should a CLAUDE.md include?

A strong CLAUDE.md includes seven sections: a short project overview, the tech stack, coding conventions the linter does not enforce, the exact dev/test/build/deploy commands, non-obvious architecture notes, the key files worth knowing, and an explicit "Do NOT" block of constraints. The "Do NOT" section is the highest-value part because it prevents whole categories of unwanted changes. The template above contains all seven with fill-in-the-blank placeholders.

How long should a CLAUDE.md be?

Keep it under about 150 lines, and shorter is usually better. Claude Code reads the entire file at the start of every session, so every line competes with your actual code for space in the context window. If you find yourself needing more, move the detailed reference material into separate files inside the .claude/ directory and keep the root CLAUDE.md as a short, high-signal index.

CLAUDE.md vs cursor rules: what is the difference?

They solve the same problem for different tools. A .cursorrules file (or the newer .cursor/rules/ directory) configures Cursor, while CLAUDE.md configures Claude Code. The content is very similar: stack, conventions, and constraints. The main practical differences are that CLAUDE.md is a single conventional file Claude reads every session, and it supports the two-level project-plus-global precedence described above. If you use both tools, you can keep the two files in sync by copying the shared sections. The template on this page works as a strong base for either.

Can I just copy this CLAUDE.md template?

Yes, that is exactly what it is for. Copy the complete template block above into a file named CLAUDE.md in your project root, replace the bracketed placeholders with your project's real details, and delete any lines that do not apply. You do not need to keep every section. For a running head start with working skills included, clone the free claude-code-skills-starter kit.

Do I need a CLAUDE.md for a small project?

Even a five-line CLAUDE.md helps. For a small project, the minimal starter above (stack, two commands, one constraint) is often enough to stop the most common wrong guesses. The value scales with how much Claude would otherwise have to infer, so the payoff is largest on projects with non-obvious conventions, unusual tooling, or load-bearing code you do not want touched casually.

Skip the setup entirely

A template gets you a good CLAUDE.md. If you want the whole system pre-wired rather than just the memory file, that is what Claudify is. It is a complete operating system for Claude Code: a production CLAUDE.md, 1,727 expert skills across 31 categories, 9 specialist agents with persistent memory, slash commands, and automated quality gates, all curated and installed in one command. The template on this page is the starting line. Claudify is the finished system.