Where instructions live in Claude: the full map, and who holds each pen

Every post on this site ends with standing orders and a note telling you to commit them to your CLAUDE.md. Fair question in response: which CLAUDE.md? Because it turns out there are about fifteen places an instruction can live in the Claude ecosystem, they load in a specific order, they’re written by at least five different parties — and a few of them you can’t even see.

So I mapped all of it. I verified every location against current docs, then handed the inventory to GPT and Gemini and asked each for placement philosophy and disagreements before writing this. Where they changed my mind, I say so. Where I think they’re wrong, I say that too.

One note on method: everything below is verified against Anthropic’s memory docs and the org-instructions article as of July 2026. This stuff changes. Check dates before trusting anyone’s map, including mine.

The map

Three product lanes, six scope bands, and one strip at the bottom for text that enters your context without you writing it. The colors are the part that matters: green is you, violet is Claude writing about you, amber is somebody else’s pen.

Chat lane (claude.ai, desktop, mobile)

Naming clarity, because I couldn’t keep it straight either: the chat-side memory feature is just called Memory — Settings → Capabilities → Memory, free for everyone since March 2026. It synthesizes a profile from your chat history, you can read and edit it, and each Project keeps its own isolated memory. Organization instructions are the Team/Enterprise layer: admins set up to 3,000 characters that apply to every conversation org-wide, they win conflicts with your individual instructions, members can’t opt out, and no menu shows them to members — though in practice the model itself will usually recite what’s steering it if you ask. Treat them as unlisted, not secret.

Claude Code lane

The ones people don’t know: .claude/rules/ takes topic files with optional paths: glob frontmatter, so a rule like “all API handlers get input validation” loads only when Claude touches matching files. Auto memory is Claude’s own notebook at ~/.claude/projects/<project>/memory/ — a MEMORY.md index that loads its first 200 lines or 25KB per session, plus topic files read on demand. Subagents carry their own system prompts entirely. Output styles modify the actual system prompt — and a plugin can mark one auto-applied. And the detail that reframes everything: your CLAUDE.md is not the system prompt. It’s injected as a user message after the system prompt. The only true system-prompt access you have is the flag family and the API.

API lane

The system parameter and your tool definitions. That’s it. No memory, no hierarchy, no inheritance. The API is the honest lane: one layer, and you own it.

When to use which: five rules

The models and I converged on most of this. The synthesis:

1. The one-violation test. This is GPT’s framing and I’m keeping it: would you tolerate Claude violating this rule once, provided a human caught it after? If yes, it can be an instruction. If no — “never push to main,” “never read .env” — it doesn’t belong in the instruction plane at all. It belongs in enforcement: hooks, permissions.deny, branch protection, credentials. Anthropic’s own docs draw this line: memory files are context, not configuration. Instructions influence. They do not enforce.

2. Match load to relevance. Every line in an always-loaded file taxes every session forever. If a rule matters in most interactions, it earns a spot in the root CLAUDE.md. If it matters only for certain files, it’s a path-scoped rule. If it’s a procedure you run occasionally — a release checklist, a migration ritual — it’s a skill, loaded on demand. The common mistake is treating “might occasionally matter” as “must consume context forever.”

3. Match the layer to the owner. The layer should belong to whoever is entitled to make the rule. Team conventions go in git-tracked project files where they get reviewed. Personal preferences go in your user file. The test for the user-global file is severe, and GPT’s version is the right one: would this still be correct in an unfamiliar repository owned by another company? If not, it’s not global.

4. Shared semantics need shared visibility. If your private ~/.claude/CLAUDE.md says all new endpoints return RFC 7807 problem details, and that’s actually a team rule, it’s in the wrong place — your agent behaves differently than your teammates’ and nobody can see why. Private layers may set personal style. They must not silently define shared engineering behavior.

5. Volatility argues for narrower placement. The more often something changes, the closer it should live to the work — a task note, an issue, a rule with an expiration date. A broad instruction with a short half-life has the worst of both: a big blast radius and lots of time to go stale before anyone notices. Sprint priorities do not belong in organization instructions.

The hidden pens

Here’s the part that made this worth writing. Count the layers someone other than you controls:

Your admin writes organization instructions you can’t opt out of — and won’t find in any menu, though the model will usually recite them if asked — and they beat your own instructions on conflict. Your IT department deploys managed policy that loads first and can’t be excluded. Your teammates commit CLAUDE.md files and hooks that shape your sessions — and a committed CLAUDE.md can @import files from outside the repo, which is exactly why Claude Code shows an approval dialog for external imports. Plugin and MCP authors inject tool descriptions and can auto-apply output styles — text nobody reads, sitting in your context, and occasionally it isn’t describing a tool so much as trying to steer the agent. And Claude itself accumulates auto memory silently while you work. Beneath all of it sits the vendor’s pen: Anthropic’s own system prompt loads before every layer on this map — and to their credit, the chat versions are published in the official release notes, making it the one hidden pen with public documentation.

GPT’s formula for triaging which of these deserve worry: risk equals authority times capability times invisibility. A visible, git-reviewed CLAUDE.md scores low. An unpinned plugin that ships an auto-applied output style and executable hooks scores high. The single best governance idea from the whole consultation — GPT again — is one I’d like to see someone build: an effective-instruction manifest. One command that answers: what instruction-bearing sources loaded this session, who authored each, at what version. /context and /memory are partial versions of this today. Run them. Most people never have.

And if you’re an admin setting invisible org instructions: publish the text internally anyway, with an owner and a change date. Steering people’s tools with prose they can’t read is a trust decision, not just a config decision.

The fight: auto memory

I wanted disagreement and I got it, and it clustered exactly here.

Gemini’s position: disable auto memory entirely for team repositories. Its phrase — which is too good not to credit — is that auto memory creates “compiles on my agent” syndrome: Claude learns the auth workaround on Alice’s machine, writes it to her machine-local memory, and now her agent succeeds where Bob’s fails, with the knowledge sitting in an untracked file nobody reviews. GPT lands nearby but softer: auto memory should be treated as a private, low-authority scratchpad — the moment a learned fact matters to shared output, it must be promoted out to a human-owned, reviewed location.

My position, having run agent memory systems for a while: they’re right about the failure mode and wrong about the fix. The problem isn’t the layer — it’s the missing promotion ritual. Auto memory is the cheapest learning channel you have; disabling it throws away signal. What it needs is the same discipline any inbox needs: review it on a cadence, promote what’s load-bearing into git-tracked files, delete the rest. If a memory entry would change a teammate’s result, it was never memory — it was an undocumented team rule the moment it got written, and the promotion is just you noticing.

Where all three of us actually agree, and where I’d bet Anthropic’s docs will eventually firm up: machine-local, model-written state must never be the system of record for anything a team relies on.

Keeping it from rotting

These layers accrete. Rules go stale, contradict each other across files, and the docs are explicit that when two instructions conflict, Claude may pick one arbitrarily — a duplicated rule isn’t reinforcement, it’s a future conflict. The maintenance discipline is the same as any config: every durable instruction gets an owner and a reason, temporary rules get expiration dates, and deletion is the default for anything restating what the code already says, describing a finished migration, or preaching vague virtue (“write clean, secure code” has never once changed a model’s behavior). Run /context when behavior surprises you. The answer is usually in a file you forgot was loading.

The lesson

Instructions are a filesystem, not a setting. They have scopes, owners, load order, and drift — and at least three of the pens writing into your context aren’t yours. Know the map, put each rule in the narrowest layer that reaches the work, move anything with a zero-tolerance failure mode out of prose entirely, and audit what actually loaded before you blame the model.

SOs

SOs — standing orders you can lift and prime your own agent with. (New here? The convention started with the Neverland post.) Paste them into a session for a one-time dose, or commit them to your CLAUDE.md / AGENTS.md — and after this post, you know exactly which one.

STANDING ORDERS — Instruction placement
Source: "Where instructions live in Claude" — bensimon.dev

1. When given a durable instruction mid-session, propose its correct layer
   before moving on: session-only, project file, path-scoped rule, skill,
   user file, or enforcement. Name the layer and why.

2. Apply the one-violation test out loud. If violating the rule once would
   be unacceptable, say it doesn't belong in an instruction file and
   propose the enforcement mechanism instead.

3. When asked why you behaved a certain way, list the instruction sources
   that loaded this session and which one drove the behavior, so the human
   can audit the layer, not guess.

4. Never write project-shared truth to machine-local memory without
   flagging it for promotion to a reviewed, version-controlled file.

5. When you notice two loaded instructions in conflict, surface the
   conflict and the file paths. Never silently pick one.

6. On request, report who holds the pen for any active instruction:
   the user, the team, an admin, a plugin, the vendor, or you.