When Claude Code starts to feel slower or less sharp, the problem may not be the model at all. It may be everything piled on top of it. Anthropic says it cut more than 80% of the Claude Code system prompt, the standing instructions the model reads before every task, with no measurable drop on coding benchmarks. The same logic applies to your own setup: old rules, unused skills and instruction files leaking in from other folders all ride along in every session. The built-in /doctor command is a quick way to find that weight and decide what to drop.
Why less instruction did not mean worse results
Older models tended to ramble unless told otherwise, so the system prompt carried many hard negative rules, such as strict limits on comment length. For newer models like Opus 5, Fable 5 and Fable 5.1, Anthropic removed those guardrails. The long comment rule became a single line: write code that reads like the surrounding code, match its comment density, naming and idiom, and use your judgment. The reasoning is that stronger models already have good judgment, and rigid rules get in their way.
Boris Cherny, who created Claude Code, goes further. He suggests that developers using coding agents delete their CLAUDE.md files, skills and hooks every six months to see what a newer model can now handle on its own. A useful name for the problem he is pointing at is instruction debt: rules added after one past mistake that stay active long after a model update made them unnecessary. A rule like “only use blue” added to CLAUDE.md after a branding slip-up is a typical example.
More context is not automatically better, either. A 2025 study of five models found that longer inputs cut performance on math, question answering and coding by 13.9% to 85%, even when all the needed information sat inside the context window, the amount of text a model can read at once. Those were controlled experiments on models from more than a year and a half ago, so the exact numbers may not carry over to trimming a personal CLAUDE.md.
Anthropic applied the same idea to tools. Instead of loading every MCP tool definition upfront (MCP, or Model Context Protocol, is the standard that connects AI models to outside tools and data), Claude Code can use a tool search tool to find definitions only when it needs them.
| Measure | Load everything upfront | Tool search on demand |
|---|---|---|
| Tokens for tool definitions | About 72,000 for 50+ tools | About 500 upfront |
| Total context used | About 77,000 tokens | About 8,700 tokens |
| MCP eval score, Opus 4 | 49% | 74% |
| MCP eval score, Opus 4.5 | 79.5% | 88.1% |
Token use fell by 85%, and accuracy went up rather than down.
▲ Loading tools only when needed
Give less, but keep what matters
Anthropic’s Applied AI team recommends aiming for the minimal set of information that fully specifies the behavior you expect. Minimal does not mean leaving out necessary technical details. What you cut is step-by-step micromanagement; what you keep are facts the model cannot infer or look up. Put simply, the best context is the smallest amount that produces the best result at the lowest cost.
When handing a task to a current model, three things are usually enough:
- The outcome: what “done” looks like
- The reason: why you are doing it
- The constraints: the limits that must be respected
Stating the reason matters more than it might seem. In one comparison, an interview transcript was turned into a resource guide two ways. The heavily specified setup, with formatting rules, branding templates, link rules and structural instructions, produced a polished document with branded headers. The minimal setup, which only explained that the guide was meant for students, produced better organized content, richer technical detail and precise timestamps. Stating that intent leads Claude to reach for analogies, intuitive explanations and relatable examples on its own. Polished visuals, it appears, can hide weaker structure.
That does not mean deleting all background. Context that is specific to the job, such as voice, strategic goals and target audience, is worth keeping, while rigid procedural checklists are worth testing and trimming. Detailed procedures for one task, such as video editing rules, should load only when that task is active, not during scriptwriting. A good CLAUDE.md stays short: the project’s purpose, the key pitfalls, and pointers to deeper instruction files that are read only when needed.
What /doctor finds
Running /doctor in Claude Code starts ten read-only checks across settings, plugins, MCP servers, skills, memory and installation paths. The report lists each skill with its scope, how many times it has been used since installation, its estimated resident tokens, and a recommended verdict such as remove. Claude Code registers skills by reading only the YAML frontmatter, the short header at the top of a skill file, rather than the whole file. Even so, every registered skill costs some tokens in every session.
One real workspace audit turned up the following:
| Finding | Detail | Payoff |
|---|---|---|
| Unused skills | 18 older skills with zero use across the last 50 sessions and 252 startups, including two that held 103 and 111 tokens | An estimated 1,088 tokens saved per session by turning them off |
| Broken skills | One skill file misnamed, another failing because an unquoted colon broke the YAML | Fixing them lets the skills register again |
| Leaking parent file | A CLAUDE.md on the Desktop added about 1,960 tokens to a project below it | Ignore the ancestor file |
| Duplicate guidance | About 2,250 characters of repeated routing instructions in CLAUDE.md | About 563 tokens saved |
| Empty template | Placeholder text in CLAUDE.local.md | 35 tokens saved |
Saving 35 tokens sounds trivial, but small waste compounds quickly over long sessions. Unused skills do not have to be deleted; they can be switched off in a local settings file. When the checks finish, /doctor asks whether to apply everything, pick items, keep everything or customize. Review the list before approving rather than accepting automated deletions blindly.
▲ A health check for your Claude Code setup
Auditing the workflow, not just the settings
The same approach works on whole workflows. In one repository used to produce video scripts, Claude Code was asked to show the smallest change that would speed up the path from a raw idea to a filming-ready script, reusing existing systems, citing the exact files involved, and editing nothing yet.
It found that the outline skill and the script skill were each running their own primary-source fact-check. Of 25 project folders, only 3 had a standard sources.md file recording the research, so findings were not being handed from one step to the next. Claude proposed three edits across the two skills: save the evidence to sources.md during outlining, and have the scripting step read from that file instead of researching again. When the handoff between steps is not standardized, the same checks and calls tend to repeat.
Bottom line: audit on a schedule and whenever the model changes
Getting more out of Claude Code is often about removing instructions, not adding them. A practical routine:
- Run
/doctorin your project and look for unused skills, broken frontmatter and CLAUDE.md files leaking in from parent folders. - Review each finding, switch off skills you do not use, and quote frontmatter values that contain colons.
- Remove rules in CLAUDE.md that were added for old mistakes, merge duplicate guidance, and move task-specific procedures into separate files.
- When assigning work, state the outcome, the reason and the constraints, and let the model propose the structure.
- Audit monthly if your setup changes often, quarterly if it is stable, and right away whenever you switch your main model, because each model reads instructions differently.
You can also schedule /doctor and a broader audit as a background task that surfaces recommendations for one-click approval. Inconsistent upkeep is the most common reason personal AI setups decay, so taking the habit out of human hands looks like the more durable option.