← narwal.one/Second Brain
SecondBrain
Ask the Brain
Index/Conceptupdated Sat Aug 08 2026 08:00:00 GMT+0800 (Philippine Standard Time)

Context Rightsizing

prompt-engineeringclaude-mdskillscontext-engineeringcapability-overhangmythos-classfable-5opus-5discipline

Context Rightsizing

The discipline of removing prompt/skill/CLAUDE.md constraint that helped older models but blocks newer ones from reaching their own imagination. The counterweight to context engineering: where context engineering says get the right context to the model at runtime, context rightsizing says remove context the newer model doesn't need.

Named as a working label for a discipline the vault now has cross-vantage evidence for; the load-bearing artefact is The New Rules of Context Engineering for Claude 5 (Thariq Shihipar) — Anthropic's July 24 2026 blog documenting how Claude Code itself rightsized its own system prompt by ~80% for Claude 5.

The mechanism (why it works)

Rightsizing is safe because of Capability Overhang: examples and negation-heavy rules that helped older models now constrain the newer ones, which are more imaginative than the examples given. The old rules existed because older models made poor decisions without guardrails; on the new class, the same rules block the model from reaching its own imagination. Shihipar's canonical phrasing:

"We found that we were overconstraining Claude Code, both through our system prompt and in our CLAUDE.md files and skills."

Anthropic's first-party datapoint: 80% of Claude Code's system prompt removed for Opus 5 / Fable 5 with no measurable loss on their coding evaluations.

Where rightsizing applies — by artefact

The Shihipar blog gives artefact-specific guidance; this concept page holds the discipline-level summary:

Artefact The rightsizing move
System prompt Keep product context; delete the obvious; replace negations with judgment prompts.
CLAUDE.md Lightweight repo description + non-obvious gotchas only; split verification/validation guidance into separate skills; use progressive disclosure.
Skills Lightweight retrieval guides; divide long skills across multiple files; avoid overconstrained instructions except in critical areas.
Tool descriptions Instructions live only in the tool description, not repeated in the system prompt.
References (@mentions) Prefer code / test suites / HTML mockups over prose descriptions. "An HTML mockup will generally produce better results than a description of the design or a screenshot."

Cross-vantage evidence — the four independent voices

The discipline is not one lab's opinion. Four independent 2026 vantages point at the same practice:

Voice Vantage Named form
Thariq Shihipar (Anthropic) Frontier-lab MTS on Claude Code "Remove 80% of the system prompt" + six pattern shifts + claude doctor
Matt Pocock Cross-vendor practitioner + skills authoring rubric The deletion test in Skill Checklist (Pocock): hunt duplication, sediment, no-ops
Lex Christopherson (GSD) Runtime-side framework Context rot — fresh 200k instance per task; per Spec-Driven AI — BMAD SpecKit GSD Superpowers (Vimal Dwarampudi)
Tyler Brown (WF-2026, via Whittemore) Community-consensus quote "Each time there's a new model release, revisit and re-implement your skills" — per 5 AI Engineering Trends That Non Engineers Should Know About (AI Daily Brief)

Convergence pattern: constraint that was optimal for Claude 4-class silently becomes suboptimal for Claude 5-class. The remedy is authored cadence (Brown), inline discipline (Pocock), runtime hygiene (Christopherson), and first-party rule reset (Shihipar) — four levers, one problem.

Distinguished from adjacent disciplines

  • Context Engineering — the parent. Context engineering asks what should the model see at runtime?; context rightsizing asks what should be deleted from what you're currently sending? Rightsizing is the maintenance / regression counterpart of an ongoing context-engineering practice.
  • Prompt Injection — attack-surface discipline; adjacent because both are about "what tokens actually make it into the context window", but rightsizing is quality-side and prompt injection is security-side.
  • Loops as Core Primitive + GSD context-rot — runtime-side rightsizing (fresh instance per task); this concept page is authoring-side rightsizing (fewer tokens per template).
  • Skill Engineering — the broader discipline; rightsizing is a specific periodic pass skill engineers run when the model tier moves.

Practical cadence — the operational shape

Combining Shihipar (rule-set) + Brown (frequency) + Pocock (rubric) + claude doctor (tooling):

  1. On each frontier-model release, run a rightsizing pass on your active skill catalogue + CLAUDE.md.
  2. Apply the six-shift rubric from the Shihipar blog as the diff target — rules→judgment, examples→interfaces, upfront→progressive, repetition→simple, manual-memory→auto, simple-specs→rich-references.
  3. Use Pocock's deletion test on each SKILL.md: hunt duplication, sediment, and no-ops explicitly.
  4. Where the artefact is Claude-specific, run /doctor inside Claude Code as a first-party diff.
  5. Enforce runtime hygiene (fresh instance per task per Christopherson) so authoring-side rightsizing wins are not undone by within-session context bloat.

Direct bearing on this vault

This vault's CLAUDE.md is a first-generation-era artefact by the current rubric — it has heavy negation phrasing ("Never modify raw/", "NEVER create documentation files"), a central repository shape for every operation, and specs stored as markdown rather than code references. The vault also runs an autonomous process-raw job that reads CLAUDE.md in full on every firing; token cost compounds. Two follow-up options:

  • Full pass — apply the six-shift rubric across the whole CLAUDE.md. High-effort, high-blast-radius.
  • Bounded pass — target only the sections the rubric most obviously flags (negation-heavy phrasings; the repeated "never do X" scaffolding; the operations section which currently mixes both structural rules and step-by-step instructions).

Not a call to do either today — a call to do it deliberately rather than by drift, and to schedule the pass to a specific Claude-tier transition marker per Brown's cadence.

Cross-links

2026-08-08 — Independent third-party measurement (xquarx, r/LocalLLaMA)

Per DeepSeek-V4-Flash-0731 Reddit Reception Research (2026-08-08), u/xquarx's harness showdown against DeepSeek V4 Flash on vLLM (identical diffs) put concrete numbers on the token-tax candidate this discipline flags:

  • Pi: 1,340 tokens system-prompt overhead per call
  • OpenCode: 7,197 tokens
  • Claude Code: 23,132 tokens — "most of Claude's tokens is the description of its 27 different tools! The system prompt in Claude Code is actually only 1,430 tokens."

Not a laboratory replication of the Shihipar 80% claim (different metric, different model), but the first independent published measurement of harness-level system-prompt overhead across the three most-used production agent frameworks. The signal:

  • The rightsizing target on Claude Code has already been applied to the system-prompt-proper (1.4k tokens is competitive with Pi's whole overhead). The remaining ~22k is in tool descriptions — the vault's rightsizing rubric now needs an explicit tool-description column, not just a prompt/skill/CLAUDE.md set.
  • Anthropic's own rightsizing move (the 80% reduction) coexists with a per-call harness surface that is 17× the leanest competitor, because the tool set is where the tax has migrated. The two facts don't contradict — they mean the discipline's next frontier is tool-set surface area, not prompt prose.
  • Consumers of harness frameworks now have an evaluable metric: per-call token overhead, per (harness × model × workload). Any competent evaluation of a production coding-agent framework should now include this.

Sources