---
name: context-diet
description: Slim down CLAUDE.md, skills, and system prompts. Claude 5-class models have judgment that already covers most generic rules — old guardrails become noise, and worse, they conflict with each other. Use when creating or reviewing a CLAUDE.md or SKILL.md, when adding a rule to one, when context feels bloated, or when asking "where should this rule live?".
---

# Context Diet

Based on Thariq's *The new rules of context engineering for Claude 5 models* (2026-07-25).
Anthropic removed **over 80%** of Claude Code's system prompt for Claude Opus 5 / Fable 5
with no measurable loss on their coding evals.

## The one-liner

**The model got better, so your guardrails became noise.** What older models needed spelled
out, newer models judge better on their own. Keeping the old rules doesn't just waste tokens —
worse, **they fight each other**, and the model burns reasoning reconciling them before it can act.

## Five things that are now obsolete

| Then | Now |
|---|---|
| Give Claude rules | **Let Claude use judgment** — keep rules only where you've actually been burned |
| Give Claude examples | **Design interfaces** — examples pin the model to the demonstrated solution space; parameter names and enum values are themselves the hint |
| Put it all up front | **Progressive disclosure** — split into a tree, load at the right time |
| Repeat yourself | **Put it in the tool description** — don't restate it in the prompt body |
| Save memories into CLAUDE.md by hand | **Auto-memory** — the model saves what's relevant |
| Simple markdown specs | **Rich references** — an HTML mockup, a test suite, a portable function, or a rubric all work as specs |

## Layering: where does this belong?

- **System prompt** — what the product is and what it's doing. Don't touch it in Claude Code;
  worth real investment only if you're building your own agent harness.
- **CLAUDE.md** — keep it light. One line on what the repo is for, then **spend the rest of
  the tokens on gotchas** — the things you can't tell by reading the code, that you only know
  because you got burned.
- **Skill** — opinions, knowledge, and practices specific to *you*, your team, or your product.
  Long skills keep splitting into more files.
- **References** (`@` or a path pointer) — deep material: specs, mockups, whole codebases.
  **Prefer things that exist as code** — an HTML mockup beats a written description or a
  screenshot by a wide margin.

## Delete list

1. **Generic engineering virtue** — "write minimal code", "don't over-abstract", "make surgical
   changes", "think before you code". Built in. Delete.
2. **Absolute style bans** — "never write comments", "always do X". Replace with judgment:
   *"Write code that reads like the surrounding code: match its comment density, naming, and idiom."*
3. **Anything visible from the filesystem** — directory listings, script inventories, frontmatter
   templates (if a script fills it in, don't paste the YAML).
4. **Rules that contradict something else** — especially anything demanding "list all tradeoffs /
   stop and ask when unsure" sitting next to "keep replies short". **A conflict costs more than
   redundancy.**
5. **Examples of how to call a tool** — move that into the tool's or script's own description.
6. **Copies of spec values** — a copy in the prompt body is a second source of truth that will
   go stale. Keep the pointer only.

## Keep list

1. **Gotchas paid for with an incident** — "we did this, it blew up, don't". **Never delete these** —
   only split them downward.
2. **Counterintuitive project conventions** — the ones that violate general best practice
   (e.g. "in this repo you *should* `git add -A`"). Unwritten, they'll get "corrected".
3. **Facts the model cannot derive** — where the keys are, which environment is production,
   who owns which module.
4. **Instructions that deliberately override default behavior.**
5. **Personal triggers and preferences** — shorthand, command words, communication style.

## The technique for splitting gotchas

A mature hard-won rule usually looks like this:

```
## Rule: X (prevents "Y")
Lesson (2026-07-10, severe): ...300 words of what went wrong... root cause = ...
Rules: 1. ... 2. ... 3. ...
```

**Keep the rules in CLAUDE.md. Move the incident narrative to something like
`docs/why-these-rules.md`, leaving one line of "why" plus a pointer.**

The war story is only needed when someone wants to *overturn* the rule — which is the
definition of progressive disclosure. This routinely cuts 30–50% while losing zero information.

## Three self-checks

Before writing any line, ask:

1. **Would the model do this anyway?** → Delete.
2. **Could it be discovered by looking at the repo?** → Delete.
3. **Does it contradict a rule elsewhere?** → Keep one, delete the other. Never both.

## Wrapping up

- Run `/doctor` (built into Claude Code) afterward — it rightsizes skills and CLAUDE.md automatically.
- Dieting means **removing noise, not knowledge**. Confirm every removal has somewhere to go;
  gotchas move house, they never get thrown out.
- Real before/after cases: see `examples.md` and `before-after/`.