CLAUDE.md: the file that multiplies Claude (what to put in and what to leave out)

There's one question that separates people who get the most out of Claude from people who fight with it: do you explain your project every time you open a session? If the answer is yes, you're leaving half the value on the table. The trick isn't writing better prompts. It's writing one file, once, that Claude reads automatically every time it starts: the CLAUDE.md.

It's the cheapest and most profitable change you can make. Four well-placed lines and you stop repeating yourself forever. This guide is about what to put in there, what to leave out, and how to structure it so it actually works.

What CLAUDE.md is and why it multiplies Claude

It's a text file in Markdown format that you put in your project folder. That's all: plain text. What makes it special is that Claude reads it automatically when each session starts and treats its content as top-of-the-list instructions.

The difference compared with a normal chat is enormous. Without CLAUDE.md, every conversation starts from scratch: Claude doesn't know what your project is, which stack you use, how you like it to write, or which files are off-limits. You fill that gap by hand, over and over, spending your time and its attention. With CLAUDE.md, that context is already loaded before you type a single word.

That's why it "multiplies": it doesn't make Claude smarter, it makes it more yours. It stops guessing and starts out aligned with how you work. The first answer of every session is already the good one, not the third.

What to put in (and what to leave out)

Here's the most common mistake: treating CLAUDE.md as a junk drawer where you stuff everything you know about the project. Wrong. Everything you write there takes up context in every session and competes for the model's attention. A huge file dilutes the instructions that really matter.

The mental rule is simple: operational, stable instructions, not documentation. If something is stable (it always applies) and operational (it changes how Claude works), it goes in. If it changes every week or only serves a task you're doing today, it goes in the chat.

What DOES belong inside:

• What the project is in one or two sentences. The purpose, not the history.
• How you want it to work: tone, language, level of detail, whether it should ask permission before big changes.
• Conventions: stack and commands (code projects), folder structure, naming, output format.
• Explicit prohibitions: which files or areas it must never touch. This is the section that prevents the most mistakes and the one almost everyone forgets.
• Shortcuts: commands or workflows you repeat a lot ("to deploy, use X").

What does NOT belong inside:

• The project's history or settled decisions that don't affect today's work.
• Long documentation that already lives somewhere else (better: link to it or say where it is).
• Single-task instructions ("today, fix this bug"): that's a prompt.
• Secrets, keys, or passwords. Never.

A recommended structure

There's no mandatory format, but this structure works because it moves from general to specific and puts the hard rules where Claude sees them. Four blocks:

1. About the project — what it is and what it's for, in a few sentences.
2. How to work — tone, language, approval flow, level of detail.
3. Conventions — stack, structure, commands, format. The concrete stuff.
4. Don't touch — the explicit prohibitions, clearly visible.

Keep each block short and in lists. Claude reads five clear bullets better than one dense paragraph. And if your project grows, split it: one general CLAUDE.md with your global preferences and one per subproject with its details. The specific ones add to the general ones, so don't repeat yourself: put the tone in the brand one, and only what changes in each project's file.

Copy-paste template

This is the base template. Copy it, delete what doesn't apply, and fill in the brackets. In two minutes you'll have a CLAUDE.md better than 95% of the ones out there.

# [Project name]

## About the project
[What it is, in 1-2 sentences.] I use it to [main goal].
Audience / context: [who uses it or who it's for].

## How I want you to work
- Talk to me in English, direct and to the point.
- Before big or irreversible changes, show me the plan and wait for my OK.
- By default, small and reversible tasks.
- If something isn't clear, ask before assuming.

## Conventions
- Stack / tools: [language, framework, apps].
- Structure: [where each thing lives].
- Key commands: [build / test / deploy if applicable].
- Output format: [how you want the answers].

## DO NOT touch (important)
- [untouchable files, folders, or areas].
- Never delete or overwrite [X] without warning me first.
- Do not include secrets, keys, or sensitive data.

Three examples for your case

The template is the same; what changes is the filling. Three real cases.

Code project. Here the value is in the technical conventions. Stack and versions, build and test commands, folder structure, code style ("use strict TypeScript, no any"), and the critical prohibitions ("don't touch migrations/, don't push directly to main"). Claude stops inventing commands and respects your architecture from the very first message.

Brand or business. Here what matters is the voice. Tone ("direct, practical, no filler, no emojis"), which words to use and which to avoid, text format, language, and style rules ("never promise guaranteed results"). What in code are technical conventions are, in a brand, voice conventions. The result: everything Claude writes sounds like you, not like generic AI.

Non-technical use. Organizing documents, planning, drafting emails. You don't need to know how to code. You put down how you work ("always sort by date for me", "summaries in bullets of five points max"), your usual folders, and what not to touch ("don't move anything in the Important folder without showing me first what you're going to do"). Same file, same effect: you stop explaining the obvious every session.

The mistake that ruins a good CLAUDE.md

Writing it and forgetting it. A CLAUDE.md is a living document: when you notice you're repeating an instruction in the chat two or three times, that instruction belongs in the file. Add it. And the other way around: if a rule no longer applies, delete it, because accumulated junk weighs on it too.

Treat it as what it is: the working contract between you and Claude. The clearer and more up to date it is, the better it works. The difference between someone who fights with the tool and someone who gets the most out of it almost always comes down to this: the second one wrote their rules once, in a file, and stopped repeating them forever.

Open your project, create a CLAUDE.md with the template above, and fill in the four blocks. It's the most profitable thing you'll do today with Claude.