🔁 Evolution by diff & consolidation
Add a little, consolidate often.
Your prompt grows through real need, not in advance. Here you learn the cycle test → find the failure → fix with a pattern e a consolidation round that prevents bloat — the same move that took Opus 4.8 to Fable 5 with +56 lines and 7 fewer blocks.
Detailed content
The cycle: test → find a real failure → fix it
Prompts aren’t ready-made — they evolve through use. The engine of evolution is a short, honest cycle: you run the prompt on a real case, observe where it in fact failure, and only then fixes it. The keyword is real: you fix the failure that happened, not the one you fear might happen.
The 4 cycle stops
Run the minimum viable prompt (Module 4.1) against a production input. Don't invent an easy test it can pass — use the case that matters.
Describe the symptom in one sentence: "it used an emoji without me asking," "it replied in 12 paragraphs." A failure without a reproducible symptom isn’t a failure—it’s a guess.
Apply one a catalog pattern that addresses exactly that symptom—and nothing else. Go back to step 1 and confirm that the failure is gone.
Real failure ≠ imagined failure
Most bloated prompts consist of rules against failures that never happened. Add a rule for the symptom you saw on screen. Everything else is anticipation—and anticipation fuels bloat.
Fix it with ONE pattern from the catalog
The difference between a prompt that ages well and one that turns into an onion of rules lies in how you fix it. The amateur fix adds “one more loose rule.” The professional fix chooses a named pattern from the catalog (Track 1), which addresses the class of the problem, not just the instance.
✗Standalone rule
- •"Never use the word 'actually.'"
- •Resolve the instance, not the class
- •If it accumulates: 1 symptom = 1 new line
- •No name → you can't consolidate it later
- •Becomes the “onion” that Fable 5 undid
✓Catalog pattern
- •"Assume a capable adult; no hedging." (Consolidated Principle)
- •Targets the whole class: covers "honestly," "actually"…
- •Generalizes to unseen cases
- •Has a name → can be labeled in the changelog
- •Ready to merge during consolidation
🗺️ From symptom to pattern
- •Model promised a tool it doesn't have → Scoped Capability Declaration
- •Answer too long → Concision Budget (Sheet 7)
- •Circumventable refusal / hard rule → Rule with Rationale (Sheet 3)
- •Four tiny guardrails throughout → Consolidated Principle (Sheet 12)
The consolidation round
Adding is easy; removing takes courage. That’s why consolidation can’t be left for “when there’s time”—it becomes scheduled ritual: every 3 additions, one cleanup round. Without the fixed trigger, the prompt just keeps growing, because each turn’s incentive pushes for "one more line."
What a consolidation round is
It’s a deliberate pause in which you adds nothing. You reread the entire prompt with three questions: what the model has already internalized (becomes noise; delete it), what repeats (deep), and which micro-rules can become a principle (consolidate).
The success criterion is counterintuitive: the round was successful if the prompt became shorter while preserving the same behavior in the tests.
The round, step by step
Run the test suite and note: line count + how many tests pass. You'll measure against those numbers.
Combine sibling rules under one principle; remove what the model already does on its own; rename blocks by intent, not imposition.
Same tests. If they pass with fewer lines: commit. If any fail: the removed rule was doing real work — restore only that one.
Every removal is a testable hypothesis
Don't decide by eye whether a rule "is still needed." Remove it and run the tests. If nothing breaks, it was noise. Consolidation is empirical, not a matter of opinion.
Imitating 4.8 → Fable 5
The diff of the Opus 4.8 for Fable 5 is the living example for this module. Anthropic added a lot of new content—and even so, the prompt grew by only +56 lines, because 7 blocks were removed. This is the central lesson: removing is part of evolving. Growth isn’t the goal; consolidation is.
📊 The diff numbers
- •4.8: 3.769 lines (~23,000 words)
- •Fable 5: 3.825 lines (~23,800 words)
- •Balance: only +56 lines — despite lots of new content, because 7 blocks were taken out
🗑️ What was removed — and why
- −
<search_first>— the model already searches through training; the obsessive instruction has become noise. - −
<default_stance>— the "help by default" stance was absorbed byrefusal_handling. - −
respond_without_citing_system_prompt— "don't say X" has a Streisand effect; it was addressed in training. - −4 tone micro-rules (no bullets when refusing, no pet names, no "honestly/actually," emoji rule) → merged into "assume a capable adult and treat them as such".
4 micro-rules → 1 principle: consolidation in its purest form
The microscopic guardrails signaled distrust of the model. A general stance covers everything — including cases no one listed. That is exactly the Consolidated Principle (Sheet 12) that you apply to your prompt.
Version in git
If every cycle and every consolidation leaves no trace, you lose the history. Versioning the prompt in git turns the student's history into their own "evolution repo" — each commit is a diff you can reread, compare, and, if needed, revert.
# adição 1 — falha real: respostas longas demais
git add prompt.md
git commit -m "add(concisao): orçamento de 2-3 parágrafos [Ficha 7]"
# adição 2 — falha real: recusa contornável
git commit -m "add(seguranca): regra com porquê na recusa [Ficha 3]"
# adição 3 — falha real: promete tool inexistente
git commit -m "add(capacidades): escopo explícito de ferramentas"
# gatilho: 3 adições → rodada de consolidação
git commit -m "consolidate: 4 micro-regras de tom → 1 princípio (-9 linhas) [Ficha 12]"
git log --oneline # o repo de evolução, legível de cima a baixo
git diff HEAD~1 # releia a última consolidação como um diff✓Good versioning
- •1 commit = 1 atomic change (1 addition OR 1 consolidation)
- •Messages cite the actual failure and the pattern applied
- •Consolidations marked with the line delta
- •Reverting is cheap → you dare to remove
✗Poor versioning
- •"update prompt" for 12 mixed changes
- •No trace of which failure motivated what
- •Edit directly, without a commit → no diff to review
- •Fear of removing it because you can't go back
Changelog with rationale
The commit records what changed; the changelog preserves why. Each entry labels the change by applied pattern e a failure that prompted it — exactly the format of the annotated diff 4.8 → Fable 5: change + likely motivation + lesson. This is the artifact that proves your prompt evolved for a reason, not by chance.
## v0.4 — rodada de consolidação
- consolidate: 4 travas de tom → "assume adulto capaz"
motivo: micro-regras sinalizavam desconfiança; -9 linhas
padrão: Princípio Consolidado (Ficha 12)
testes: 8/8 mantidos
## v0.3
+ add: escopo explícito de ferramentas
motivo: modelo prometeu "buscar na web" sem ter a tool
padrão: Declaração de Capacidades
## v0.2
+ add: regra com porquê na recusa
motivo: recusa seca era contornada por reformulação
padrão: Regra com Porquê (Ficha 3)
## v0.1
+ add: orçamento de concisão (2-3 parágrafos)
motivo: respostas de 12 parágrafos no caso de suporte
padrão: Orçamento de Concisão (Ficha 7)🧬 Anatomy of a good input
- •Type:
addorconsolidate— makes the pace of addition/cleanup visible - •Reason: the real observed failure (the symptom on screen), not the theory
- •Pattern: the catalog entry that justifies the form of the change
- •Tests / delta: the empirical evidence—passes/fails and lines added/removed
The changelog is your personal annotated diff
Three months from now, you won't remember why line X exists. The changelog answers that — and gives you the confidence to remove it in the next consolidation, because you know exactly which failure that line fixed (and whether it still exists).
🔁 Module Summary
Next: Module 4.3
Tests and the “documented why” (golden rule) — how to measure prompt quality by behavior, not opinion, and why every rule needs a test and a written reason.