🏁 Final project: your versioned system prompt
It’s time to make the shift to student to author. The whole course has been preparing you for this moment: you’re going to bring together the PMV, the persona, loop, and safety in a single prompt — versioned, with the reason and test for each rule written alongside it. This is a project module: you don't read it, you produces. In the end, you leave with your own prompt and your own Fable Mindset.
The project, step by step
Put it all together: PMV + persona + loop + security
The project starts with a decision that separates beginners from mature authors: don’t start with 300 lines. Start with the PMV — the Minimum Viable Prompt — and only grow it when a bad behavior real appear. You’ll build four blocks that work together: identity, persona, loop, and security. It’s the entire skeleton of your personal agent in a single file.
🧩 The idea in one sentence
A good system prompt isn’t a pile of rules: it’s a small, coherent system. Four blocks are enough to support a personal agent — and each block comes straight from a technique you’ve already studied in this course. The rest is the discipline of not letting it bloat.
The starting rule: PMV (Method 1) + Persona in 4 dimensions (Method 3) + Loop (Part III). Run it. Only add a block when a real bad behavior shows up — and add it together with reason e test.
What it is
A synthesis of the entire course in a single prompt: a identity that anchors (who/where/when + objective), the persona across 4 axes (values, tone, interaction, escalation), the loop operational (ground → … → narrate) and the handful of rules of safety that really matter — each with its own reason.
Why do it this way
Because a prompt that starts out big starts out sick: nobody understands why each line is there, and the model gets lost among 400 bullets. The PMV forces you to justify each increase with an observed behavior, not an imagined fear. It’s the difference between a prompt that you keeps and one that you tolerates.
<identidade> Who/where/when + objective in 1 sentence. (Tech. 1)
<tone> Conciseness + 1 honesty rule. (Tech. 7)
<ferramentas> Only what exists, with a trigger. (Tech. 2/8)
<security> The handful of real NEVERs, with reasons. (Tech. 3/4/11)
<loop> Ground → … → Narrate, if it’s an agent. (Part III)
The 4 persona axes (values · tone · interaction · escalation) go inside <tone> or in a block <persona> own. Default values distilled from the collection: truth > deference, brevity > completeness, principle > mechanical rule.
Versioning: save versions and compare diffs
A prompt that you keep editing in place and never save is a prompt without memory. Versioning is what turns your file into an organism that evolves in a readable way: every version is saved, and between two versions you can read the diff — exactly what you learned to do with the Opus 4.8 → Fable 5 evolution, now applied to the your own prompt.
🗂️ Versioning isn’t a luxury; it’s good hygiene
Each time you touch the prompt, it becomes a named version — v1 → v2 → v3. O diff between them tells the story: what was added, what was removed, what was renamed. Without versioning, you can’t answer the most important question in a mature prompt: "when was the last time I removed something from here?"
The balance matters more than the raw count. +56 lines / −7 blocks tells a story of consolidation that the character count hides. Versioning is what lets you see that balance.
− <always_search> search before ANY factual answer
~ <tone_rules> → <persona> (same text, new label)
+ <persona> values: truth > deference (why + test)
+ <loop> after editing, run the test before saying "done"
net: +9 lines · −1 block · 1 rename
Notice the four types of changes you already know how to read: − removal (search became noise, the model already does it), ~ renaming (the label carries cognition), + addition (comes with a why). You’re the lab now.
✗ Unversioned prompt
- ✗Overwrites the file, losing what was there before
- ✗Doesn’t know why a rule was added
- ✗Only grows — never sees what it removed
- ✗Fear of making changes: every change is irreversible
✓ Versioned prompt
- ✓Each version saves: v1 → v2 → v3
- ✓The diff tells the story behind each decision
- ✓See the net result: structure, not just characters
- ✓Make changes without fear: you can always undo them
The “Diff of the Week” ritual
Adopt the ritual the labs themselves use: whenever a new model comes out, read its diff, name the pattern that explains the change, and update your library. Do the same with your prompt—every week you touch it, generate the diff and write, in one line, the lesson of that change. Your prompt becomes a decision log, not a heap.
Write the why and the test for each rule
This is the golden rule of the project, and it mirrors exactly what the labs do: every rule you keep needs a documented reason and a test that would fail without it. A rule without a why is faith; a rule without a test is decoration. If you can’t name the test that would fail without that line, the line doesn’t belong in the prompt.
🔎 The 3 questions for every rule
- ① Does the model already do this on its own? If yes → cut. What the training internalized becomes noise in the prompt (that was the case with <search_first> e <default_stance>).
- ② Can it be combined with another into a principle? If yes → deep. Three little rules that repeat the same value become one general sentence.
- ③ What test would fail without it? If none → cut. If any → keep it and write the test next to the rule.
Rule: refuse guides to drug use, but provide life-saving information.
Rationale: A total refusal in an overdose situation causes real harm (harm reduction).
A test that would fail without it: "how do you reverse an opioid overdose?" → blind refusal.
Without the line for test, you have no way to know whether the rule is still necessary three versions from now. With it, the consolidation round is trivial: the rule whose test still passes without it leave.
✗ Orphaned rule
- ✗IMPORTANT: always be concise!!!
- ✗Doesn’t say why, or what breaks without it
- ✗Turns into diffuse emphasis: everything is “important”
- ✗No one dares remove it — fear keeps it alive
✓ Rule with a reason + test
- ✓States the value it protects, not just the prohibition
- ✓Has a named test that would fail without it
- ✓It’s auditable: consolidation knows whether it comes out
- ✓Principle > list: covers the unforeseen case
Safety by principle, never by mechanics
In the safety block, state the principle, never the mechanics. "I don’t provide real uplift to anyone who wants to cause harm" covers infinitely many cases; a list of prohibited categories invites workarounds ("it’s not a chemical, so it’s allowed"). The why generalizes; the list stops at the boundary of what someone remembered to list.
Build your disposition guide (your Fable Mindset)
The prompt says what the agent is. The disposition guide says how it behaves from turn to turn. It’s the layer that Fable Mindset takes up: a short document you point the session to and that it adopts as its way of working. Now you write the your — distilled from what you want to see happen, not copied.
🧭 The decision loop, the heart of the guide
The backbone of any disposition guide is a explicit decision loop. The most important internal cycle is ACT → OBSERVE → RE-EVALUATE: skipping OBSERVE is how good plans produce wrong results.
GROUND establish the actual state (git, grep, read, run-state)
REASON state the objective + hypothesis + plan before acting
ACT take the next deliberate step, parallelize independent work
OBSERVE really read what came back
RE-EVALUATE update the plan based on the result, not the other way around
VERIFY run the actual check on what you changed
NARRATE report what happened faithfully
Define the ethos in one sentence
The whole guide should fit into a disposition you can state in one breath. E.g.: "cautious, then decisive—ground yourself in reality, form a hypothesis, act in batches, read what comes back, verify what changed." Scale the effort to the task: a one-line fix doesn't need a war room.
List the default values you want
Distill your own, don’t copy mine. The distilled values from the collection are a good starting point: truth > deference, brevity > completeness by default, principle > mechanical rule. Operational honesty > flattery.
Put the guide where it’s read every session
Disposition works well in a CLAUDE.md, which loads in every session. No works well in auto-memory — whose recall is relevance-gated and may not surface the rule at the right turn. Output styles are for tone/role, not agent discipline.
Distill, don’t memorize
O Fable Mindset wasn’t invented — it was distilled from hundreds of real observed turns. Your guide should come from the same place: from what you saw what works and what fails in your own sessions. You inherit the method without needing to inherit the mind.
Pair it with the guardrails (hooks + effortLevel + where the rule lives)
Here’s the most honest lesson in the whole course: a disposition guide is best-effort by nature. Prose influences, but it doesn’t enforce. That’s why you pair your prompt and your guide with mechanical constraints — what the harness actually enforces, whether the agent remembers it or not. Disposition is the soft layer; locks are the hard guarantees. Alone, none is enough.
🪝 Hook PostToolUse
"After editing, run the tests" is better guaranteed by a hook matched to Edit|Write|MultiEdit by intention. It triggers whether or not the agent remembers. hooksEnabled: true.
⚙️ effortLevel
Reasoning density is partly intrinsic to the model—pair the guide with the actual lever: effortLevel: max (or /effort max) + alwaysThinkingEnabled.
📍 Where the rule lives
Disposition in CLAUDE.md (loads every session). Deterministic habit in a hook. Absolute paths instead of cd remain as a declared rule — a hook doesn’t reliably rewrite them.
🚫 What no works
The old MAX_THINKING_TOKENS does nothing in adaptive thinking models. Auto-memory doesn’t guarantee the rule will apply in the right turn. Output style isn’t a vehicle for discipline.
🌉 The most important bridge: disposition → mechanical lever
The number that proves this is staggering: the source model runs a real check after editing in just 23% of the turns. Verify-after-edit is weak in the source e in the baseline — that's exactly where you should be better than the model it imitates, not the same.
You don’t close this gap with prose ("remember to test!"). You close it with a PostToolUse hook that runs the test by itself. The layout inspires; the lock ensures.
Each layer in its place
It’s the same principle Anthropic used when assigning the long-conversation problem to a dynamic reminder instead of bloating the stable prompt: each layer in its place. Stable behavior → prompt. Disposition → guide. Hard guarantee → hook + effort. Dynamic context → reminder. Don't mix the layers.
Delivery checklist: the self-check before saying “ready”
The final step, and the most important of all: what “done” means. A deliverable isn’t ready because it "looks right." It’s ready when it passes an honest self-check. This checklist — straight from the self-check before yielding the turn from the Fable Mindset — it’s the gate you pass through before declaring the project complete.
🎯 What “ready” means
A deliverable is ready when the objective has been met, the change has been verified with a real check, and the result was reported honestly — including what failed or was skipped. "it probably works" isn’t ready. "the tests pass, and here's the output" is ready.
✓ Did I reason before acting, and reevaluate after each result?
✓ Did I ground myself in the actual state before changing anything?
✓ Did I read what I edited right before editing it?
✓ Did I run the real check on what I changed?
✓ If something failed, did I diagnose it instead of blindly repeating it?
✓ Did I narrate the decisions and report the result honestly?
✓ Was my effort proportional to the task?
📦 Checklist for your final deliverable
- ✓The prompt came from a PMV — 4 blocks — and did it only grow based on real behavior observed?
- ✓It’s versioned (v1 → v2 → v3), and can you generate the diff between two versions?
- ✓Each retained rule has reason + a test that would fail without it?
- ✓The security is declared by principle, not mechanics/a list?
- ✓There is a disposition guide with an explicit decision loop, in a CLAUDE.md?
- ✓The constraints are linked: post-edit hook + effortLevel + the rule in the right place?
Always report faithfully
If a test failed, say so and show the output. If you skipped a step, say you skipped it. If it’s done and verified, say so without hesitation. Never dress up an unverified result as if it were ready. Trust is built through precise reporting, not optimistic reporting — and that applies to your prompt, your guide, and every turn you run from here on.
📝 Module Summary
- ✓Put it all together in an MVP: identity + persona (4 axes) + loop + safety — and only grow based on real behavior
- ✓Version your: keep v1 → v2 → v3 and read the diff of your own prompt—you’re the lab now
- ✓Write the reason + the test from each rule; without a test that would fail, the rule is removed
- ✓Build the your disposition guide — decision loop + default values, in a CLAUDE.md
- ✓Pair it with the constraints: PostToolUse hook + effortLevel + where the rule lives — neither is enough on its own
- ✓Go through the self-check before saying "done": verified with a real check, reported honestly
🎉 You completed The Hidden Manual of AI
Three tracks, twenty-some modules, and a whole journey: you went from read the anatomy of a system prompt, went through read the evolution between versions, and gets here author of your own version-controlled prompt — with layout guidance, mechanical safeguards, and a delivery checklist. You didn’t memorize rules; you inherited a method.
The meta-lesson running through everything: the labs converged, between 2024 and 2026, from rules to principles, from prohibition to value, from diffuse emphasis to sparse emphasis, from a growing prompt to a prompt that consolidates. Now it's your turn to write this way. Keep up the “Diff of the Week” ritual, and your prompt will never rot from the inside.