Instruction conflicts, over-constrained prompts, prompt bloat

Read these first

• Context engineering — the budget

What you will know

• Find two instructions in a long prompt that contradict each other

  Conflicts often hide in scope, priority, format, and exception clauses, so a model may satisfy different subsets across runs.

• Improve a prompt by deleting from it

  A smaller instruction set reduces precedence collisions and token pressure, but representative evaluations are needed to catch regressions.

• Trace how a prompt accumulated contradictory or obsolete instructions

  Version history, copied templates, and emergency patches commonly preserve assumptions that no longer match the surrounding workflow.

• Audit a prompt that has not been reviewed in months

  Stale prompts often encode changed schemas, policies, or tool behavior while continuing to consume context on every request.

• Show that a removed instruction changed nothing, and remove it

  The deletion is only safe when outputs, failure cases, and relevant edge cases remain within the agreed acceptance criteria.

Chapters

1. 1

   Instruction conflicts

   An instruction conflict is a pair of rules that agree on most inputs, disagree on a narrow class of them, and declare no winner — so the model settles the contradiction afresh on every call and the failure looks like flakiness. Hunt them by writing down each rule's input class and the observable it constrains, because the wording of two colliding rules usually shares nothing at all.

   Read chapter
2. 2

   Precedence declarations

   A line saying one instruction takes precedence over all others ends the inconsistency by suppressing whatever the losing rule existed to surface, so a loud failure becomes a silent one and the declaration's scope is the whole prompt rather than the pair you found. The test before shipping one is whether the losing rule has anywhere to go, and the durable repair is usually a schema field that lets both rules be obeyed at once.

   Read chapter
3. 3

   Bisecting a prompt by deletion

   When a case that used to be reliable now passes four times in five and no conflict is visible on inspection, stop reading and start halving: cut the rule set in two, measure each half, keep whichever half still misbehaves. Because the failure is a rate rather than a verdict, each step needs enough samples to separate 0.80 from 0.95 — and both halves misbehaving is far more often an undersampled step than two independent conflicts.

   Read chapter
4. 4

   Prompt rule provenance

   Three tone instructions written by three people, one contradicting the other two: reading them cannot say which to keep, because that is a question about taste. The commit that introduced each rule, and the ticket or incident it cites, converts it into a question about fact — which rule's assumption is still true — and questions of fact can be closed by going and checking.

   Read chapter
5. 5

   Choosing which rule to delete

   Adding one more rule that states the intended behaviour is the fastest path to green, and it is the reason the prompt already has thirty-four rules: the conflicting pair survives, still fires on the input classes the new rule's scope clause did not name, and now has a third participant. Deciding which of the two colliding rules goes takes provenance, enforcement outside the prompt, and a question about which absence you would notice.

   Read chapter
6. 6

   Provoking cases for a deletion

   A frozen regression suite cannot report a regression in an input class it contains no cases for, so running it either side of a deletion tells you only that nothing else broke. Write a targeted set that provokes the rule — direct questions, social pressure, and controls against over-refusal — agree the acceptance criteria as assertions before the run, and validate the predicate that scores them against hand labels.

   Read chapter
7. 7

   Instruction set saturation

   When a new rule fixes one case and regresses two that passed last week, the instruction set has saturated: rules now interact at the edges and compete for adherence, so appending is negative-sum. The ledger of the previous ten rules is the argument, the discriminator between collision and dilution decides where to look, and the fix is to move deterministic constraints out of prose entirely.

   Read chapter
8. 8

   Auditing a prompt's referents

   Almost every instruction points at something outside the prompt — a label set, a tool name, a payload field, a policy, a queue — and those live in systems that change on their own schedule. An instruction whose referent is gone reads perfectly, obeys cleanly and produces well-formed output in the wrong class, so stop reading a stale prompt for sense and start resolving it against the live sources on every build.

   Read chapter