Your team needs a rule that must hold on every run regardless of what Claude decides in the moment. Where does it belong?

The principle — match the mechanism to the requirement. "Should" and "must" live in different places.

Why the key is correct — Anthropic draws the line explicitly: settings rules are enforced by the client regardless of what Claude decides to do, while CLAUDE.md instructions shape Claude's behaviour but are not a hard enforcement layer. A requirement stated as must therefore belongs in settings. The reason CLAUDE.md cannot carry it is structural rather than a matter of quality — it is delivered as a user message after the system prompt, which makes it context to be weighed rather than configuration to be obeyed.

Why the others are wrong — strong wording does not convert context into enforcement, and betting a hard requirement on emphasis is how teams discover the distinction the expensive way. Repeating the rule in a second file adds context without adding force, and duplicated instructions are a common source of the contradictions that make adherence worse. And auto memory is written by Claude and is context in exactly the same sense, so it is further still from a guarantee.

Remember this — if the answer to "what if Claude decides otherwise?" is unacceptable, you need settings, not instructions.

Sources — Anthropic's memory page.