Context Engineering: Claude Code's Prompt Cut 80%+

Context engineering vs prompt engineering in Claude Code

Context engineering shapes everything that reaches Claude with each request, while prompt engineering is about the message you type. Thariq Shihipar, a member of technical staff at Anthropic, laid out this view in a post dated July 24, 2026. The post reports a single result: how much of the system prompt Anthropic was able to delete for Claude models such as Claude Opus 5 and Claude Fable 5.

What counts as context: what you type is only a small part

What you type is only a small share of what Claude receives when you send a message. Most of the rest comes from other sources, and the post names several:

• the system prompt, the product's own instructions that tell Claude what product it is running in and what it is doing
• skills, guides that Claude can call on when a task needs them
• CLAUDE.md files, which Claude once relied on for memory, information and guidance
• memory, along with other sources

Anthropic calls the work of putting all this together context engineering. According to the post, it has a big effect on what you get from Claude Code and from agents you build yourself.

Unlike a prompt, context is reused across many requests, so it cannot be written for one particular task. The post describes the open problem as writing general guidance for Claude without knowing what a user will ask. Anthropic adds that this can be surprisingly hard while Claude's abilities keep changing, and that it recently saw a big shift in how it prompts its newest models.

Claude Code's system prompt lost over 80% for Opus 5 and Fable 5

For models such as Claude Opus 5 and Claude Fable 5, Anthropic says it deleted more than 80% of the Claude Code system prompt with no measurable loss on its coding evaluations. That is the post's only number, with no evaluations named, no scores given and no prompt length stated before or after the cut.

Anthropic found it had been overconstraining Claude Code, placing too many limits on it through the system prompt, CLAUDE.md files and skills. Reading transcripts of its own internal Claude Code use, the team found single requests carrying instructions that pulled in opposite directions. One said "leave documentation as appropriate" while another said "DO NOT add comments", because the system prompt, skills and the user's request clashed.

Claude can usually tell what the user means, but overlapping or conflicting messages make it think harder before acting. The post says these limits were once needed to prevent worst-case outcomes. Anthropic has since found it can delete many of them and let Claude rely on the surrounding context and its own judgment.

Claude Code also has far more tools today. Claude once depended on CLAUDE.md for memory, information and guidance, and now it can load and share context across sessions through memory, artifacts and skills.

Six old context engineering practices Anthropic calls myths

Then and now: the six pairs the post lists

Then	Now
Give Claude rules	Let Claude use judgement
Give Claude examples	Design interfaces
Put it all upfront	Use progressive disclosure
Repeat yourself	Simple tool descriptions
Memory in CLAUDE.md files	Auto-memory
Simple specs	Rich references

According to the post, several earlier context engineering best practices have become myths, and it lists six as Then and Now pairs. It introduces them with the word "including", so the list is not meant to be complete. Each pair below gives the old habit, what replaced it and, where the post says, why.

Rules to judgment: a style standard replaced the no-comments rule

Anthropic replaced a set of strict comment rules with one sentence asking Claude to match the code around it. When Claude Code first launched, the team had to make sure Claude avoided worst-case outcomes such as deleting files.

So the team wrote firm guidance that might not always be right. The old system prompt told Claude to write no comments by default, to keep any comment to one short line, and to skip planning or analysis documents unless asked.

For some prompts that guidance was wrong. A user might have their own views on documentation, and parts of very complex code can need comment blocks several lines long.

With older models Anthropic accepted that tradeoff, since without the guardrails Claude's comments would often be wrong. Newer models handle these cases well without explicit rules, so the new system prompt asks Claude to match the comment density, naming and idiom of the surrounding code.

Anthropic's prompting best practices page makes a related point about forceful wording: Claude Opus 4.5 and Claude Opus 4.6 respond more strongly to the system prompt than earlier models, so prompts written to stop tools or skills being under-used may now make them fire too often. Its fix is to soften the wording, and its example changes "CRITICAL: You MUST use this tool when..." to the plainer "Use this tool when...".

Examples to interface design: the Todo tool's status enum

For the newest models, the post advises designing the tool's interface instead of writing examples of how to use it. Giving Claude examples used to be the first rule of tool use.

On its newest models, Anthropic found, examples narrow the range of approaches Claude tries. The post suggests looking instead at the parameters Claude gets from your tools, scripts and files and at how those parameters could say more.

The Todo tool is the example. Its status field is an enum, a fixed list of allowed values: pending, in_progress and completed. That list alone hints at how to use the tool, and one instruction about keeping a single item in_progress defines the behavior Anthropic wants.

Anthropic's prompting best practices page still recommends 3 to 5 examples for steering the format, tone and structure of Claude's output. That is a separate job from the tool-use examples the post is about.

Upfront to progressive disclosure: load context when needed

Progressive disclosure means loading the right context at the moment it is needed instead of putting everything in the system prompt at the start. Since Claude Code was built for coding, its system prompt once held detailed steps for code review and verification.

Those steps were not needed for every task, but they mattered a lot when they were. Claude Code has since become good at progressive disclosure. For example, Anthropic moved verification and code review into separate skills that Claude Code calls only when it needs them.

Tools now work the same way. Some Claude Code tools use deferred loading, so their full definitions are not loaded up front.

Before using such a tool, Claude has to look up its full definition with ToolSearch, a search tool. That lets Claude Code offer more tools, such as its Task tools, without spending context on them until they are needed.

The post applies this to your own CLAUDE.md and Skill.md files too. It calls it a common myth that these files should collect every practice you might need, on the theory that Claude would miss anything left out, and suggests a tree of files that can each be loaded at the right time.

Repeated instructions gave way to simple tool descriptions

Anthropic removed the repeated tool instructions from Claude Code's system prompt and kept them only in each tool's description. Earlier Claude models sometimes needed an instruction more than once, and they could follow what came at the end of their context window, the span of text a model reads at once, more readily than what came at the start.

So Claude Code's system prompt sometimes mentioned tools in its main text while each tool's description gave instructions as well. Anthropic found it could delete those repeats, and instructions for using a tool now live in its description, not in the system prompt.

Claude Code auto-memory replaces hand-saved memory

Claude now saves memories about you and your work by itself, whereas Anthropic once asked users to save them to CLAUDE.md with the # hotkey. That hotkey wrote the item directly into the user's CLAUDE.md file.

Claude Code plan mode to rich references: artifacts, code, rubrics

Claude can now work from rich references such as HTML artifacts, code and rubrics instead of simple markdown specs. In plan mode, Claude Code leaned heavily on markdown files holding the plan, which Claude could look back at. A related habit was keeping specs in the codebase for Claude to consult on longer projects.

According to Anthropic, Claude can now handle more references, and more complex ones. It can point to HTML artifacts made with Anthropic's new artifacts feature. A spec can also be code, such as a thorough test suite or a function from another codebase that Claude may port.

A rubric is another kind of reference. With a rubric, Claude can try to check work against your taste in a field, such as what good API design looks like. It does this by running dynamic workflows and starting verifier agents that apply the rubric.

Context engineering for your own setup: what each layer needs

What the post says for each part of your context

Component	What the post says
System prompt	Tied to the product; Claude Code users will likely never change it, but agent builders should spend a lot of time on it
CLAUDE.md	Keep it light, say briefly what the repo is for and spend most of it on gotchas
Skills	Write them as lightweight guides and split long ones into many files
References	Add files with @-mentions and prefer code, such as an HTML mockup over a description or a screenshot

The post then carries these lessons over to four parts of your context: the system prompt, CLAUDE.md, skills and references. Claude Code users control the last three themselves.

System prompt: where agent builders should spend their time

People building their own agents should put a lot of time into the system prompt, while Claude Code users will probably never touch it. It is closely tied to the product, since it tells Claude which product it is running in and what it is doing.

In Claude Code, Anthropic writes that prompt, and it is the text the company cut by more than 80%. Anyone building an agent harness, the software that runs a model with its prompt and tools, writes this layer themselves.

CLAUDE.md best practices: a short repo summary plus gotchas

The post recommends a lightweight CLAUDE.md that briefly says what the repo is for and spends most of its tokens on the gotchas in your codebase. Tokens are the units a model counts text in, so the advice is about where the file's length goes.

Its example of a gotcha is keeping every type in one monolithic file and nowhere else. It also says to leave out "the obvious", meaning things Claude can learn by looking at your file system or repo.

The post wants heavy use of progressive disclosure here too. If you have several of your own instructions on checking work, it suggests a verification skill that CLAUDE.md points to. Claude Code Token Usage: 33K vs OpenCode's 7K covers how much Claude Code loads before your first prompt.

Claude Code skills: lightweight guides, long ones split into files

Treat skills as lightweight guides that help Claude find information when it needs it, not as strict rule sets, the post says. It warns against overconstraining them, except in areas that are highly important.

A long skill should rely on progressive disclosure as much as it can, which here means splitting it into many files. Skills work best, the post says, when they record opinions, knowledge or best practices that belong to you, your team or your product.

References: prefer code files over prose and screenshots

For references, the post prefers files written in code, since code gives Claude clear, high-fidelity instructions in a language it knows well. You add a reference by @-mentioning a file in Claude Code.

References let Claude look up detailed information about the current plan, and they can be spec files, mockups or even whole codebases. An HTML mockup of a design, for instance, usually gives better results than a written description or a screenshot of it.

Claude Code's /doctor command and the limits of the 80% result

The post ends by suggesting you may need to slim down your system prompt, skills and CLAUDE.md files as Anthropic did, and that the /doctor command can do it automatically. The over-80% figure comes from Anthropic's own coding evaluations on models such as Claude Opus 5 and Claude Fable 5.

Rightsize your skills and CLAUDE.md with /doctor

Anthropic built the post's best practices into claude doctor, which you run in Claude Code as /doctor to rightsize the skills and CLAUDE.md files in your project. For prompting the more advanced models in particular, the post sends readers to Anthropic's Fable field guide.

Comparing a file's character count before and after an edit shows how much the trimming took out. Paste the old and new versions of a CLAUDE.md or skill into the character counter below to see the difference.

Where the 80% result applies: Claude Opus 5 and Fable 5

The over-80% cut is Anthropic's result on its own coding evaluations for models such as Claude Opus 5 and Claude Fable 5, not a rule for every model. The post sets no target size for a CLAUDE.md or a skill.

The post also explains why older models were treated differently. Without the comment guardrails, those models' comments would often have been wrong, so Anthropic kept the rules and accepted the tradeoff.

Anthropic's prompting best practices page has a rule for techniques tied to a model: treat them as measured on that model and test them again against your own evals, meaning tests on your own tasks, before using them with another model. As of late September 2026, the page lists later models such as Claude Opus 5.5 and Claude Fable 5.1, which the July post does not mention.

Anthropic's July 2026 post on context engineering reports cutting Claude Code's system prompt by more than 80% for models such as Claude Opus 5 and Claude Fable 5 with no measurable loss on its coding evaluations. The rules it removed had overlapped and given Claude conflicting instructions. For your own files, the post's advice is to keep CLAUDE.md light, write skills as lightweight guides, prefer code for references and run /doctor.