🔄 Is more context better? Not with Fable 5
🧠 Imagine it this way: Classic prompt engineering is written like a lawyer’s ironclad contract—every clause anticipating an exception: “always do X,” “never do Y,” “if Z happens, then W.” This protected against a model that forgot rules along the way. With a model that already follows plenty of instructions, the same contract becomes bureaucracy that no one reads to the end.
The convention you’ve probably already learned says: the more context, the more explicit rules, the better the result. That made sense while instruction following was inconsistent — enumerating each behavior was the only way to ensure the model didn't miss anything important.
With Claude Fable 5, this assumption changes. Instruction-following has become strong enough that a brief, well-chosen instruction can guide the right behavior without listing every rule one by one. Enumerating everything is no longer protection; it has become noise: each extra rule competes for attention with the ones that actually matter, bloats the prompt, and can even steer the style to match the response’s tone to the same wordiness as the prompt itself.
Caption: on the left, each enumerated rule competes for attention and dilutes the result; on the right, a single brief instruction comes through clearly—strong instruction-following doesn't need a list.
⚠️ Don’t confuse this with cutting information
"Say less, not more" isn’t about removing context that changes the outcome — it’s about removing redundant rules the model would follow on its own. Intent information remains just as important as ever (topic 5 explains why).
In one sentence: weaker models needed a list; Fable 5 needs clear direction—enumerating everything became noise, not protection.
🎯 Strong instruction following — the official prompt
🧠 Imagine it this way: it’s the difference between training a new intern (who needs a step-by-step manual) and giving direction to a senior (who already knows how to fill in the details). Fable 5 is already close to "senior"—treat it that way.
The official doc “Prompting Claude Fable 5” is direct about this: instruction following has improved enough that you can guide most behaviors with a brief instruction instead of listing every behavior by name. It’s a change in strategy, not just writing style.
Instruction-following is improved enough that you can steer most behaviors with a brief instruction rather than enumerating each behavior by name.
Instruction following has improved enough that you can guide most behaviors with a brief instruction instead of listing each behavior by name.
In practice: if your system prompt has a list of 15 bullets trying to cover every possible behavior (“always do X,” “never do Y,” “if Z, do W”...), Fable 5 probably already responds well to a sentence that captures the central intent. Try removing half the list before considering adding another rule.
✓ What to DO
- ✓Write 1-2 sentences that capture the intent and expected outcome.
- ✓Trusting that default behaviors (formatting, tone, care with obvious edge cases) are already built in.
- ✓Add a new rule only when the default behavior actually fails in a real test.
✗ What NOT to do
- ✗Copying and pasting the same list of 20 rules you used for older models.
- ✗Repeating the same instruction in different ways "just to be safe."
- ✗Treating every hypothetical exception as if it needs to become a permanent rule.
In one sentence: a brief, well-targeted instruction replaces the list—the model already follows plenty of instructions.
✂️ Lead with the outcome — readable ≠ concise
🧠 Imagine it this way: Think of a newspaper headline. It isn’t short because the words were cut in half—it’s short because someone carefully decided what really matters to tell first.
The official docs also give you the recipe for the final output: start with the result (“lead with the outcome”). The first sentence after you finish should answer “what happened” or “what did you find”—what the user would ask if they said, “just give me the summary.” Details and reasoning come afterward.
Goal: make the agent lead every long response with the result, and justify it only afterward — without compressing the output into unreadable fragments.
Lead with the outcome. Your first sentence after finishing should answer "what happened" or "what did you find": the thing the user would ask for if they said "just give me the TLDR." Supporting detail and reasoning come after. Being readable and being concise are different things, and readability matters more. The way to keep output short is to be selective about what you include (drop details that don't change what the reader would do next), not to compress the writing into fragments, abbreviations...
Start with the result. Your first sentence after finishing should answer "what happened" or "what did you find": what the user would ask for if they said "just give me the summary." Supporting details and reasoning come afterward. Being readable and being concise are different things, and readability matters more. To keep the output short, be selective about what you include (cut details that wouldn’t change what the reader does next), rather than compressing the text into fragments, abbreviations…
How to check: paste this at the end of your CLAUDE.md or system prompt and watch the next long response. The first sentence should already state the result—without “let me explain what I did first” before getting to it.
🔍 Key distinction: readable ≠ concise
- Readability — the reader understands it on the first pass, without having to decode it. That matters more.
- Brevity — fewer words. It only matters when it doesn't hurt readability.
- Keeping it short is about selectivity (what you leave out), not about compression (how you write down what stuck).
✓ Well-written concision
- ✓Cut the paragraph that doesn’t change the reader’s next action.
- ✓Write complete sentences, even if they’re short.
- ✓Spell out file names/numbers the first time they’re mentioned.
✗ Poorly done concision
- ✗Compresses it into fragments like "ok, done, next".
- ✗Abbreviates everything until it reads like a telegram.
- ✗Cutting the main result because you think “less is always better.”
In one sentence: being concise is about what you leave out, not how you write what remains.
🔀 Terse between tool calls vs. final summary (re-grounding)
🧠 Imagine it this way: a surgeon can use brief technical jargon during an operation with the team in the room. But the report he gives the family at the end needs to explain everything again from scratch in plain language—the people receiving it weren’t in the room.
During the work — between one tool call and the next — brief shorthand is great. It’s you “thinking out loud”; nobody is reading it in real time, and brevity there saves time and tokens without any real loss of clarity.
Caption: shorthand between tool calls is fine when you're thinking out loud; but the final message needs to reorient anyone who didn't see the process—result first, with every identifier explained as if it's new.
You start the task and step away
Overnight, or a long session where you aren’t reading every step the agent takes.
Between tool calls: terse shorthand
Good sign—it’s the agent thinking out loud, and brevity there costs nothing because no one is reading in real time.
Long session, lots of back and forth
Internal jargon accumulates: flag names, PR abbreviations, shortcuts that only make sense to people who followed everything.
Final message: mode switch
From “continuing the line of reasoning” to “re-grounding”—outcome first, with each identifier (file, commit, flag) explained as if the reader were hearing about it for the first time.
Goal: make the agent switch from "telegraphic mode" to "re-grounding mode" when wrapping up a long session without supervision.
Terse shorthand is fine between tool calls (that's you thinking out loud, and brevity there is good). Your final summary is different: it's for a reader who didn't see any of that. If you've been working for a while without the user watching (overnight, across many tool calls, since they last spoke), your final message is their first look at any of it. Write it as a re-grounding, not a continuation of your working thread: the outcome first, then the one or two things you need from them, each explained as if new. When you mention files, commits, flags, or other identifiers, give each one its own plain-language clause. Open with the outcome: one sentence on what happened or what you found. Then the supporting detail. If you have to choose between short and clear, choose clear.
It’s fine to be telegraphic between tool calls—that’s you thinking out loud, and brevity is good there. Your final summary is different: it’s for a reader who didn’t see any of that. If you worked for a while without the user watching (overnight, across several tool calls, since they last spoke), your final message is their first contact with all of it. Write it as a re-grounding, not as a continuation of your train of thought: the result first, then one or two things you need from them, each explained as if it were new. When mentioning files, commits, flags, or other identifiers, give each one its own sentence in plain language. Open with the result: one sentence about what happened or what you found. Then the supporting details. If you have to choose between brief and clear, choose clear.
How to check: paste this into your agent's instructions (system prompt/skill) and, in the next long, asynchronous session, reread the final message on your own: can you understand the result without seeing any tool calls? If so, it worked.
In one sentence: terse while no one is watching; re-grounding when someone finally reads it.
⚖️ This doesn’t contradict “give the why” (module 1.2)
🧠 Imagine it this way: a good design brief has one sentence of purpose (“this is meant to convince a skeptical investor”) and zero pages of pixel rules. Rich intent and a few enumerated rules have always worked well together—they just seemed like the same thing because old prompts often piled both together.
Module 1.2 (give the reason) asks you to explain the intent behind the request. This module (1.5) asks you not to enumerate every rule. At first glance, it seems contradictory — more on one side, less on the other — but these are two different axes, not the same scale.
⚖️ Two independent axes
Intent (the why) measures the quality of the context—what you want and why you want it. Verbosity (how many rules) measures volume — how many items you enumerate. You can have both: a dense statement of intent, with no list of rules.
- •Axis 1 (intent): "because this endpoint is used by 3 critical services"—1 sentence, high value.
- •Axis 2 (verbosity): "always do X, never do Y, in case Z do W..."—the more items, the more noise.
- •"Say less" targets axis 2 downward. "Give the why" targets axis 1 upward. They don’t compete for the same space.
Caption: "say less" affects the horizontal axis (fewer enumerated rules); "give the why" affects the vertical axis (more context about intent). These are independent axes—you can have both at once.
In practice, an “ideal” prompt for Fable 5 sits in the diagram above’s upper-left corner: 1-2 sentences expressing genuine intent, without the list of rules it would already follow on its own. If you’re unsure where to draw the line, review module 1.2 first—the right question isn’t “do I have too much context?” but “is this context intent or a redundant rule?”
Related→ Revisit module 1.2 — Give the why + don’t ask for reasoning
In one sentence: rich intent + a few enumerated rules isn’t a contradiction—it’s the ideal combination.
🛠️ In practice: refactoring CLAUDE.md and old skills
🧠 Imagine it this way: CLAUDE.md and skills written for older models are like instruction manuals translated from an old device—full of warnings that no longer apply to the new model, but are still there, taking up space and competing for attention.
The official docs give you a concrete target for applying all this: your CLAUDE.md, system prompts, and older skills written with earlier models in mind. If they spell out behavior step by step, they’re likely competing with Fable 5’s own judgment instead of helping it.
Official source · “Prompting Claude Fable 5” doc
"Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality. Review and consider removing older instructions if default performance is better."
PT-BR: "Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality. Review and consider removing older instructions if default performance is better."
This applies especially to skills and system prompts inherited from projects with older models: reread them critically and test whether removing half the rules changes the result. If it doesn't, those rules no longer made a difference—they only inflated the prompt and competed for attention with what actually matters.
Goal: asking Claude Code itself to audit its current CLAUDE.md/system prompt and flag what is probably redundant enumeration for Fable 5.
Releia o CLAUDE.md (ou system prompt) deste projeto <cole o conteúdo ou aponte o arquivo>. Aponte quais instruções são regras enumeradas que um modelo com strong instruction-following como o Fable 5 provavelmente já seguiria por padrão, e proponha uma versão mais curta que mantenha só o que muda o comportamento de fato. Não remova nada relacionado a intenção, contexto de negócio ou fronteiras de segurança — só o que é enumeração redundante.
How to check: run both versions (original vs. concise) on the same real task and compare the output. If the behavior hasn’t changed, the concise version is strictly better (fewer tokens, less noise). If something important is missing, context about intent was accidentally cut — put it back in the prompt.
⚠️ Attention
Don’t delete everything at once. Cut one block of rules at a time and run the same task before and after. Keep any rule that exists because of a real incident (security, sensitive data, fragile integration)—the target is the rule that existed only “just in case.”
📎 Going deeper (optional): signs that a skill is too prescriptive
- •A list with more than 10 "always/never" rules and no context explaining why.
- •Instructions redundant with the model's default common sense (obvious formatting, polite tone, don't make up facts).
- •Rules that try to prevent a hypothetical scenario that has never actually happened in the project.
- •Instructions like "show your reasoning" or "explain step by step before answering"—module 1.3 already showed that this can trigger the refusal category
reasoning_extractionin Fable 5.
In one sentence: reread CLAUDE.md and older skills through the Fable 5 lens — if a rule doesn't change the result, it's noise; cut it.
🧾 Module Summary
Next module:
1.6 — Effort and safety routing: effort levels (max/xhigh/high/medium/low) and the 4 refusal categories.