What does a conflicting instruction set cost you? For one, time and tokens, not to mention the constant headache to figure out the "why?". An instr...
For further actions, you may consider blocking this person and/or reporting abuse
The sharpest insight here is counterintuitive: a smarter model makes this harder to catch, not easier. 4.x flip-flopping was an accidental smoke alarm; Opus 5 committing consistently to the losing rule removes the only symptom you had. The "consistent with the wrong rule" framing should end the reflex to bold-and-shout.
"a smarter model makes this harder to catch, not easier" -> especially if there is an overconfident LLM-as-a-judge in the loop
A 90 point swing from moving one rule down a file is a big enough effect that the next question is whether it survives assembly. Your setup holds the file constant and moves the rule inside it, and you already point at nested src/CLAUDE.md as a place contradictions hide. What actually reaches the model is several files concatenated, root down to working directory, with @path imports expanded at launch up to four hops, and subdirectory files loading on demand when the agent reads in that subtree rather than at startup. The docs say those files are concatenated rather than overriding each other, which describes assembly and stops short of saying anything about precedence, so your within file result is currently the only evidence either way. Did you run the same swing across a boundary, one rule in the project file and its exception in a nested or imported one? If position still governs there, the practical advice changes, and your static analysis gets harder, because the pairs to compare now live in different files.
The easiest way to approach the position is thinking it like recency.
An instruction at the later end in the file will be the more recent instruction from the LLM perspective. Some goes for the @path. When you have something like that the harness (claude specifically, as other - if memory serves me right - coding agents are not resolving it) will resolve it "in-line". Basically you are injecting a file in a file, at the position of the @path.
You can also extend this thinking to other harness artifacts, like skills/rules/agents/memory, the results will be the same. Recency (among many other things) governs.
This is the same failure mode we run into constantly with architectural rules, not just CLAUDE.md instructions: a contradiction resolves silently and the only signal is behavior, after the fact. We ended up building Mneme specifically to surface that moment, flag the conflict instead of letting position in a file decide it for you.
Interesting concept! Would it be okay if I'd run reporails (github.com/reporails/cli) diagnostic on your CLAUDE.md?
This makes me think instruction files need something closer to a dependency/constraint model rather than just being treated as documents.
A rule can be perfectly valid by itself and still become dangerous when combined with another rule somewhere else. The hard part is therefore not just finding “bad instructions”, but understanding the relationships between them.
I especially like the distinction between detecting a contradiction in the text and observing what the agent actually does at runtime. Those feel like two separate layers of governance.
The interesting next step to me would be tracking which rules are durable constraints, which are scoped exceptions, and which are temporary workflow instructions — because otherwise the file slowly becomes a collection of rules with no clear authority model.
true that. That's why you use progressive disclosure and you ensure that your instructions are formalized (using whole sentences with object/subject/predicate/scope). Once that's in place contradiction/conflict detection becomes relatively easy.
I'm experimenting with a system that works in tandem with Reporails: it's assessing task-instruction parity and if it detects deviations it stops the running agent with an error message and a lineage of relevant instruction loading logs.
I'd highly recommend implementing such system anywhere where you want to have a reliable AI architecture
the 'position decides, and we measured the size of that' section is the finding i'd flag for any project running a heavy CLAUDE.md. the silent resolution is what makes it hard to catch — the model produces confident output regardless of whether two rules agree, so there's no signal a conflict fired at all.
the Opus 5 commits harder result is counterintuitive but tracks: a better model doesn't hedge ambiguous instructions, it commits to a reading and goes. that's correct resolver behavior. it's wrong if you didn't know you were resolving a conflict.
are you building anything to surface which rules actually fired vs which were silently dropped? the diff reading approach works per session but doesn't scale.
yes,
it's in beta version (0.5.12): github.com/reporails/cli
0.6.0 is under development, will be released in the next week or so.
infromative.
thanks.
I'm glad you find it informative