# Your CLAUDE.md Rules Are Probabilistic: Why Claude Quietly Deprioritizes Some Instructions

> Source: <https://dev.to/olivia_craft/your-claudemd-rules-are-probabilistic-why-claude-quietly-deprioritizes-some-instructions-29jc>
> Published: 2026-06-03 05:39:22+00:00

You wrote the rule clearly. You put it in your CLAUDE.md.

```
Never push to production without explicit user confirmation.
```

Claude read it. You can tell because it follows it most of the time. Then one session, mid-task, it pushes to production without asking.

No error. No warning. No "I know you said not to, but..."

Just: done.

This is not a bug. It is how CLAUDE.md actually works — and most developers do not know this until something breaks.

Here is what the Claude Code documentation does not say loudly enough:

**CLAUDE.md instructions are injected as user-turn context, not as system prompt.**

This matters because:

The result: your rules are **probabilistic constraints**, not deterministic ones.

Claude does not read your CLAUDE.md once and lock those rules in. It reads them at each turn as part of its context window. This means:

**Rules that get followed reliably:**

**Rules that get dropped silently:**

The worst case: you have two rules that contradict each other. Claude picks one. It does not tell you which one it picked, or that it had to choose.

When your session gets long, Claude Code compacts its context window. This is a summarization — your CLAUDE.md rules get compressed into a shorter version.

Some rules survive the compression. Others do not.

And here is the critical part: **Claude does not tell you when a rule was dropped from the compressed context.** The next task runs with an incomplete ruleset. You will not know until the behavior breaks.

After observing how CLAUDE.md rules actually degrade in practice, here is what improves reliability:

**1. Lead with critical rules**

The first 20 lines of your CLAUDE.md carry more weight than the last 20. Put your safety-critical rules at the top.

**2. Use imperative, single-sentence rules**

Not: "When possible, try to avoid making large refactors unless you are very confident."

But: "Do not refactor existing code unless explicitly asked."

**3. Mark rules with explicit weight signals**

```
CRITICAL: Never push to production without user confirmation.
```

The word "CRITICAL" acts as a salience signal. It is not a guarantee, but it helps.

**4. Avoid contradictions**

Audit your CLAUDE.md for rules that pull in opposite directions. Claude will resolve them silently. You want to resolve them first.

**5. Keep it short**

A 50-line CLAUDE.md with clear rules beats a 200-line CLAUDE.md with nuanced guidelines. Density works against you.

The mental model shift is this: you are not writing a config file. You are writing instructions for a reasoning system that has to balance your rules against everything else it knows.

That means:

This is not a workaround. It is how high-reliability CLAUDE.md files are built.

If you want a tested CLAUDE.md structure that accounts for probabilistic compliance, compaction survival, and instruction conflict resolution, the [CLAUDE.md Rules Pack](https://oliviacraftlat.gumroad.com/l/skdgt) includes:

[Get the CLAUDE.md Rules Pack — $27](https://oliviacraftlat.gumroad.com/l/skdgt)

Or start free: [Free CLAUDE.md Starter](https://oliviacraftlat.gumroad.com/l/pomoo) — includes the core rules structure.

*Built from watching what breaks. If you have a rule that Claude keeps ignoring, it is probably a structure problem, not a Claude problem.*