Learning path map
🔬 Reading evolution through diffs
Each +/− line is a decision
🗜️ Consolidation
Prune without losing behavior
🛡️ Principle-based safety
The principle, never the mechanics
🪜 Priority and layers
Who’s in charge and what’s dynamic
🧠 Distillation: recover the brain
The heart of the course—from logs to guide ⭐
⚙️ Willingness × hard guarantee
Soft guide + guardrails that never fail
🏁 Final project
Your version-controlled system prompt
Detailed content
🔬 Reading evolution through diffs
When a lab changes versions, it leaves a trail: the diff between the old prompt and the new one. Reading that trail is decision archaeology—each line added, removed, or renamed tells you why someone changed their mind. Here, you’ll read a diff like a researcher.
Addition, removal, rewriting, and renaming—each type carries a different intent. The first step in reading is to separate what changed from how it changed.
The amateur reader sees only the additions and confuses a rewrite with a rename. Knowing the four types separates recording a change from understanding one.
Addition (+) · removal (−) · rewrite (≈) · rename (~) · Opus 4.8 → Fable 5 case study.
The most underestimated rule: anyone who reads only what went in reads half the book. What came out was internalized through training (it became noise) or consolidated into a principle.
A prompt’s maturity is measured by the last time something was removed from it. A prompt that only grows is rotting from within.
Internalized = noise · consolidated = principle · search_first disappeared · removing it is editing too.
Reconstruct the problem the change probably solves — weapons became a principle, drugs gained a vital exception, the end of the conversation began to be respected.
The inferred motivation is your interpretation, not a statement from the lab. Inferring is legitimate as long as you don’t mistake a hypothesis for a stated fact.
What incident does this address? · likely motivation · epistemic honesty · the diff is a record of problems experienced.
The subtlest change doesn’t alter any words in the content: copyright_compliance → core_copyright_principle. The text stays; the label changes.
You’re always choosing how the model sees itself obeying—and that changes how it obeys. "Compliance" follows instructions; "principle" reasons through new cases.
Prohibition vs. principle · compliance vs. core_principle · rename based on intent · a value-based name generalizes.
Each specific change hides a lesson that applies beyond its context. The self-harm rewrite becomes “example + generative criterion > examples alone.”
If you only keep the case, nothing transfers. The lesson applies to your next prompt—like studying chess games for their principles.
Case × lesson · principle > list · evolve ≠ grow · inherit the method without inheriting the mind.
The complete protocol: for each change, classify the type, infer the likely motivation, and distill the lesson — then check the balance (+56 lines / −7 blocks).
The same lens of analysis is what you use to trim down your own prompt afterward. Reading diffs closes the loop with the consolidation in 3.2.
Classify · read the − · extract the lesson · the takeaway (structure > characters).
🗜️ Consolidation: slim down without losing behavior
In 3.1, you read about the evolution from the outside; now it's time to take action. The consolidation round takes a prompt that keeps growing and pares it down — merging little rules into principles — without losing a single behavioral guarantee. The golden rule: nothing is removed without a reason and a test.
Prompt entropy: every problem becomes a new rule, none are removed, and the document turns into a monster nobody dares touch.
An overgrown prompt dilutes the model’s attention and hides contradictions. Recognizing the symptom is the first step toward treating it.
Prompt entropy · one rule per incident · diluted attention · nobody dares delete anything.
A scheduled ritual: every N rules you add, stop and review everything at once—merge, remove, rewrite—instead of just piling on more.
Consolidating deliberately and periodically is what prevents decay. It’s maintenance, not emergency repair.
Periodic ritual · every N rules · refactor the prompt · maintenance, not panic.
The test applied to each rule: does the model already do this on its own? Can it be merged into a broader principle? What test would fail without it?
The three questions turn "intuitive cleanup" into a defensible decision. Each rule either proves its value or goes.
Can you do it on your own yet? · can it be merged? · which test fails without it? · justifiable decision.
The consolidation constraint: every rule carries the reason it exists and a test that would fail without it. Without both, it does not deserve to stay.
It’s what protects you from accidentally removing something important—and from keeping something useless out of fear. Evidence decides, not guesswork.
Documented rationale · test that would fail · evidence for each rule · proof > fear.
The canonical example: the Opus 4.8 → Fable 5 evolution gained content (+56 lines) but shrank in structure (−7 blocks). It grew and slimmed down at the same time.
It’s living proof that “evolving ≠ growing.” A mature team adds what was missing and removes what training has already absorbed, in the same diff.
+56 lines / −7 blocks · content goes up, structure goes down · balance > volume · visible maturity.
The counterpoint: consolidating before you’ve seen the real behavior is premature optimization. Without enough cases, you merge rules you don’t yet understand.
Pruning too early is as dangerous as bloat: you could generalize the wrong principle. Wait for the data before merging.
Premature optimization · wait for the data · wrong principle · there’s a right time for maturity.
🛡️ Safety by principle, not mechanics
The labs’ most delicate lesson: in safety, what you write to protect can also teach people to attack. The solution is to state the principle, never the detection mechanics—and give the model a refusal trigger it can recognize through its own reasoning.
The Fable 5 case: the child safety policy stays at the level of principles and patterns, without detailing the signals detection uses.
Detailing detection mechanics in a prompt gives a map for how to get around them. The right level is the principle, not the procedure.
Principle-level · don't detail the signals · the pattern is enough · the prompt is readable by an attacker.
The central security risk: the knowledge that protects is symmetrical to the knowledge that attacks. Explaining how to detect is explaining how to evade.
Recognizing the symmetry is what makes you think twice before writing the mechanics. Defense and attack share the same information.
Knowledge symmetry · educating = arming · think of the hostile reader · two-edged information.
The practical rule: write the high-level value (“protect X”) and let the model derive how to apply it — without listing how to recognize each attempt.
The principle covers cases the list didn’t anticipate and doesn’t prescribe a method. It’s more robust and safer at the same time.
Principle > mechanics · high level · derive the application · don’t hand over the method.
An introspective trigger: if you find yourself reframing… then refuse. The warning sign is the model itself catching itself working around the rule.
Instead of a list of prohibitions that can be circumvented, the trigger uses the model's reasoning as a sensor—it detects evasion and stops.
Introspective trigger · reframing as a signal · REFUSE · reasoning is the sensor.
The step after “no”: stay alert in later turns, because the request may come back in pieces or reframed to get around the refusal.
A single refusal doesn't close the risk if the model "forgets" on the next turn. The precaution has to survive the refusal itself.
Post-refusal attention · split-up request · reframing in sequence · the risk persists.
The form of the refusal: a conversational, human response—without dumping policy lists or lecturing, while preserving the dignity of the conversation.
A cold, bureaucratic refusal alienates legitimate users and helps no one. The right tone refuses the request without punishing the person.
Conversational · no bullet points · no lecture · firm and human.
🪜 Priority and layers
When two instructions conflict, which one wins? And what is that <system-reminder> that appears in the middle of the conversation? This module separates stable behavior (the prompt) from dynamic state (the layer injected by the harness) — and shows why this architecture scales over time.
The rule that establishes precedence among conflicting instructions — central policy above system, system above user, user above the default.
Without an explicit order, conflicting instructions leave behavior to chance. The hierarchy says in advance who wins.
Declared precedence · central policy at the top · resolve conflicts · nothing left to chance.
The chain broken down link by link, using the real example of copyright precedence: from security at the top down to default behavior.
Seeing the entire chain shows where each instruction in your prompt fits — and why a “weak” rule can’t override a “strong” one.
Link by link · copyright precedence chain · nonnegotiable safety · each level in its place.
O <system-reminder>: a context layer injected by the harness during execution — the current state, not a fixed prompt rule.
It’s how the system pushes dynamic information (long conversations, rule reminders) without rewriting the stable prompt. Understanding this explains a lot of behavior.
<system-reminder> · injected by the harness · current state · dynamic layer.
The crucial distinction: the reminder is injected by the harness, not the user — it’s context that guides you, not a user command that must be blindly obeyed.
Treating context as an instruction (or vice versa) breaks the hierarchy. The model needs to know the source so it can properly weigh what it reads.
Context ≠ instruction · origin matters · it’s not the user speaking · weigh it by its source.
The division of responsibilities: the prompt holds the behavior that always applies; the reminder carries the state that changes from turn to turn.
Mixing the two bloats the prompt with ephemeral details. Keeping each layer in its place keeps the prompt stable and lean and the state up to date.
Stable vs. dynamic · each layer in its place · doesn’t bloat the prompt · separation of responsibilities.
The rule that resolves the clash between what the user asks for now and what memory/auto-memory saved earlier: the user’s current request takes precedence.
Memory that overrides the user creates a stubborn agent stuck on old preferences. What the user says now must take precedence over what’s remembered.
User > memory · the present wins · no stubbornness · old preferences don't hold you back.
🧠 Distillation: recover the brain
The heart of the course. We lost Fable’s weights—but the logs remain. This module teaches you the method for recovering an agent’s “brain” from its own records: find the JSONL files, reduce the noise with a script, profile behavior with numbers, and synthesize a decision guide to point a new model toward.
The founding idea: you don’t have the model’s weights, but you do have the trace of what it did—and a good agent’s behavior is all there in those logs.
Reframes what it means to "recover" a model: it's not retraining it, but distilling the observable method from the trail it left behind.
No weights, with logs · observable behavior · distill ≠ train · the trace is enough.
The practical step: locate the files .jsonl from a session where every agent turn is recorded—input, reasoning, action, and result.
Without knowing where the record lives, there’s no raw material. Finding the JSONL files is how you open the black box of behavior.
Files .jsonl · recorded sessions · turn by turn · the raw material.
The key discipline: filter and summarize the logs with a Python script—never dump hundreds of raw turns into the model’s context window.
Putting raw logs in the context is expensive, slow, and blows past the limit. The script does the heavy lifting outside the model and delivers only the signal.
Script > context · process outside the model · signal, not noise · don’t overflow the window.
The selection: among all turns, isolate only those from the agent whose behavior you want to distill — separating the target brain from the rest of the system.
Mixing different agents muddles the patterns and dilutes the profile. Filtering for the target is what focuses the distillation.
Agent-specific scope · isolate the target · don’t mix brains · focus on the profile.
Quantify the profile from the 429 turns: 97% with reasoning, 84% reasoning before the 1st action, 87% reevaluating, 23% with a real test.
Numbers turn impressions into a picture. They reveal what the agent really prioritizes—thinking a lot before acting, reevaluating almost every time.
429 turns · 97% reasoning · 84% before acting · 87% re-evaluates · 23% real testing.
The final step: turn the numerical profile into a decision guide—the distilled decision loop—and point a new model’s session to that guide.
This is where the brain “comes back”: the observed method becomes a reusable instruction. You inherit the agent’s discipline without having its weights.
Profile → guide · the decision loop · point to the new model · the recovered brain.
⚙️ Willingness × hard guarantee
A behavior guide is just "best effort"—the model tries to follow it, but may fail. For what needs to be guaranteed, you don’t ask: you lock it down. This module separates willingness (soft) from hard guarantees—reasoning density via effortLevel, a deterministic habit via hook — and shows where each rule lives.
The nature of the guide: behavioral instructions nudge the model in a direction, but don’t force it. It’s a disposition, not a guarantee.
Trusting a prompt to always get something right is a gamble. Knowing the guide's limits tells you when to move to a hard safeguard.
Best effort · disposition ≠ guarantee · the prompt nudges · know the limits.
The right lever for “thinking more”: the effortLevel (xhigh/max), which controls reasoning density — not the old MAX_THINKING_TOKENS.
Asking the model to “think carefully” in the prompt is a request; raising effortLevel is a configuration change that actually affects how much the model reasons.
effortLevel xhigh/max · reasoning density · config, not prompt · ≠ token budget.
The hard constraint: a hook PostToolUse that runs the test automatically after each edit — the harness runs it, the model doesn’t “remember.”
What must always happen cannot depend on the model's disposition. The hook ensures the habit deterministically.
PostToolUse · the harness enforces · deterministic · guaranteed habit.
The decision about where it goes: the CLAUDE.md always loads (every session), while auto-memory is relevance-gated — it only comes in when the context calls for it.
Putting a critical rule only in auto-memory risks it not appearing when it matters. Where the rule lives determines whether it’s reliable.
CLAUDE.md always loads · auto-memory is relevance-gated · where > what · ensure presence.
The right scope for output styles: they shape how the agent sounds and what role it plays—but they don’t enforce process discipline (testing, reassessing, verifying).
Expecting agentic discipline from an output style means using the wrong tool. Tone is tone; operational behavior belongs somewhere else.
Tone and role · ≠ discipline · the right tool for the right purpose · style doesn't verify.
The takeaway: the disposition guide provides direction and good judgment; the hard constraints (hooks, effortLevel, where the rule lives) ensure what must not fail. Together, they form the system.
Prompts alone are fragile; constraints alone are rigid and blind. The combination produces an agent that is both flexible and reliable.
The guide steers + guardrails ensure · soft + hard · flexible and reliable · the complete system.
🏁 Final project: your versioned system prompt
Time to bring it all together. You build your own system prompt—MVP, persona, loop, and safety—version it with diffs, write down the why and the test for each rule, draft your own disposition guide, and pair it with hard constraints. The deliverable is yours: a versioned prompt + guide, ready to evolve as the labs do.
Putting together the final prompt from the course components: the Minimum Viable Prompt, the four-axis persona, the operational Loop, and the safety blocks.
It's the integration of everything you've practiced—without repeating the mistake of bloating it. Each piece is included because your case calls for it, not "just in case."
PMV + persona + loop + safety · integrate without bloating · only what the use case calls for · complete prompt.
Treat the prompt as a versioned artifact: save each version and compare them with a diff, closing the loop you learned to read in 3.1.
Versioning makes evolution visible and reversible. You start reading your own diff — and applying to yourself the method you used in the labs.
Prompt as code · save versions · your own diff · visible and reversible evolution.
Apply the golden rule from 3.2 to your prompt: every rule comes with why it exists and the test that would fail without it.
It’s what makes your prompt auditable and easy to prune in the future: you (or someone else) knows why each line is there and how to check whether it’s still useful.
Rationale for each rule · test that would fail · auditable prompt · can be pruned later.
Draft your behavior guide — your "Fable Mindset" — distilling the decision loop you want the agent to follow, in the spirit of 3.5.
The guide is the disposition that steers the agent in cases the rigid prompt doesn't cover. Writing it means capturing your method in reusable text.
Disposition guide · your Fable Mindset · written decision loop · reusable method.
Apply 3.6 to your project: pair the soft guide with hard safeguards — hooks for habits, effortLevel for reasoning, and a decision about where each rule belongs.
It’s what takes your prompt from “I hope it works” to “I guarantee what’s needed.” The combination closes the gap between intent and execution.
Hooks + effortLevel · where the rule lives · guide + guardrails · intent becomes execution.
The final self-check: a checklist that confirms the prompt, guide, tests, and safeguards are complete and consistent before declaring “ready.”
Close the course with the same rigor it teaches: nothing is "done" based on a feeling — it's done through verification, item by item.
Delivery checklist · ready by verification · prompt + guide + tests + safeguards · final consistency.