If you're using Claude Code to build your second brain, there's a new article from Anthropic you need to see. Thoric, a member of the technical staff, just dropped new rules for context engineering on the latest Claude models, and the core idea is dead simple: you're probably burning tokens on stuff that never gets used. Worse, that extra noise is making Claude less accurate. All those system prompts, CLAUDE.md files, memories, skills, and plugins aren't just convenient glue; they add up to a massive context payload that gets loaded every single time you send a message. And if you're not careful, that payload turns into a kitchen sink that costs you money and degrades your results.
Instruction Collision: When Your Rules Fight Each Other
The article starts with something subtle but dangerous. Whenever you send a prompt to Claude, that message is only a small fraction of the actual context the model receives. A huge chunk is assembled from your system prompt, skills, CLAUDE.md files, memories, and whatever else you've wired in. This is context engineering, and you probably know the drill by now. The problem, as the article points out, is that this gets harder as models get smarter. The intelligence goes up, but the guardrails and instructions you've layered on top don't magically adapt. If you built a massive CLAUDE.md and a sweeping system prompt for Opus 4.5, then just swapped the model to something like Opus 5 or Haiku 5, you're still handcuffing the new model with the same constraints. The raw capability improves, but the effective output doesn't, because the context itself introduces friction.
One of the clearest examples is instruction collision. Imagine your system prompt says "do not add comments." Your CLAUDE.md says "comment or document everything." And then your actual prompt asks Claude to "make this readable." Now Claude is stuck. It has to reconcile three contradictory signals, and all that reconciliation burns reasoning tokens, sometimes a lot of them. Instead of getting a crisp answer, you get a model chewing through a logic puzzle just to decide how to even respond. That's token usage you paid for and accuracy you lost, all because the instructions were fighting each other.
The Kitchen-Sink Trap
Another failure pattern the article highlights is what I call the kitchen-sink file. Think about your CLAUDE.md, maybe it's 400 lines long, packed with rules for running tests, linting, commit styles, documentation conventions, deployment checklists, on and on. Now in any given session, how many of those rules actually get invoked? Maybe the "how to run tests" block gets used 5% of the time. The rest? Under 2%, if at all. But that entire CLAUDE.md gets loaded at 100% of every interaction. So you're paying for context that sits there like dead weight, and it's not neutral dead weight. It takes up space in the context window, which means other relevant information gets truncated or pushed out. And it adds mental load for the model, making it less likely to nail the exact task you care about because it's dragging around 398 lines nobody asked for.
This is why Anthropic did something dramatic. They deleted over 80% of their own system prompt for models like Opus and Haiku, with no measurable loss on coding evaluations. How? By packaging functionality into skills that load only when needed, instead of keeping everything permanently active. And they used a single command to make it happen: /doctor in Claude Code, also known as the Claude Doctor skill.
How /doctor Diagnoses and Cleans Your Context
The Claude Doctor is a health check for your entire Claude Code setup. It inspects your claude.json file, your skill usage, your plugin usage, your CLAUDE.md, your memories, and a whole list of checks to audit exactly what's bloating your context. The TL;DR: it finds extensions you pay context for but never touch, permissions prompts you keep hitting meaninglessly, and giant instruction files that barely get used. Then it proposes fixes and lets you approve them.
Run /doctor and you get a full diagnostic in return. It checks things like installation health, skills, MCPs, the size and content of your CLAUDE.md, and whether your configuration is causing truncation. Many people don't realize that once your skills listing climbs above a certain point, things start getting silently truncated. So you might think Claude has access to all your tools, but in reality it's already dropping pieces at the edge. The doctor catches that.
I ran it on my own second brain, which I call Eric OS. That folder holds all my projects, knowledge bases, raw files, skills, and MCPs. I typed /doctor and told Claude to go ahead and run the full audit. What came back was a detailed report broken into groups.
Group A: The Dormant User Skills
The doctor identified 36 user skills I could disable. These were things like design-oriented skills, marketing helpers, various utilities under the "hixo families" umbrella. Skills that might have been useful once, but in my actual daily sessions, they just sat there, loading into context without contributing.
Group B: Project-Specific Keepers
The second category was project-related skills, like my Obsidian integration and video understanding tools. These are tied to specific workflows where I do use them actively. The doctor flagged them for review, but I knew I still needed them.
Group C: Plugins That Overlap
Then came five plugins to consider disabling. A PR review plugin, a Contact 7 plugin, a Stripe co-review, a code simplifier. Some of these had clear overlap with other skills I already had, or with native Claude capabilities that have gotten so good the plugin was redundant.
Group D: Text Edits That Slim Down
Finally, two text-level edits: removing a 12-line block of instructions, and refining the CLAUDE.md itself to strip out rarely-triggered rules.
The bottom line? Roughly 6,000 tokens recovered per session. My skills listing dropped from well over 10,000 tokens to about 6,900, safely under the truncation cap. That's tokens I was paying for every time I sent a prompt, now gone, with no loss in what Claude could actually do. And here's the key: nothing was deleted from disk. The doctor only disables things in settings. You can always reactivate if you realize you need something later.
Cherry-Picking What Stays and What Goes
After the report, I took a middle-ground approach. I didn't blindly approve every recommendation. I told Claude to keep certain things and disable others based on my judgment. For instance, I kept the project-specific skills in Group B because I genuinely use them. From the plugins in Group C, I chose to disable the Stripe one and a contact plugin I hadn't used in months, but I kept at least one PR review tool because I still needed code review automation. I gave Claude those preferences, and it handled the rest, applying the changes and respecting my exceptions.
This back-and-forth matters. You don't want to strip away everything and cripple your workflows. The doctor gives you the information, but the final call is yours. You cherry-pick based on actual usage patterns and what you know you'll need.
Finding Redundancy: The Skill Overlap Problem
One more tip that came out of this process: use /doctor to hunt for redundant skills. After the initial cleanup, Claude pointed out that some of my skills were essentially doing the same job. For code quality, I had multiple tools that all tried to review and simplify code. But one of them was already natively covered by Claude's own capabilities. Others were third-party plugins that overlapped heavily.
For browser automation, I had two different skills: one using Playwright and another using a Chrome connector. Both could drive a browser, but they attacked the problem differently and loaded duplicate context. By picking just one, the one that integrated best with Playwright CI, I cut another chunk of tokens and simplified my stack.
There were skills I had installed months ago and never triggered even once. A Gstack deploy tool, a planning skill. They just existed, adding their descriptions to the model's context each time, while giving me nothing in return. Disabling those was an easy win.
The mental model shift here is important. As Claude models get more powerful, you might not need a specialized skill for every little thing. The model itself can handle tasks that previously required a plug-in. If you can rely on the raw reasoning power of the newest Claude without loading extra scaffolding, you should. The /doctor helps you see where that line is.
Keeping Your Second Brain Lean
What the Anthropic team demonstrated with their own 80% system prompt reduction isn't just a one-time hack. It's a new rule for context engineering. You treat context as a limited, expensive resource, not a dumping ground. Every line in your CLAUDE.md, every extra skill, every plugin, costs tokens and attention. That cost compounds with every single message, silently eating your budget and blurring Claude's focus.
The fix is methodical. Run /doctor regularly. Let it audit your setup. Don't be precious about skills you installed six months ago and never used. If a skill hasn't fired in weeks, disable it. You can always re-enable later. Watch for instruction collisions. If your system prompt and your CLAUDE.md could ever contradict, clean that up now, because models will spend reasoning cycles trying to obey both. And group your instructions into skills that load on demand rather than bloating a permanent file.
When I went through this, I didn't lose any capability I actually needed. I just stopped paying for context that never pulled its weight. And Claude's responses got sharper because it wasn't wading through noise.
Points clés à retenir (Key Takeaways)
- The prompt you type is only a fraction of the context Claude sees; your system prompt, CLAUDE.md, memories, and skills make up the rest, and they load on every request.
- Instruction collisions between different layers of your setup burn reasoning tokens and reduce accuracy.
- Kitchen-sink CLAUDE.md files of 400+ lines often have under 5% utilization per session but cost 100% of the context load.
- Anthropic deleted over 80% of their own system prompt for new Claude models with no degradation, by moving instructions into load-on-demand skills.
- The
/doctorcommand in Claude Code audits your entire setup, finds unused extensions, overlapping plugins, and oversized configuration files, and proposes targeted fixes. - In a real run, one audit recovered roughly 6,000 tokens per session and dropped the skills listing from 10,000+ to under 7,000, safely below truncation limits.
- Cherry-pick which skills to keep, disable, or merge based on actual usage, not instinct.
- Hunt for redundant skills and ask yourself: can the model itself now handle this without a plugin? If yes, ditch the plugin.
That's pretty much the whole playbook. Run /doctor, stop paying for dead context, and let the model use the brainpower you're already paying for. If you want to go deeper on token savings, there are more detailed walkthroughs I'll link around here. But even this one step, auditing your setup and cleaning the fat, is probably the fastest performance boost you haven't tried yet.