Anthropic cut 80% of Claude Code's system prompt — your CLAUDE.md is next

Anthropic just admitted its own product was making its own models dumber. Claude Code's system prompt had grown so big and so bossy that the Claude 5-generation models perform worse with it than without it — so they deleted more than 80% of it, reran their coding evals, and measured no loss.

That lands on you directly. The CLAUDE.md rules and memory files you've been stacking up since 2024 are the same kind of bloat, and they drag on Opus 5 and Fable 5 the same way. This guide covers what changed, the new rules, and the cleanup: /doctor to diagnose, plus a /checkup skill you can install in thirty seconds to actually cut the dead weight.

The receipt is a post from Anthropic called The new rules of context engineering for Claude 5 generation models. The short version: for the 5-gen models, Claude Code's own system prompt was overconstraining the model. It had accumulated years of rules written for weaker models — and some of them flatly contradicted each other. One part told Claude to “leave documentation as appropriate” while another said DO NOT add comments. The model was being graded against a rulebook that disagreed with itself.

So they cut over 80% of it. No measurable drop on their coding evals. The team's conclusion, and the reason this guide exists: newer models have good judgment, and every rigid rule you pile on top replaces that judgment with something dumber.

When you type a prompt into Claude Code, that prompt is the smallest part of the message. The harness prepends a system prompt on your behalf: its own instructions, tool definitions, your global CLAUDE.md, the project CLAUDE.md, saved memory, examples. All of it arrives before your first word, every single turn.

Older models genuinely needed the hand-holding — without explicit rules they wrote five-paragraph docstrings and invented file structures. The 5-gen models don't. Feed them the same wall of accumulated instructions and they spend their attention reconciling your rules instead of solving your problem. The context you wrote to make Claude better is now the thing making it worse.

The post reads as a list of reversals — things that were best practice in 2024–25 that are now anti-patterns on 5-gen models:

• Rigid rules → judgment calls. The old prompt said “default to writing no comments… one short line max.” The replacement states intent and trusts the model.
• Examples → interfaces. Worked examples constrain exploration. A well-named tool parameter (a status enum of pending / in_progress / completed) teaches usage without boxing the model in.
• Everything upfront → progressive disclosure. Detail moves into skills and deferred tools that load on demand, instead of sitting in every request whether needed or not.
• Repeated instructions → said once. Guidance that lived in both the system prompt and the tool description now lives in the tool description only.
• Manual CLAUDE.md upkeep → auto-memory. Claude now saves relevant memories on its own. Hand-curating a rules file is no longer the job.
• Markdown specs → rich references. Instead of describing what you want in prose, point at code, test suites, and rubrics the model can verify against.

The comment rule is my favorite because you can feel the difference. Here's the replacement line, verbatim from the new prompt:

“Write code that reads like the surrounding code: match its comment density, naming, and idiom.”

No thresholds, no ALL CAPS, no edge cases. One sentence of intent that works in every codebase, because the model is trusted to look around and adapt.

Start with the built-in check. Inside a Claude Code session, run:

/doctor

Along with the usual install checks, it now looks at your context surface — skills, CLAUDE.md files, appended system prompts — and flags what's bloated. Treat it like a linter: it tells you where the problem is. The next command is how you fix it.

This is the skill from the video. It reads every piece of standing context Claude Code loads for you, then walks through it file by file proposing what to keep and what to cut — and it never deletes anything until you approve the list. One paste creates it:

mkdir -p ~/.claude/skills/checkup && cat > ~/.claude/skills/checkup/SKILL.md <<'EOF'
---
name: checkup
description: Audit every piece of standing context Claude Code loads —
  CLAUDE.md files, memory, skills — and cut what is stale, conflicting,
  or obvious. Use when the user runs /checkup.
---

Audit my standing context, then propose cuts. Never delete anything
before I approve.

1. Gather the surface. Read ~/.claude/CLAUDE.md, the project CLAUDE.md,
   and every file in the memory directory. List each with a line count.
2. Flag, in each file:
   - rules that conflict with each other or with another file
   - rules that restate model defaults ("write clean code",
     "use best practices")
   - facts the repo already teaches (stack, structure, scripts
     in package.json)
   - stale entries: dead paths, old model names, decisions that
     already shipped
   - rigid always/never rules that should become judgment calls —
     propose the rewrite ("never write comments" -> "match the
     surrounding code's comment density")
3. Output a keep/cut table with one-line reasoning per row.
   Keep = a genuine gotcha the codebase cannot teach.
   Cut = everything else.
4. After I approve: apply the cuts, then report before/after line
   counts per file.
EOF

Restart Claude Code so the skill registers, then run it:

/checkup

On my setup the first run flagged rules I'd written a year ago for models that no longer exist — formatting demands, stack notes the repo already answers, memories about decisions that shipped months back. The keep/cut table makes the call easy because every row has a reason attached.

Here's what the cleanup looks like on a real file. The before is the kind of CLAUDE.md most of us have — a style guide the model stopped needing a generation ago:

## Code style
- Always use TypeScript strict mode. Never use `any`.
- Always use descriptive variable names.
- Never write comments unless absolutely necessary.
- Always use functional components with hooks.
- Follow SOLID principles. Write clean, maintainable code.

## Workflow
- Always run prettier before committing.
- Always write unit tests for new functions.
- This project uses Next.js with the app router.
- Components live in /components. Pages live in /app.

…and 40 more lines like this

Every one of those lines is either a model default, a fact the repo teaches on inspection, or an always/never rule that overconstrains. The after is the entire file:

# atareh.xyz
Next.js site on Vercel. Newsletter goes through Resend.

## Gotchas
- pnpm, never npm — the lockfile will fight you.
- The guides route dir is literally named [slug] — quote it
  in shell commands or zsh eats it.
- Vercel KV is the idempotency layer for email sends.
  Don't send without checking it.

One line of purpose, then only the things Claude cannot learn by reading the repo. Anthropic's own advice matches: briefly say what the repo is for, spend your tokens on the gotchas, and let auto-memory handle the rest.

The habit to break is writing rules. The habit to build is writing landmines. If a line in your context tells the model how to behave, it's probably making 5-gen output worse; if it warns about something the codebase can't teach, it's earning its tokens. /doctor tells you when the balance has drifted, /checkup restores it, and auto-memory means you mostly stop doing this by hand.

The wild part is who's telling you. Anthropic didn't theorize about prompt bloat — they deleted 80% of the most battle-tested system prompt in the industry and their own product got no worse. Your CLAUDE.md will survive the same haircut.