In July 2026 Anthropic published a piece with a genuinely surprising claim: it had removed more than 80% of Claude Code's system prompt for the Claude 5 generation — Claude Opus 5 and Claude Fable 5 — with no measurable loss on its coding evaluations. The instructions were not replaced with better instructions. They were deleted. The reason reframes how you should build with these models. Most of what fills a system prompt, a CLAUDE.md, or a long tool description is not knowledge the model lacks — it is guardrails written to stop failure modes of older, weaker models. Claude 5 no longer produces most of those failures, so the guardrails now do more harm than good: they conflict with each other, they are wrong in edge cases the author never imagined, and they crowd out the model's own judgment. Anthropic calls the fix "unhobbling" — you get better results by removing constraints, not adding them. This guide is the practitioner read on what that means. It defines context engineering and separates it cleanly from prompt engineering, walks through the six concrete shifts Anthropic named — rules to judgment, examples to better tools, everything-upfront to progressive disclosure, repeated instructions to simple tool descriptions, manual memory to auto-memory, and simple specs to rich references — and then gets practical about what to actually delete from your own prompts and context files, what to keep, and where the discipline still matters more than ever. It closes on the honest limit: a bigger context window and a smarter model raise the value of curating context well, they do not remove the need to do it.
In July 2026 Anthropic published a post about building with its Claude 5 generation of models, and buried in it was a claim that should reset how a lot of people write prompts: the company had removed more than 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5, and measured no loss on its coding evaluations. Not rewritten it. Not compressed it. Deleted it. The instructions that had been carefully accumulated over prior model generations turned out to be, for the most part, dead weight the moment the model got good enough.
That single result carries the whole thesis of context engineering for Claude 5, so it is worth stating plainly before the detail. Most of what fills a system prompt, a CLAUDE.md file, or a bloated tool description is not information the model is missing. It is a guardrail — a rule written at some point to stop a specific failure an earlier, weaker model kept making. Claude 5 does not make most of those failures anymore. So the guardrail stops being protection and becomes friction: it contradicts another rule three paragraphs down, it is wrong in an edge case the author never thought about, and it spends the model's attention telling it not to do something it was never going to do. Anthropic's name for fixing this is "unhobbling" — you improve output by removing constraints, not by adding better ones. This guide is about how to think, and what to actually change, once that is the reality you are building against.
Context engineering is the practice of curating the entire set of tokens a model sees at inference time, and keeping that set optimal as the task runs. That is broader than the prompt. It includes the system prompt and the user message, yes, but also the tool definitions you expose, the files and references you pull in, the data a retrieval step injects, and the memory the system carries between turns. The question it asks is not "how do I phrase this?" but "what configuration of context is most likely to produce the behavior I want?" Anthropic frames it as the natural progression of prompt engineering: after a few years of the field obsessing over wording, the harder and more valuable problem turned out to be assembling and pruning the whole context, of which the prompt is one part.
The distinction matters because it changes what you optimize. Prompt engineering is a writing task — find the right words, order the instructions well, phrase the ask so the model complies. Context engineering is a systems task — decide what belongs in the window this turn, what should load only when needed, what should be a tool the model calls rather than text it reads, and what to leave out entirely. Prompt engineering still lives inside it; you still write clean instructions and clear tool descriptions. But for anything past a single-turn chatbot, the prompt is one input into a pipeline, and the pipeline is what you are really engineering. Claude 5 pushed this to the front because it made the "leave it out" answer correct far more often than the "add a rule" answer, which is exactly what the 80% deletion demonstrates.
The reason the deletion did not hurt is the whole story, so it is worth being precise about it. Anthropic said it had been overconstraining Claude Code — through the system prompt, through CLAUDE.md files, and through skills. The constraints were not random; each one had been added to prevent some real behavior. But they were prevention aimed at older models. A rule like "never write multi-paragraph docstrings" existed because a prior model would over-explain; a more capable model already writes to match the surrounding code without being told. Once the model clears the bar the rule was defending, the rule has three failure modes and zero benefits. It conflicts with other rules the model now has to reconcile. It is wrong wherever the real situation is the exception the author did not foresee. And it consumes context and attention that would otherwise go to the task.
So the fix was not "write the rules better." It was "remove the rules that are defending against failures the model no longer produces." That is unhobbling: the model was capable the whole time, and the accumulated instructions were holding it below its own ceiling. The practical implication for you is uncomfortable and freeing at once — a meaningful fraction of the prompt engineering you have done for older models is now actively making Claude 5 worse, and the highest-leverage edit you can make is to take things out and check whether anything actually breaks. Usually it does not.
Anthropic laid the change out as a set of before-and-after moves. Each one is a case of trading accumulated instruction for something lighter, and together they are the operating manual for context engineering on Claude 5.
The old instinct was to enumerate rules for every situation. The new one is to give the model the product context and a principle, then trust its judgment on the specifics. The docstring example is the archetype: instead of "never write multi-paragraph docstrings," you write "match the comment density of the surrounding code." The second version is shorter, is right in more situations, and does not fight the model when the surrounding code genuinely warrants a longer comment. Principle-based guidance scales; rule enumeration does not.
When a model kept misusing a tool, the reflex was to paste in examples of correct usage. The better fix on Claude 5 is to design the tool so it is hard to misuse — expressive parameter names, enumerations and constraints that encode the valid options, an interface that hints at proper use by its shape. A well-designed tool signature teaches correct usage more reliably than a paragraph of examples, and it does it without consuming context on every call.
The old pattern loaded all possible guidance into the prompt in case it was needed. The new pattern discloses progressively: essential context upfront, everything else available but deferred until the moment it is relevant. This is the single most important structural shift, and it gets its own section below.
Repeating an instruction in several places was a way to make sure the model did not miss it. With a model that reliably reads its context, repetition is just noise that dilutes signal and creates opportunities for the copies to drift out of sync. A single clear statement, in the right place — often the tool description rather than the system prompt — does the job.
Hand-maintaining a CLAUDE.md as a memory store, writing down everything the model might need to remember, gives way to relying on the model's own memory mechanisms to persist what matters. You stop treating the instructions file as a database the model reads top to bottom every turn, and start treating it as a lightweight orientation.
Instead of describing what you want in prose, point the model at the real thing. A code reference beats a description of the code. An HTML mockup outperforms a written description of a design. You can hand a model an entire codebase as reference material and let it find what it needs, rather than trying to summarize the relevant parts in advance. Rich references are higher-fidelity and lower-effort than the specs that tried to stand in for them.
The organizing idea behind all six shifts is that context is a budget, and the goal is to keep the working set small and high-signal. Progressive disclosure is how you do that in practice. Think of it as three tiers. The first is the essential context that goes in the system prompt: what the product is, what the model is doing, the handful of things that are true on every single turn. Keep this genuinely small. The second tier is medium-priority guidance that lives in a lightweight CLAUDE.md or in a skill — the repo's purpose in a sentence or two, and the gotchas specific to it that the model could not infer. The third tier is detailed information that loads only when it is needed: long skills split across multiple files so only the relevant file loads, deferred-load tools whose full definitions arrive when the model actually reaches for them, references pulled in on demand.
The CLAUDE.md advice deserves its own line because it is where most teams over-invest. Keep it brief about what the repo is, and spend the tokens on the non-obvious — the gotchas, the traps, the decisions that would surprise someone reading the code cold. Do not state the obvious, do not restate what the model can read from the code itself, and do not turn it into a rulebook. When an instruction is complex, reference a skill instead of inlining the whole thing. The same logic governs skills: treat them as lightweight guides for discovering information, encode your team's and product's actual opinions, and split anything long so the model loads only the part in front of it. The point throughout is that a smaller, sharper context beats a larger, complete one, because the model reasons over what it is attending to, and attention is the scarce resource, not window size.
The shift from specs to references is worth pulling out because it inverts a habit almost everyone has. The instinct is to describe: to write, in careful prose, what the code does or what the design should look like, so the model has a clean summary to work from. On Claude 5 that is usually the wrong move. A description is a lossy compression of the real artifact, and you are spending effort to make it worse. Point at the artifact instead. Use an @-mention to bring the actual file in as a reference. Give the model the HTML mockup rather than a paragraph about the layout. Include the real codebase and let the model navigate it. Pair references with rubrics and dynamic workflows when you need the model to verify its own output against a standard. The model is capable of reading the source of truth; your job is to make the source of truth reachable, not to paraphrase it.
The practical version of all this is an editing pass on the prompts and context files you already have. Start with the assumption that a large fraction of it is guardrail text for problems Claude 5 no longer has, and go looking for it. Rules that begin with "never" or "always" and defend against a sloppy behavior are the first candidates — try replacing each with a one-line principle, or deleting it, and see whether output degrades. Usage examples for tools are the second: ask whether the tool's parameters could carry that information instead. Repeated instructions are the third — keep one copy, in the most relevant place, and remove the rest. Anything in a CLAUDE.md that restates what the code already says, or explains something obvious, is dead weight. Long inline specifications are the fourth candidate; swap them for a reference to the real thing.
The discipline is empirical, not theoretical. Delete, run your evaluation, and check. Anthropic did not decide the 80% was safe to cut on principle — it measured no loss on its coding evals and then cut it. You should do the same at your scale: keep a small set of tasks you can re-run, remove context aggressively, and let the results tell you what was load-bearing and what was cargo. The failure mode to avoid is the opposite instinct — reacting to a single bad output by adding another rule, which is how the 80% accumulated in the first place. On a capable model, "add a constraint" is the move that quietly hobbles you over time.
Anthropic shipped a diagnostic to make the editing pass less manual: a /doctor command in Claude Code that helps rightsize your skills and CLAUDE.md files, flagging where you have over-specified. It is a small feature with a telling implication — the vendor is now building tools whose explicit job is to help you remove context, which is about as strong a signal as you can get that subtraction is the direction of travel. If you work in Claude Code, run it against your existing setup and treat its findings as the start of the delete pass, not the end of it.
It would be easy to read all of this as "the models got good, so context engineering matters less." That is exactly backwards, and the mistake is worth naming because a lot of people will make it. The larger context window is the trap here — Claude Opus 5 offers up to a million tokens, and the temptation is to conclude that curation is obsolete because you can now fit everything. But window size is capacity, not attention. A model still reasons best over a focused, relevant, high-signal set of tokens, and filling the window with everything you have degrades output through the same dilution that made the 80% of system prompt worth deleting. More capable models and bigger windows raise the payoff of getting the context right; they do not let you stop.
What actually changed is the direction of the optimization. On weaker models, context engineering often meant adding — more examples, more rules, more scaffolding to hold the model on track. On Claude 5, it more often means removing — fewer rules, lighter files, deferred loading, references instead of descriptions. The skill is the same skill: deciding what the model should be attending to right now. The answer just shifted toward "less." That is a harder discipline than it sounds, because adding feels productive and deleting feels risky, and the only way through is to measure rather than guess.
There is a version of context engineering that most creators will never touch a system prompt to do, and it is the one that matters most for content: curating the context that governs voice and brand so a model produces on-brand output every time, without you re-prompting from scratch on every post. That is precisely the layer Kompozy productionizes. It is a content generation and multi-platform publishing engine — not a repurposing add-on and not a thin wrapper over a chat box — and the thing it is quietly doing under the hood is context engineering, applied to content, done once and reused across everything it makes.
The mechanism maps cleanly onto the principles above. The Persona Brief is the curated context that governs the model's output — voice, angle, phrasing, the things a rule list would try and fail to capture — expressed as judgment-shaped guidance rather than a brittle stack of "never say this" rules, which is the first shift in this guide made concrete. Your brand assets, reference images, and HyperFrames templates are the references — the real artifacts the engine renders against instead of a prose description of your brand, which is the specs-to-references shift. The banned-word filters and the four quality gates are the guardrails, but they sit at the output boundary as verification, not smeared through the prompt as constraints that fight the model. And because that context is assembled once and held in the Persona Brief, the same curated context drives all eighteen output formats — Persona Shorts, carousels, image posts, blogs, newsletters, and the rest of the output buckets — rather than you hand-building a prompt per piece.
That is the payoff that makes it more than a convenience. The whole point of context engineering is to stop treating each generation as a fresh phrasing problem and start treating the context as a system you configure well and reuse. Kompozy is that idea shipped: you engineer the voice-and-brand context one time, and Autopilot runs it as a governed agentic loop — pulling a source, generating against the curated context, clearing each output through the quality gates, and publishing across eight social platforms plus blog and email — so the on-brand configuration you got right once is applied on every post, on every platform, without the re-prompting that context engineering exists to eliminate. The honest scope: Kompozy is not where you tune a Claude Code system prompt or delete guardrails from your own agent — this guide is for that. It is where the same discipline pays off for anyone whose actual job is producing on-brand content at volume, which is most people who will never open a prompt file at all. For the concept itself, see context engineering in the glossary; for the model generation behind it, Claude Opus 5 and Claude Sonnet 5.
The headline finding — 80% of a system prompt deleted with no measured loss — is not a quirk of one product. It is the clearest evidence yet that context engineering for Claude 5 is a subtraction discipline. Most of what accumulates in a prompt is guardrail text for failures a capable model no longer produces, and on Claude 5 that text does not protect you, it hobbles you. The new rules follow from that: give the model judgment instead of rules, design tools instead of writing examples, disclose context progressively instead of loading it all upfront, say things once, lean on auto-memory, and hand over rich references instead of prose specs. The one thing that has not changed, and the thing people will get wrong, is that a smarter model and a bigger window make curating context more valuable, not less — you just curate toward less. Whether you are editing a system prompt or configuring a content engine, the skill is the same: decide what the model should attend to right now, and have the discipline to leave the rest out.
Context engineering is the practice of curating the entire set of tokens a model sees at inference — the system prompt, files and references, tool definitions, retrieved data, and memory — rather than perfecting a single prompt string. For Claude 5, the emphasis shifted hard toward removing content: because Claude Opus 5 and Claude Fable 5 are more capable, much of the guardrail text that helped older models now hurts. Anthropic reported deleting over 80% of Claude Code's system prompt for the Claude 5 generation with no measurable loss on its coding evaluations, which is the clearest signal that the discipline is now about subtraction and judgment, not accumulation.
Because most of it was overconstraining the model. Anthropic said it had been over-specifying Claude Code through the system prompt, CLAUDE.md files, and skills — and that many of those constraints were guardrails written for older models' failure modes. Claude 5 no longer produces most of those failures, so the guardrails created friction instead: conflicting instructions, rules that were wrong in edge cases, and context that crowded out the model's own judgment. Removing them — what Anthropic calls "unhobbling" — improved results without adding anything back.
Prompt engineering asks "how should I phrase this instruction?" Context engineering asks "what is the right configuration of context — instructions, tools, references, memory, retrieved data — most likely to produce the behavior I want?" Anthropic frames context engineering as the natural progression of prompt engineering: prompt engineering is still one part of it (you still write good instructions and tool descriptions), but in any system more complex than a single-turn chatbot, the prompt is just one input into a much larger context pipeline that you have to curate as a whole.
Progressive disclosure means loading context in tiers instead of dumping everything upfront. You keep only essential product context in the system prompt, put medium-priority repo guidance in a lightweight CLAUDE.md or a skill, and defer detailed information so it loads only when the model actually needs it — for example, splitting a long skill across multiple files, or using deferred-load tools whose full definitions arrive only when relevant. The goal is to keep the working context small and high-signal, so the model spends its attention on the task rather than wading through instructions that do not apply this turn.
No, and this is the most common wrong conclusion. Claude Opus 5 offers a context window of up to a million tokens, but capacity is not the same as attention — a model still reasons best over a focused, relevant, high-signal context, and stuffing the window with everything you have degrades results rather than improving them. The larger window and the more capable model raise the payoff of curating context well; they do not remove the need to. The Claude 5 lesson is that the winning move is usually to remove context, not to add it because you now can.
Context engineering for Claude 5 means curating the entire set of tokens the model sees — system prompt, references, tools, and memory — rather than perfecting one prompt. Because Claude Opus 5 and Fable 5 are far more capable, Anthropic deleted over 80% of Claude Code's system prompt with no measured loss on coding evals. The new rules: trust the model's judgment over rigid rules, use progressive disclosure instead of loading everything upfront, design better tools instead of giving examples, and provide rich references instead of long specs.
Get started → · ← All guides · Compare Kompozy vs other tools