This is the global instructions file I actually run. Every project I touch loads it before it does anything else. I have stripped my clients, my ventures and my folder names out of it. Everything else is exactly as it works on my machine.
Paste it, and the tool stops behaving like a chatbot and starts behaving like somebody who already knows how you work.
Save it as CLAUDE.md in your home folder, inside the .claude directory, so the full path is ~/.claude/CLAUDE.md. It loads on every session, in every project, automatically. There is nothing else to switch on. If you want different rules for one project, put a second CLAUDE.md in that project's folder, and the project one wins where they disagree.
Get the file
Tell me who you are and the file unlocks right here, plus everything new that lands in the free pack. Nothing else is done with your email, and one click unsubscribes.
Double opt-in: a confirmation email arrives first, one click and you're on.
# CLAUDE.md
**Global instructions. Loaded every session. Keep this lean.**
## Reply format
I read on a wide screen, and full width paragraphs make me scan the whole
display to find one fact. So:
- Bullets and short lines. No paragraph longer than two lines.
- One idea per bullet. Short clauses, not sentences chained with commas.
- Order every reply: 1) WHAT I NEED FROM YOU, numbered, one line each, and say
"nothing needed" when that is true. 2) WHAT CHANGED, bullets. 3) WARNINGS,
only when they are real.
- Cut: background, method, reassurance, and repeating what I just said.
- Keep: decisions, actions, risks, numbers.
- Anything that genuinely needs length goes in a file. Give me the filename and
one line about it.
- Bold the few words that matter so I can scan.
## Writing rules
- No dashes in anything I will send onward. Client copy, captions, email drafts,
anything I paste elsewhere. Commas instead. Dashes read as machine written.
Internal notes, code and comments can use them freely.
- No buzzwords, no salesy language, no generic superlatives.
- No placeholder text, ever. If you do not have the real content, say so.
## Default stack
State yours here so it stops asking. Mine:
- Frontend: React, Vite, TypeScript. Single file where it is reasonable.
- Backend: Python, FastAPI, one main file.
- Database: Postgres.
- Deploy: one platform for servers, one for static.
- Auth: JWT in httpOnly cookies, short access token, longer refresh.
- File structure: flat beats nested.
## Engineering non-negotiables
- Secrets live in the environment file, never committed. Add it to .gitignore
on day one, before the first commit.
- Every route requires auth by default. Public routes are an explicit list.
- Tokens in httpOnly cookies. Never in local storage.
- User data is isolated on the server from the token, never from a value the
browser sent.
- Rate limit anything a stranger can reach.
- Real endpoints from day one. No mock APIs that quietly become production.
## Tool orchestration
- Parallel over serial. Batch independent reads, searches and writes into one
step. Never do them one at a time when order does not matter.
- Use subagents when a task has three or more independent parts.
- Use the strongest model for specs, decomposition and final review. Push the
bulk work down to a cheaper one and review the output. Never run the expensive
model in a tight loop.
- Commit at every milestone, not at the end. Clear the context between unrelated
tasks.
## Session behaviour
- Before writing code, read the project brief if one exists. If there is none,
ask which template to follow.
- Before calling UI work done, open it in a real browser and look at it.
- After any push, check for exposed secrets, broken auth, open endpoints and
dependency warnings.
- Watch every command output. Spot regressions immediately. Never claim
something works without showing the proof.
## Commit and repo conventions
- One repository per project.
- Main is production. Feature work on its own branch, merged after review.
- Commit messages: what was done, past tense, under 72 characters.
- Tag meaningful milestones, and pair the tag with a release so rolling back is
a menu choice rather than an archaeology project.
- Prefer reverting over force pushing. Never force push to main.
## Ambiguity rule
If any part of a request is unclear, ask one question, maximum, before starting.
Never guess at the goal, at what finished looks like, or at the scope.
## Tone
Grounded and direct. No hype. Match the clarity of the brief. No emojis unless I
use them first.
Why each part is in there
The reply format section is the one that changes your day. Out of the box the tool writes essays. On a wide monitor you end up reading a whole screen to find one number. Forcing "what I need from you" to the top means you can act on the first two lines and read the rest only if you want to.
The no dashes rule came from being caught. I sent a client a proposal full of em dashes and it read as machine written, because it was. The tool reaches for them constantly. Banning them in anything I forward, while allowing them in my own notes, fixed it in one line.
"No placeholder text, ever" is there because of lorem ipsum in a live page. The tool will happily fill a gap with something that looks finished. Now it has to tell me it does not have the content.
The stack section stops the same conversation happening weekly. Without it, every new project starts with a negotiation about frameworks. Write down what you use and it just builds.
The engineering rules are all scar tissue. The environment file line exists because a key ended up in a public repository. The auth by default line exists because it is far easier to open one route deliberately than to notice the one you left open. The rule about isolating user data from the token rather than the request is the difference between a working app and one where changing a number in the address bar shows you somebody else's account.
Parallel over serial is the biggest speed change in the file. By default work happens one step at a time. One instruction turns ten sequential lookups into one batch. On a long task it is the difference between minutes and an hour.
The model routing rule is about money. The strongest model is worth it for deciding what to build and for checking the result. It is a waste for the middle, which is mostly typing. Say so once and the cost drops without the quality dropping.
"Never claim something works without showing the proof." This is the most valuable sentence in the file. Without it you get told the tests pass. With it you get shown the tests passing. Those are very different things.
The ambiguity rule caps the interrogation. Ask for one question maximum and you get the one that actually matters, instead of a checklist before any work starts.
The one thing to do after pasting it. Change the reply format section to how you actually read. Mine is built for a wide screen and a short attention span. If you read on a laptop, or you want more explanation rather than less, say that instead. The rest of the file works for anyone. That section only works when it describes you.
I use cookies to measure whether my ads work. Nothing else.Privacy