Claude Code Cut 80% of Its System Prompt. I Rethought My Content System.

TL;DR: Claude Code removed more than 80% of its system prompt for frontier models such as Opus 5 and Fable 5, with no measurable loss on its coding evals. That result made me audit my own content system. As models improve, old instructions need a deletion path. Context, tools, state, evals, and feedback should carry more of the load.

§A useful signal from July 24

On July 24, Claude Code engineer Thariq Shihipar published a post about how the team changed its context for a new generation of models.

One number stood out. Claude Code removed more than 80% of its system prompt for models such as Opus 5 and Fable 5. Its coding evals found no measurable loss.

The scope matters. This was one coding product, measured on coding tasks, using frontier models. Claude Code still gives older models a fuller system prompt.

The team also explained what it removed. Earlier models needed lots of examples, repeated reminders, and hard rules. Newer models can infer more from the codebase, tool design, and task context. Old examples may narrow the model's search space. Conflicting instructions create extra work on every request.

Anthropic's response was practical: reduce hard constraints, make tool interfaces clearer, load detailed skills only when needed, and let the model use local context to make more decisions.

I immediately thought about my content system.

§Skills collect debt too

Over the past few months, I've split topic selection, briefs, drafting, titles, images, review, publishing, and archiving into separate skills.

It worked. A process that once depended on my memory became something an agent could follow. By agent, I mean an AI system that can call tools and complete a multi-step task.

The maintenance pattern started to worry me.

If an opening felt weak, I added a hook rule. If the copy sounded machine-written, I added more banned phrases. If a fact slipped through, I added another mandatory check. One weak post could trigger a new audience-analysis framework.

Each addition made sense by itself. Over time, a single skill started carrying the task definition, writing method, tool instructions, quality checks, recovery behavior, and user preferences. Rules repeated. Exceptions grew. Some instructions pulled in opposite directions.

I used to treat a longer, more complete skill as a more mature skill.

After running this system for a while, I'm less sure. A system that only adds rules will eventually drag its whole history into every task.

§Put each failure in the right layer

Claude Code's cleanup gave me a better debugging question. When a task fails, I should locate the layer before editing the prompt.

1. ·If the model missed a source, fix context selection.
2. ·If a claim is unreliable, use search and evidence checks.
3. ·If a long task loses progress, fix state and recovery.
4. ·If quality is hard to judge, add an eval or acceptance check.
5. ·If an action carries risk, control it with permissions and human approval.
6. ·Update the skill only when the model lacks a reusable judgment it can't infer from the task.

Some instructions still need to stay. Privacy limits, publication approval, factual checks, and voice rules are easy to get subtly wrong. They also fail quietly. Those rules are load-bearing.

Other material can move. Detailed examples can live in references and load only when relevant. Verification can become a separate skill called before publishing. Task progress belongs in state. Past feedback belongs in memory and data.

Prompt deletion works only when another part of the system can take over the job.

§What I mean by a content system 2.0

My current setup is a content system 1.0. It teaches an agent how to do the work by turning experience into prompts and skills.

The next version has to make delivery reliable over time.

That includes choosing the right source material for each task, checking facts, recovering interrupted work, defining what good looks like, and feeding publication results back into the next decision. One larger skill won't solve all of that.

It needs a fuller agent harness, the runtime system around the model. Prompts can hold principles and essential boundaries. Context, tools, memory, state, evals, permissions, and feedback each need a clear job.

Version 1.0 focused on the quality of one generation. Version 2.0 has to protect the floor across many deliveries.

§I'm starting with a rule audit

I won't copy Claude Code's number and delete 80% of my skills. Content has no compiler. A voice mistake or factual drift may look fine until a reader points it out.

I'll start with three questions for every rule:

1. ·Which real failure caused us to add it?
2. ·Can the model infer the right behavior from the material already available?
3. ·What result will tell us whether deletion was safe?

Rules with no traceable failure go onto the deletion list. Task-specific material moves behind progressive loading. Privacy, publishing, factual, and permission boundaries stay.

I don't know how much I can remove yet. I need to test the changes on real work.

The direction is clear enough to act on. When the model changes, the surrounding system has to shed old scaffolding too. The durable advantage will come from how well the system organizes context, tools, verification, and feedback around the model.

§Sources

• ·Anthropic: The new rules of context engineering for Claude 5 generation models
• ·Thariq Shihipar's original X post
• ·Simon Willison's edited transcript of the Claude Code team interview