Every new Claude Code session starts the same way: a capable new hire with amnesia. It doesn't know how your tests run, which files are off-limits, or that you want a three-line status update, not three paragraphs you have to dig through.
CLAUDE.md is the onboarding doc it reads automatically at the start of every session. Get it right and you stop re-explaining your project, stop getting "I assumed you meant..." rework, and stop finding edits in places nobody asked it to touch. Below is what I took away from a big community thread on the topic, a real CLAUDE.md I wrote for a small production app, and a free template you can copy.
Honesty note: I did not run a controlled with/without experiment in Claude Code for this post. The CLI wasn't installed in the environment I used. The comparison section is a static one: what information the agent can get from the repo with and without the file. I'll update this post with real runs later.
Where this comes from
A thread on r/ClaudeAI asked, more or less, "What's the single most useful line in your CLAUDE.md?" It picked up roughly 1.3k upvotes and 185 comments (thread). What follows is my own summary of the patterns that kept coming up, not a quote dump.
The 6 ideas that kept coming up
- Terse reporting. The top idea, roughly: "be extremely concise in reports; sacrifice grammar for brevity." Status updates shrink from paragraphs to a few lines you'll actually read.
- State assumptions and separate evidence from inference. Ask it to list its assumptions and to mark what it verified apart from what it inferred. A lot of people called this unexpectedly useful.
- A stop-loss rule. After two failed attempts, stop and explain where you're stuck. Don't try a third time. This keeps it from confidently refactoring itself into a dead end.
- How many questions to ask. This was the most debated one. Rough consensus: at most one clarifying question for small tasks. If a mistake is expensive to undo, ask first; if it's cheap, decide and tell me. For big features, write a real spec, or have the agent interview you.
- Promote hard rules to hooks. Requirements like "always re-read your diff" hold up much better as a hook than as prose.
-
Point to AGENTS.md. Keep shared rules in
AGENTS.mdand make CLAUDE.md a single line:@AGENTS.md. Some say newer versions read AGENTS.md natively; check this against your own version.
Two honorable mentions: hand deterministic work (counting, searching, diffing) to tools instead of letting the model eyeball it, and write these files for compliance and token economy, not for human readability. The joke rules people shared (emoji on every sentence, talking like a TV character) prove the point from the other side: this file really does change behavior.
Structure: five sections are enough
- One-line identity: what the project is and what the stack is
- Commands: install, run, test. This matters most.
- Map: only entry points and anything non-obvious
- Hard rules: things that break production, with reasons
- Workflow: questions, stop-loss, self-review, report format
A real example: StatementCSV
StatementCSV is a small Flask app I run that converts bank statement PDFs to CSV/Excel. It has no database. Here's what went into its CLAUDE.md and why:
-
Commands: "If you touch
parser.py, runscripts/selfcheck.pyand every line must say OK." Without that line the agent can't know the regression script exists. There's notests/folder, so it would guesspytestand fail. -
Map:
parser.pyis the core, andapp.pyholds routes and usage counters. This keeps edits in the right file. -
Hard rules:
- PDFs are processed in memory only and are never written to disk or logs. That's a privacy promise on the site.
- Money is always
Decimal. - If the balance check doesn't reconcile, report it. Never "tune it until it passes."
- Production runs multi-process gunicorn, so shared state needs a lock.
- New public pages must be added to the sitemap.
None of these are visible from reading the code, and every one is a real trap.
- Workflow: the four most-upvoted rules from the thread: at most one question, stop after two failures, self-review the diff, terse report.
Before/after (static comparison)
| Task | Without CLAUDE.md (repo only) | With CLAUDE.md |
|---|---|---|
| "Add a test for date parsing" | No tests dir, so it guesses a framework and likely misses scripts/selfcheck.py
|
Extends selfcheck expectations and runs until all OK |
| "Add an FAQ page" | Probably adds the route only | Also updates sitemap_xml()
|
| "Add logging for debugging" | Might log uploaded content | Hard rule forbids PDF content in logs |
| Reporting | Long essay | Three lines: changed / verified how / open issues |
What I did run: the project's self-check passes 6/6 (5 sample statements plus 1 scanned PDF correctly flagged as having no text layer). That checks the app, not the agent.
To do a proper A/B yourself, run the same prompt twice with claude -p "<task>", temporarily renaming CLAUDE.md for one run, then compare the diffs and how many back-and-forth turns each took.
Common mistakes
-
Too long. Past about 100 lines the important rules get diluted. Aim for under 40 and push details into subdirectory CLAUDE.md files or
@docs/...imports. - Platitudes. "Write clean code" does nothing. Only write what the model can't know by default.
- Commands that don't run. Verify every one yourself.
- Rules without reasons. Without the why, it either over-applies a rule or lawyers around it.
- Never updating it. Every time you correct the agent, ask: should this go in CLAUDE.md?
- Secrets. CLAUDE.md usually gets committed. Keep credentials out.
Free template
Save this as CLAUDE.md in your repo root and replace the <...> parts.
# <Project name>
<One line: what it is, the stack, who it's for>
## Commands
- Install: `<cmd>`
- Run: `<cmd>`
- Test (run after every change): `<cmd>`
- Lint/format: `<cmd>`
## Structure
- `<dir>/`: <what lives here>
- `<file>`: <core logic>
## Hard rules (breaking these causes real damage)
- <e.g. never write user data to disk>
- <e.g. money is always Decimal>
- Unless explicitly asked: no push, no deploy, don't touch `.env`
## Workflow
- If something is ambiguous, ask at most 1 question; if it's cheap to undo, just do it and tell me
- After two failed attempts, stop and explain where you're stuck; don't try a third time
- Re-read your own diff before reporting
- Report tersely: what changed / how you verified / what's left
What's the one line in your CLAUDE.md that earns its keep? I'd like to hear it in the comments.
Top comments (0)