Your CLAUDE.md is being skipped.

The documentation is direct about it, and reading it changes what you expect from the file:

"Claude treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead."

code.claude.com, How Claude remembers your project

Two more lines from the same page matter, and both are actionable:

• On size: "target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence." So the file gets worse as it grows, and everyone's file grows, because every correction gets appended to it.
• On compliance: "there's no guarantee of strict compliance, especially for vague or conflicting instructions." Which puts the burden back on wording, and wording only goes so far.

None of that is a flaw in the design. A file loaded into a conversation is a file loaded into a conversation. It was never a place where things get checked.

Four cases, and we mean them. If you are in one of these, close this page and go and write the file.

• One person, one project, a few weeks. Nobody else needs the rules, nothing has to survive a handover, and you hold the whole thing in your head anyway.
• Your rules are conventions, not obligations. Two-space indentation, a naming pattern, where files go. If the agent gets one wrong, you fix it in ten seconds and nothing was at stake.
• Your sessions are short. You start and finish a piece of work in one sitting. Nothing has to be carried across a boundary, so nothing gets lost at one.
• You are still learning the tool. One file you can read is worth more right now than a system you have to learn alongside the thing you came to learn.

Adding anything to those situations is a cost with no return. We would rather tell you that than sell you something you will resent in a week.

Before adding anything at all, three free changes, all of them straight from the documentation.

1. Get it under 200 lines

That is the documented target, and the stated reason is that longer files reduce adherence. Most files are long because corrections were appended and nothing was ever deleted. Cut it. Half the entries are things the model would have done anyway.

2. Scope the rules that only apply somewhere

A rule about API handlers does not need to be in the window while the agent styles a button. Path-scoped rules load only when a matching file is read. Moving them out is how you get under 200 lines without losing anything.

3. For the few rules that must happen, use a hook

This is the vendor's own advice in the quote above. A hook runs as code at a fixed point, regardless of what the model decides. Keep the list very short, because a guard you start bypassing is worse than no guard.

Do those three and the file will carry you a long way further. When it stops carrying you, it will be for one of the reasons in the table, not because of the wording.

Mission HQ is not a better file. It is a different shape, and it is worth understanding before you decide you need it.

Rules arrive with the task, not at the top of the session

Conventions are stored per area of work and delivered when a task of that kind starts. Nothing about the database sits in the window while a button is being built.

A delivered rule brings its own checks

When a way of working is delivered, its done-checks attach to that task as items that have to be answered before it closes. That is the part a file cannot have, because nothing reads a file back and asks.

The work state is separate from the instructions

A CLAUDE.md holds rules. It has nowhere to put what is half done, what failed, and what to do next, which is why people end up with a second file for that. Those are records here, and they survive the session ending.

Your teammate gets what you taught

The rules live with the project rather than on a machine. Worth knowing: the documentation says auto memory "is machine-local" and that its files "are not shared across machines or cloud environments", so what your laptop learned your teammate's laptop does not know.