# What to Put in Your CLAUDE.md (and What to Leave Out)

> Source: <https://dev.to/promptmaster/what-to-put-in-your-claudemd-and-what-to-leave-out-4f39>
> Published: 2026-06-21 09:37:47+00:00

A great CLAUDE.md is not the longest one. It is the one where every line changes what Claude does. The whole skill is knowing what belongs in it — and, just as importantly, what does not.

Start with a one or two line project description and your stack, with version numbers. Claude infers a lot from your code, but it will not guess that you are on Next.js 15 instead of 14, or which ORM you chose.

Then a directory map — not every file, just the top-level layout with a note on what each part holds. After that: the build and test commands, the conventions a formatter does not enforce, and critically, the things not to touch.

```
# Project: Acme Dashboard
Next.js 15 (App Router), TypeScript, Drizzle ORM, Vitest.

## Structure
src/app/        # routes and pages
src/lib/        # shared utilities, db client
db/migrations/  # generated - never hand-edit

## Commands
Build:  npm run build
Test:   npm run test

## Conventions
- API routes return { data, error } - never throw to client
- Server components by default

## Do not touch
- db/migrations/ is generated. Never edit by hand.
```

Every line in that file would cause a mistake if removed. That is the bar.

This is where most files go wrong. Two kinds of content waste your budget:

**Personality instructions.** "Act as a senior engineer," "think step by step," "be thorough." These feel productive but change nothing — Claude already does them. General advice that does not prevent a specific mistake is pure noise.

**Rules a tool already enforces.** If you have a formatter or linter, do not restate what it enforces. Wire it into a hook instead, and keep CLAUDE.md for what tools cannot enforce.

For every line, ask: **"If I remove this, will Claude make a mistake?"** If yes, keep it. If no, delete it.

This single question, applied ruthlessly, is the difference between a file Claude follows and one it ignores. A bloated file buries the rules that matter in noise, so Claude cannot tell which line is the important one. Pruning is not tidying — it is what makes the file work.

CLAUDE.md loads into Claude's context every session, and performance degrades as context fills. A leaner file is not just easier to read — it makes Claude more reliable, because the rules that matter are not competing with filler for attention. Short is not a style choice here. It is a performance requirement.

**Free starter:** The format, a complete annotated example, and the one-line test are all on a free cheat sheet: [CLAUDE.md Quick-Start Cheat Sheet](https://promptmasterstore.gumroad.com/l/claude-md-cheat-sheet)

**Go deeper:** The full guide covers the entire configuration stack — hooks, subagents, commands, skills and plugins — with real-world walkthroughs and a 30-day plan: [CLAUDE.md: The Complete Claude Code Configuration Guide](https://promptmasterstore.gumroad.com/l/claude-md-configuration-guide)

What is the one rule in your CLAUDE.md that has saved you the most? Share it in the comments.