Video walkthroughs · Claude Code Club

The New Rules of Context Engineering for Claude Code

12 minute read · Companion guide to “Anthropic Engineers Just Fixed Claude Code and Nobody's Talking About it!”

Most people set up Claude Code once, write a long file of rules, and never open it again. That file loads every single session for the rest of its life. It was written for a model that no longer exists. And it is quietly making your runs slower, more expensive, and worse.

Watch the full walkthrough, including a live run of the built in health check on a real machine.

This guide is built on a write up from Tariq, an engineer on the Claude Code technical team at Anthropic, called The New Rules of Context Engineering for Claude 5 models. The headline finding is blunt. They removed over 80% of Claude Code's own system prompt for the newest models and measured no loss in their coding evaluations. None.

That number is not a curiosity. It is a direct instruction about how the rest of us should be setting up our own tools. If the team that builds the thing found that four fifths of their instructions were dead weight, the odds that your setup is lean are close to zero.

Step 1: Understand what context actually is

When you type a message to Claude, that message is a small fraction of what the model actually receives. The rest is assembled for you, automatically, before a single token of your prompt is read.

• The system prompt that ships with the tool
• Your global CLAUDE.md, loaded on every session everywhere
• Your project level CLAUDE.md, loaded on every session in that directory
• Every skill definition, or at minimum every skill name and description so the model knows what exists
• Any memory that has been saved from previous sessions
• Every tool definition from every connected MCP server
• The files, transcripts, and outputs pulled in as the session runs

Context engineering is the practice of deciding what goes into that pile and when. Your prompt is the smallest lever you have, and it is the only one most people ever touch. Everything above is set before you start typing, which means it is also where the real gains are.

Step 2: The rent you pay on every rule you write

This is the idea worth taking away even if you never change a file. Instructions are not a one time cost. They are rent.

When you add a rule to your CLAUDE.md, you are not making a single decision. You are committing to paying for that rule in tokens, in latency, and in attention, on every session you ever run again, whether the situation it covers comes up or not. A rule that helps in one session out of fifty still bills you fifty times.

Once you see instructions as a recurring cost rather than a free safety net, the whole calculation flips. The question stops being "could this rule ever help" and becomes "does this rule earn its rent across every session it will load in". Almost nothing passes that second test. That is how Anthropic got to 80%.

Step 3: Stop over constraining and start handing over judgment

The Anthropic team found they were over constraining Claude Code through the system prompt, through CLAUDE.md files, and through skills. Reading back their own transcripts, they found instructions that actively contradicted each other. One place said keep all the documentation. Another said do not add documentation.

The model can usually work out what you actually want from the surrounding context. But when two of your own instructions disagree, it has to spend effort reconciling them before it can do anything useful. You wrote both rules to be helpful. Together they are a tax.

Most of those guardrails are fossils. They were written to stop worst case behavior from an older, weaker generation of models. Delete them and let the model use its own judgment and the surrounding context, and you get the same results, faster and cheaper. The shift is from telling the model what to do to telling it what you are trying to accomplish.

In practice that means replacing a numbered list of ten steps and ten prohibitions with a short statement of the goal, the constraints that genuinely matter, and permission to figure out the rest.

Step 4: Rewrite CLAUDE.md as an index, not a manual

The common myth is that your CLAUDE.md should be a central repository for every practice you might ever need. That was reasonable when CLAUDE.md was the only memory the tool had. It is not the case any more.

The better shape is a tree. A short top level file that tells the model what exists and where to look, and a set of sub files and skills holding the detail. Think of the top file as a table of contents, not a chapter.

A good top level file names the projects, points at the skills and what each one is for, and stops. It does not explain how to do the thing. It says where the explanation lives so the model can go get it when the job calls for it.

Step 5: Move standing instructions into skills

A skill is a set of instructions, rules, or a process you want followed for a specific kind of job. The critical property is that its body loads when it is invoked, not on every session.

That distinction is the whole point. A process you use once a week costs you almost nothing as a skill and costs you every session as a paragraph in CLAUDE.md. Anthropic did exactly this with their own instructions. Code review and verification guidance used to sit in the system prompt permanently, because when it was needed it mattered a lot. They moved both into skills the tool calls only when the moment arrives.

This has a catch, and it is the one people miss. Skills are not free either. The model has to know a skill exists to call it, which means every skill's name and description is loaded on every session even when the body is not. A handful of skills is invisible. A hundred is a bill.

Step 6: Apply the same thinking to tools

Every connected MCP server publishes tool definitions, and by default those definitions all load up front. Ten servers with a dozen tools each is a substantial block of context consumed before you have asked for anything.

The alternative is tool search. Load short definitions of what each tool does, let the model search those definitions when it needs something, and pull the full schema only for the tool it actually picked. Same capability, a fraction of the standing cost.

This is the general pattern, and it has a name: progressive disclosure. Load the right context at the right time. Call information when you need it and do not call it when you do not. It applies to your CLAUDE.md, your skills, and your tools identically.

Step 7: The decision that actually matters

Every restructure comes down to one fork, repeated for each piece of guidance you own. Does this stay always loaded, or does it move out into something loaded on demand?

Keep it always loaded when all three of these are true:

• It applies to essentially every session, not a category of them
• Getting it wrong is expensive or hard to undo, so you cannot risk the model not fetching it
• It is short. One or two lines, not a section

Move it into a skill or sub file when any of these are true:

• It only applies to one type of work, one client, or one repository
• It runs longer than a short paragraph
• It is a process with steps rather than a preference
• You could name the situation that triggers it in a single sentence

The tell is whether you can name the trigger. If you can finish the sentence "when I am doing X, do this", it belongs in a skill, and the X is your description line. If you cannot, and it truly applies to everything you ever do, it stays, and you make it one line.

Step 8: Run the health check before you change anything

There is a skill that ships with Claude Code and almost nobody uses. In the terminal, run the doctor command. It runs a full health check on your setup. It is read only first, which means it scans everything, reports back, and asks before it changes a thing. You stay in control of what gets cut.

It checks nine things:

1. Install health, including duplicate or leftover installs
2. Broken settings files or colliding agent definitions
3. Dead weight: skills, MCP servers, and plugins you never actually use, measured against your real usage counters and session transcripts
4. Repetition and redundancy across your CLAUDE.md and the rest of your setup
5. Whether your CLAUDE.md carries context the session could work out on its own
6. Lazy loading: always loaded guidance that would be better as a sub file or a skill
7. Scripts that block the loop on every tool call
8. Context weight, meaning what is eating your budget before you type anything
9. Version currency and permission fixes, including whether auto mode is your default

Run this first. Not because it will make the right calls for you, but because you cannot make good decisions about your setup without knowing what it currently costs. Most people have never seen that number.

Step 9: What a real setup looked like

Here is the actual output from running it on a working machine that had already been cleaned up once, so this is close to a best case.

The install was healthy. Latest version, nothing broken, no duplicate installs, no colliding agents. The CLAUDE.md file was in reasonable shape because a dedupe pass had already been run against it.

The real finding was skill bloat. 113 personal skills, eating roughly 10,000 tokens of context in every single session just to list them. Twenty five of those had never once been used, verified against the actual usage counters across the fifty most recent sessions. The bulk of the token load traced back to a subset of around 88 personal skills.

Ten thousand tokens is the cost of existing. That is spent before a question is asked, on every session, forever, and a quarter of it is for skills that have never fired once. That is the shape of the problem on a setup that was already considered tidy.

Step 10: The failure modes that bite people

Four things go wrong when people do this restructure, and all four are avoidable.

The first is deleting rules without checking why they were written. Some guardrails were fossils from an older model. Some were written the day something expensive broke. Before you cut a rule, ask whether the model can now be trusted to work it out or whether it is the scar tissue from a real incident. Cut the first kind freely. Keep the second kind and make it one line.

The second is moving everything into skills and then creating a worse problem. Skill descriptions load every session. If you shred a 400 line CLAUDE.md into forty skills, you have not removed the cost, you have renamed it and made it harder to see. Consolidate related work into one skill instead of splitting by task.

The third is writing skill descriptions the model cannot route on. A skill that never gets called is pure cost. The description is the only thing loaded by default, so it has to say plainly what situation the skill is for. Vague descriptions produce skills that sit there, billed and unused.

The fourth is doing this once and calling it done. This is the same mistake that created the mess. Setups accumulate. Put it on a recurring cadence, monthly is plenty, and the whole thing stays lean with a few minutes of attention.

Step 11: Do this in one sitting

The shortest honest path from reading this to having a leaner setup, in about an hour.

1. Run the doctor command in the terminal and read the report without changing anything yet. Write down the context weight number.
2. Take the list of never used skills, plugins, and MCP servers. Delete the ones you do not recognise. Anything you are unsure about, leave for now.
3. Open your global CLAUDE.md. Cut every line describing something the model could discover on its own: directory structure, tech stack, build commands, file naming.
4. Read what is left and find the contradictions. Reconcile each one into a single clear statement, or delete both sides if neither still matters.
5. For every remaining block longer than a short paragraph, finish the sentence "when I am doing X, do this". If you can, move it into a skill and make that X the description.
6. Rewrite what survives as an index. Projects, skills, what each is for, nothing more.
7. Turn one of your longest rulebook style instructions into a statement of the goal instead of a list of steps, and run a real task against it to feel the difference.
8. Run the doctor command again and compare the context weight to the number you wrote down.

That last step matters more than it sounds. Seeing the number move is what turns this from a piece of advice you agreed with into a habit you keep.

What this really comes down to

Every rule you write is a bet that the model cannot handle a situation on its own. Two years ago that bet was usually right. It is now usually wrong, and you pay the losing side of it every session.

The people getting the best output from these tools are not the ones with the longest configuration files. They are the ones who worked out what to stop saying.

Read this online at claudecodeclub.ai