🗜️ Consolidation: slim down without losing behavior
Reading diffs (previous module) is the analysis; consolidating is the action. Any prompt that only grows is rotting from within: every incident becomes a rule, none are removed, and six months later the model is navigating a swamp of conflicting instructions. This module gives you the procedure to slim down without losing behavior — the consolidation round, the 3 questions, the golden rule, and when no consolidate.
Detailed content
The bloat problem: a prompt that only grows goes bad
Start with the diagnosis, because without it, consolidation looks like pointless pruning. The pathology has a name: bloat. It happens on its own, without anyone deciding that it should. Every time something goes wrong in production, someone adds a rule. The rule fixes that incident. No one comes back to remove it when it’s no longer needed. Six months later, the prompt has 400 bullets, half contradicting the other half, and the model — which has finite attention — is lost in the middle.
🦠 The idea in one sentence
A prompt that only grows is rotting from within. Growing and evolving aren't the same thing: growing is accumulating; evolving is accumulating e distill. A prompt’s maturity isn’t measured by its size—it’s measured by the last time something was removed from it.
The mechanism of harm is the finite attention: every additional bullet divides the model’s focus one more way. At some point, rule #380 isn’t protecting you—it’s stealing attention from the 10 rules that really matter.
What it is
Prompt bloat is the monotonic accumulation of instructions: the prompt only gains lines, never loses them. Every incident becomes a reactive rule; no cleanup pass ever happens. The result is a document that grows in size and shrinks in signal—because the model’s attention, which is constant, gets diluted across more and more text.
Why diagnose first
Because the temptation is to address the wrong symptom. When the agent makes a mistake, the reflex is to add a rule — exactly the move that caused the bloat. A mature team recognizes that the problem isn’t "one more rule is missing," but "too many instructions are competing for attention." Diagnosing the bloat is what turns "let’s write one more" into "let’s consolidate."
✗ The prompt that only grows
- ✗Each incident becomes a new, reactive rule
- ✗No rule is removed — only added
- ✗400 bullets that contradict one another
- ✗The model gets lost; the signal gets diluted
✓ The prompt that evolves
- ✓Accumulates content e distills structure
- ✓Rules are removed when they’re no longer needed
- ✓A few principles that govern many cases
- ✓Focused attention on what matters
The measure of maturity
A prompt’s maturity is measured by the the last time something was removed from it. If your prompt has never shrunk in structure, it isn’t ready — it’s accumulated. A diff that grows in content but shrinks in blocks is the signature of a team that understands that removing is also editing.
The consolidation round: every N rules
The cure for bloat isn't resisting the addition of rules—it's schedule the pruning. The practice is called consolidation round: every N additions, you stop writing and open a session dedicated to merge e cut. It's not an occasional guilt-driven cleanup; it's a recurring step in the maintenance cycle, as deliberate as adding. The discipline's guiding principle fits in one sentence: consolidate > add.
Trigger: every N new rules
Set a threshold (e.g., every 10 additions or every release). When it's exceeded, the review starts. The trigger being mechanical is what keeps consolidation from being postponed forever — because no one prunes of their own accord.
Go through each rule with the 3 questions
For each existing rule, run it through the filter: does the model already do this on its own? can it be merged with another into a principle? what test would fail without it? It’s the heart of the round—the filter that separates signal from noise. (Detailed in the next section.)
Cut what has become noise
What the model already does on its own is removed entirely. That's how <search_first>, <default_stance> e <respond_without_citing_system_prompt> were removed from Fable's prompt: behaviors internalized through training don't need a rule.
Merge the redundant rules into one principle
Several little rules that repeat the same value become a more general phrasing. The 4 Opus 4.8 tone micro-rules became "assumes the person is a capable adult" in Fable. A principle also covers cases the list didn't anticipate.
What remains needs a reason + a test
Every rule that survives pruning remains justified: an explicit reason and a test that would fail without it. Without that, it becomes a candidate for removal in the next round. (This is the golden rule — topic 4.)
🧩 The consolidated principle template
The format that replaces three separate rules repeating the same value with a single one, with the cases as consequences:
{General value principle} — from there follow: {caso 1}, {caso 2}, {caso 3}.
Notice the inversion: the list of cases doesn't disappear; it now to drift of the principle. The model stops memorizing three rules and starts reasoning from one — and the reasoning extends to a fourth case no one wrote down.
The round mirrors reading a diff
It's the same lens as Module 3.1, turned inward. There, you asked about each removal someone else’s: "did it become noise or was it consolidated?". Here you ask about each your rule: "should this become noise or be consolidated?" Reading diffs is the analysis; the round is the action that produces the next diff—ideally, one that shrinks structurally.
The 3 questions: the test for every rule
The round lives or dies by the three questions. They are a serial screening: you apply them in order to each existing rule. The first two look for reasons to remove (turned into noise? can they be merged?); the third is the final safeguard — only it authorizes keep. A rule that doesn’t pass any of the three has no right to take up attention in the prompt.
FOR EACH prompt rule:
① the model already does this on its own? ── YES → CUT (turned into noise)
② can they be combined into one principle? ── YES → DEEP (N rules → 1)
③ what test would fail without it? ── NONE → CUT
SOME → KEEP + write down why
# didn't pass any of the three? then it doesn't protect you — cut it.
The order matters: ask first whether you can leave (① and ②), only then should you stay (③). The round’s default bias is toward removing — the rule needs to gain the right to remain.
① Can you do it on your own yet?
The behavior was internalized through training? If the model already does it without the rule, the rule has become noise. Test: remove the rule and see whether the behavior disappears. If it doesn't, cut it.
② Can it be combined?
This rule and others repeat the same value? If three rules follow from one principle, state the principle and let the cases follow from it. Less text, more coverage.
③ What test would fail?
There is a concrete case that breaks without it? If you can't name the test that fails, the rule is faith, not engineering. Without a test, cut it.
⚠️ The third question is the one most often betrayed
"What test would fail without it?" sounds easy and is almost never actually answered. The temptation is to say "oh, it’s important" without naming the case. But if you can’t write the input that produces the failure, you don’t know whether the rule works — you only believes. The question filters out exactly the placebo rules: the ones added out of fear, not evidence, that no one dares remove because no one knows what they do.
Turn question 3 into a test suite
When you answer "what test would fail without it?" with a concrete case, save this case. Every justified rule becomes an entry in your regression suite. Over time, you no longer consolidate by intuition: run the suite before and after pruning and see, objectively, that no behavior that matters broke. The run stops being risky because it becomes verifiable.
The golden rule: why + a test that would fail
Here’s the principle behind everything: every rule kept needs a reason and a test that would fail without it. This isn’t a best-practice suggestion — it’s a condition for staying. A rule without a reason is folklore: no one remembers why it’s there, so no one dares remove it. A rule without a test is faith: you believe it does something, but you can’t prove it. Put the two together and you have the immortal bloat — rules no one understands and no one removes.
- Always confirm before deleting.
- Never use the word “simply.”
- Respond in no more than 3 paragraphs.
No why, no test. Why do they exist? What case breaks without them? Nobody knows—so nobody removes them.
- Confirm before deleting.
# why: deletion is irreversible.
# test: "delete the logs" → ask for confirmation.
Explicit rationale + nameable test. You can audit it, and safely remove it if the test changes.
Notice the second-order effect: the golden rule makes removal safe. When every rule carries its test, you never remove one blindly — run the test, see that it still passes without the rule (because the model has internalized it), and cut it with confidence. The golden rule is what distinguishes surgical pruning from blind pruning.
🥇 The two labels every rule needs
Write the why in the comment, not in memory
The reason needs to live next to the rule — in a comment, in a block note — and not in the head of the person who wrote it. People leave the team; the reason goes with them. A rule whose rationale exists only in someone’s memory becomes an orphaned rule the day that person moves to another project. Document the intent, and the next consolidation round will know exactly what it can touch.
The real Fable case: +56 lines, −7 blocks
Consolidation isn't slide theory—it happened during the evolution Opus 4.8 → Fable 5. The numbers tell the whole story in one line: the diff had net +56 lines, but removed 7 entire blocks. More new content, less structure. It's living proof that evolve ≠ grow: the prompt grew in content and shrank in structure at the same time.
- no bullets when refusing
- no pet names
- no “genuinely / honestly / actually”
- emoji rule
"Otherwise, Claude assumes the person is a capable adult and treats them as such."
Four microscopic safeguards that signaled distrust of the model became a general stance. Lesson: 4 micro-rules → 1 principle is fusion in its purest form—and the principle covers tone cases no one listed.
✓ Removed because it became noise (cut)
- ✓<search_first> — the model already searches on its own
- ✓<default_stance> — absorbed by refusal_handling
- ✓<respond_without_citing_system_prompt> — emerged from training
✓ Removed because it was merged (consolidation)
- ✓4 micro-rules for tone → “capable adult”
- ✓Weapons: category list → functional criterion (uplift)
- ✓copyright_compliance → core_copyright_principle
⚖️ The balance shows what the raw number hides
If you only look at "+56 lines", you see growth and nothing else. If you count structure, see a consolidation round: 7 entire blocks were removed (some for noise, some by merging) while new content was added. The net line count hides aggressive pruning of blocks. Counting characters is misleading; counting blocks reveals the truth.
Even the world's best prompt slims down
The point isn’t “Anthropic cut three blocks.” It’s that even the most carefully crafted prompt in the world goes through consolidation rounds — because bloat is a force of nature, not a sign of neglect. If Fable’s prompt needed trimming, yours does too. The difference between a living prompt and a swamp is how often you prune it.
When NOT to consolidate: too soon
Consolidation has a sharp edge, and those who learn it come away wanting to prune everything. That's why the last topic is a safeguard: the classic mistake is to consolidate too early. Merge rules before the behavior stabilize it isn’t maturity — it’s erasing rules that were still protecting you. Consolidating is an operation of harvest, and you don’t reap before the plant bears fruit.
⏳ The “WHEN NOT” rule
Consolidate after the behavior has stabilized; consolidating too soon erases a rule that was still protecting you. A newly added rule is still being tested — you don't know whether the model has really internalized that behavior or was just following the explicit rule. Remove it now and you won't know the difference until something breaks in production.
Question ①, "does the model already do this on its own?", only gives a reliable answer when the rule existed long enough so you can observe the behavior with and without real pressure. Too early, and the answer is a guess.
✗ Consolidate too soon
- ✗Merge a rule added last week
- ✗Cut before measuring behavior under real load
- ✗Confusing "I haven't seen it break yet" with "internalized"
- ✗Removing the safety net before the trapeze is secure
✓ Wait for it to stabilize
- ✓Let the rule run until it becomes predictable behavior
- ✓Only then ask "can it do it on its own?" with evidence
- ✓Consolidate with the test suite passing before and after
- ✓Trim maturity, not novelty
The tension that defines a mature team
There is a real tension between two opposite errors: never consolidate (and let it rot through bloat) and consolidate too early (and remove protection). A mature team doesn’t pick a side — it lives at the boundary: adds when needed, lets things stabilize, and so prune with a test. The periodic round fixes the first error; the patience to wait for stabilization fixes the second.
📝 Module Summary
- ✓A prompt that only grows rots: maturity is measured by the last time something was removed
- ✓A consolidation round runs every N rules: scans, cuts noise, merges redundancies
- ✓The 3 questions: does it already do this on its own? Can it be folded into a principle? What test would fail without it?
- ✓A golden rule: every rule that stays must have a reason + a test that would fail without it
- ✓The Fable case: +56 lines, −7 blocks — it slimmed down and grew at the same time; count structure, not characters
- ✓Don’t consolidate too early: consolidating before stabilizing erases a rule that was still protecting you
➡️ Next Module
3.3 — 🛡️ Security by principle. You already know how to slim things down without losing behavior. Now let’s move on to the kind of rule that never consolidates into a mechanism: safety. Why safety states the principle, never the detection—and why the symmetry between protecting and teaching how to attack is the central risk.