This changes from person to person — but here is what's in my global CLAUDE.md, so you can use it as a starting point.
Rules that belong in CLAUDE.md by default — Karpathy Rules
Some rules are so important that they should not live in an optional skill or plugin that may or may not run. Put them directly into CLAUDE.md so they apply on every coding, review and refactor task. The best example is Andrej Karpathy's coding guidelines:
## Coding Discipline
Apply these on every coding, review, or refactor task (Karpathy guidelines):
- **Think before coding** — state assumptions explicitly; if multiple
interpretations exist, present them instead of silently picking; if a
simpler approach exists, say so.
- **Simplicity first** — minimum code that solves the problem; no
speculative features, abstractions, configurability, or error handling
for impossible cases.
- **Surgical changes** — touch only what the request needs; don't refactor
or reformat unrelated code; match existing style; only remove orphans
your own change created.
- **Goal-driven** — turn each task into a verifiable success criterion
(a test or concrete check) and loop until it passes.
Pay special attention to the third rule. "Surgical changes" targets the most common LLM problem: breaking something else while doing what you asked for. Without this rule, models often try to "improve" nearby code — reformatting lines, renaming things, changing working logic they were never asked to touch. That is exactly where new bugs come from. This one line turns that behavior off: every changed line must come directly from your request.
More rules from my global CLAUDE.md
These are all general-purpose — copy the ones you like:
Reference doc rule
## Reference Doc Rule
Whenever a new `.md` documentation file is created, add a one-line
reference to it — in the same commit — in the CLAUDE.md of its level:
- Global file under `~/.claude/` → reference in `~/.claude/CLAUDE.md`,
under the Reference Docs section.
- Project file (e.g. `memory.md`, `design.md`, handoffs, specs) →
reference in that project's `CLAUDE.md`.
Format: - [`filename.md`](./filename.md) — one-line description.
A doc that CLAUDE.md never mentions will never be read.
**User-agnostic paths in .md files:** when a markdown file records an
absolute path under a user profile, write it as `C:\Users\<user>\...`
— never a specific username; every reader has their own. Code and
configs keep real paths; this rule is about documentation. When using
such a path, resolve `<user>` from the current environment.
**Docs-first pointer wording:** when a CLAUDE.md delegates a project's
rules to a reference doc, never scope the pointer to changes only.
Word it as docs first, code second, for ALL work: "read it before any
change AND before answering any question about how something works —
the code is only the implementation of those rules."
Wikilink compatibility
## Wikilink Compatibility
If a `.md` file I'm already editing contains a `[[wikilink]]` and I can
resolve the target file, add a markdown link next to it pointing to the
same target: `[[design]] ([design.md](./design.md))`. If the target
can't be resolved, leave the wikilink untouched. Never sweep unrelated
files for this.
The `+name` shorthand — save rules as you chat
## Quick MD-Update Shorthand (`+<name>`)
When a message contains a `+<name>` token (e.g. `+design`, `+admin`),
take the rule stated in that sentence and add it to the markdown file
`<name>.md`. Look in the current project first; if the file is not
there, use the global `~/.claude/<name>.md` (create it if missing).
A trailing `g` (`+design g`) means: always write to the global file.
Don't duplicate — if an equivalent rule exists, refine it instead.
How it works in practice — you are chatting with Claude and notice something you want as a permanent rule. Just add the token to your sentence:
# inside Claude Code — a normal chat message
Numeric table columns should always be right-aligned. +design
That's it. Claude writes the rule into design.md and keeps working. Next session, the rule is already active — you never open the file yourself. Instead of typing a long sentence like "please add this rule to my design.md file", you just say +md — and it's done.
Terminology consistency
## Terminology Consistency
Within a project, use ONE consistent term for each concept everywhere
it appears — labels, tooltips, headings, docs. Never mix synonyms for
the same thing; never reuse one term for two different concepts.
Project memory file
## Project Memory File
Every project should have a `memory.md` at its root — a condensed,
human-readable reference: ports & commands, data model, architecture,
design decisions, and known gotchas. Reference it from the project's
CLAUDE.md and keep it current as the project evolves.
Restart servers yourself
## Server Restarts
When the local backend/dev server needs a restart, do it yourself —
don't ask me to do it.
Cache invalidation on mutations
## Cache Invalidation on Lookup Mutations
Any project that caches lookup/reference data must invalidate that
cache immediately after every mutation (POST, PUT, DELETE). Changes
must show up instantly — never wait for a TTL or a server restart.
The `question:` prefix
## `question:` Prefix
When a message starts with `question:`, take NO action — no edits,
no commands, no fixes. Only answer the question, nothing more.
The `got it` suffix
## `got it` Suffix
When a message ends with `got it?` or `got it`, explain back to me
what you understood — your interpretation, assumptions, and planned
approach — and take NO action until I explicitly confirm.
Terminal commands — one per line
## Terminal Commands — one per line
When giving commands to run in a terminal, provide them as single-line
commands, one per code block, so each can be copied and pasted as one
line. No multi-line blocks, no line continuations, no heredocs.
Auto-Commit Policy
## Auto-Commit Policy
Commit automatically after each completed and verified unit of work —
don't ask first each time.
- Commit only when the change works (build/tests/manual check pass).
- One feature/fix per commit, with a clear message.
- Commit to the current branch, local only. Never `push` without
my explicit approval.
- Never commit secrets (.env, files with passwords/tokens/keys).
Takeaways
- CLAUDE.md is the only file Claude Code reads automatically — treat it as the master rulebook.
- Child .md docs exist only if CLAUDE.md references them. New doc → new reference line, same commit.
- Always-on rules (like the Karpathy coding discipline) belong inside CLAUDE.md, not in a skill that needs to trigger.
- Keep it short and current — you pay for its content in every session.
