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.
The sections that earn their place
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.
Enter fullscreen mode Exit fullscreen mode
Every line in that file would cause a mistake if removed. That is the bar.
What to leave out
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.
The one-line test
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.
Why brevity is performance
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
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
What is the one rule in your CLAUDE.md that has saved you the most? Share it in the comments.
답글 남기기