How to Keep Your Agent Instructions from Going Stale

How to keep the instructions you give a coding agent from going stale.

In July, Anthropic cut Claude Code’s own system prompt from roughly 800 tokens to 164. More than 80 percent removed, with no measurable loss on their coding evaluations. Their stated reason is worth sitting with: overly detailed rules, examples and instruction files can restrict a capable model rather than improve its decisions.

If that holds for the prompt written by the people who build the model, it holds for the rules file you wrote only a month ago. Opus 5 has been out for days. Most instruction files were written for something less capable.

A single large figure, 164, beside the words: tokens, down from about 800. Below it, Anthropic removed more than 80 percent of it and measured what that cost, followed by a marked statement that there was no measurable loss on their coding evaluations. A footer gives their stated reason, that overly detailed rules, examples and instruction files can restrict a capable model rather than improve its decisions, and notes that Opus 5 has been out for days while most instruction files were written for something less capable, including the one you wrote last month. — Anthropic's own numbers, published July 2026, for their own system prompt. The claim of no measured loss is theirs about their coding evaluations, not a general result.

Measure	Value
System prompt before	~800 tokens
System prompt after	164 tokens
Reduction	over 80%
Measured loss on their coding evals	none
Published	2026-07-24

Why instructions go stale in the first place

Most rules in an instructions file were written to compensate for something. The model did the wrong thing once, so you wrote a rule. That rule was correct on the day you wrote it.

Two things then happen without anyone touching the file.

The model gets better, and the weakness the rule was compensating for goes away. What is left is a paragraph of instruction spending context on a problem that no longer exists.

And the surrounding tooling starts doing the same job natively. The interface descriptions your agent already reads may now instruct the exact behaviour your rule spells out. At that point the rule is not just unnecessary, it is a second copy of an instruction that can drift from the first.

Neither of these announces itself. The file keeps working, so nobody re-reads it.

A single horizontal stacked bar showing 22 rules split four ways, with each segment sized to its share: 4 cut outright, 1 merged, 5 compressed, and 12 kept untouched. A bracket above the bar groups the first three as 10 removed or compressed, and the last as 12 kept untouched. A legend names each verdict with its count, noting that the 4 cut outright went because the tooling now says it natively. A footer records that roughly 35 to 40 percent of the block was removed or compressed, and that what survived is the instructive half: access policy, personal failure modes, and one rule that overrides a default, where deleting it lets the default silently return. — The retention test applied to 22 real rules. Segments are drawn to exact proportion, and the removed-versus-kept split is stated in the bracket rather than implied by colour.

Verdict	Rules	Reason
Cut outright	4	The tooling now instructs this natively
Merged	1	Two rules stating one constraint
Compressed	5	Intent kept, examples and enumerations dropped
Kept untouched	12	Worst-case scenarios, or specific to me

How to decide what actually goes

The useful part of Anthropic’s guidance is a retention test, not a target percentage. A rule earns its place if it does one of two things: it addresses a worst-case scenario, or it encodes opinions, knowledge or practices specific to you. General advice a capable model would follow anyway does not qualify.

I ran that test across my own global rules, with every proposed change carrying a confidence grade for how certain it was that the change lost nothing. I approved the high and medium sets. Roughly 35 to 40 percent of the rules block came out or was compressed.

Two rules were removed because I compared them against the instructions the tooling itself already hands the agent, and found near-identical wording sitting there. I did not have to decide whether those rules were still useful; I could see they were duplicates. If you do one thing from this piece, start there: read what your tools already tell the agent, then delete your own copies of it.

What survived is as instructive as what went. Access policy stayed, because getting it wrong is a worst-case scenario. A rule that deliberately overrides a default behaviour stayed, and it is the strongest possible keep, because the moment it is deleted the default silently returns. Rules encoding my own repeated mistakes stayed, because a model has no way to know which errors I personally keep making.

Nothing structural was touched. Permissions and enforcement hooks are not advisory text, and the guidance does not apply to them.

Titled: four quality review skills, evaluating every other skill. Each asks a different question. Four columns, grouped by a bracket into two that look inward at the skill itself and two that look outward at a moving platform and field. Looking inward: form, asking is it well formed, checking frontmatter quality, structural completeness, cross-reference integrity and hook consistency, run on demand; and design, asking is it well built, checking wasted context, design anti-patterns and a missing statement of what the skill produces, where the lean-context checks live, run nightly. Looking outward: effectiveness, asking is it still good at its job, researching current practice in that skill's own subject and naming where the skill has fallen behind, run twice a week as the expensive one; and redundancy, asking should it still exist, comparing the skill against what the platform now does natively so anything obsolete can be deleted rather than maintained, run nightly. A footer states that the outward two are the ones that decay, because a well-formed and well-built skill stays that way on its own while whether it is still the best approach and whether it should exist both change without anyone touching the file. — Each reviewer asks something the others cannot answer. The split that matters is inward versus outward: only the outward two go stale on their own, which is why those are the two worth scheduling.

Skills that review your other skills

This next part assumes something most people have not built yet, so it is worth explaining plainly before the rest makes sense.

Alongside the skills that do my actual work, I keep a small set of skills whose only job is to review the others. One checks structure and health: is a skill well formed, are its references intact, does it declare what it produces. One reviews design quality: is it bloated, is it doing something the platform now does for me, is it clear about what it refuses to do. One researches the current state of the art for that skill’s subject and asks whether the skill is still good at its job. One compares each skill against what the platform can now do natively, so I can delete anything that has been made redundant.

That review layer is the thing worth copying from this piece. Instructions and tooling decay, and a capable reviewer that knows what good looks like can find the decay far faster than you will by reading your own files.

But building the reviewer is only half of it, and the half that is easier to get wrong is what makes it run.

Two panels contrasting a broken check with its replacement. What was there: warn if the cached data is over 30 days old, where the check lives inside a tool run by hand, only evaluates when that tool runs, and nothing ever scheduled the tool to run, so detecting the staleness required the very run that was not happening and shortening 30 days to 7 would have changed nothing. What replaced it: a gate that refuses rather than warns past 45 days, an explicit override for a knowingly accepted risk, and a scheduled job guaranteeing the run happens, because a run-time check needs a scheduler paired with it rather than a stronger threshold. — The failure was structural, not a badly chosen number. Any warn-if-old check inside a tool you invoke by hand has the same hole unless something separate guarantees it runs.

Why an on-demand check cannot catch its own staleness

The skill that compares my skills against current platform capabilities keeps a cached inventory of what the platform can do. That inventory carried a warning: if it is more than thirty days old, say so. Reasonable design.

The inventory was over four months stale, and the warning never once fired.

The reason is structural, not a badly chosen number. The check only ran when the skill ran, and nothing ever caused the skill to run. Detecting the staleness required exactly the run that was not happening. Shortening thirty days to seven would have changed nothing.

So the fix was not a louder warning. It was a schedule.

Put plainly: a review that depends on you remembering to ask for it will not happen, because remembering is the part that fails. Put it on a timer and it happens whether or not you thought about it that week. The benefit is that drift gets caught on a cadence you chose, rather than whenever you happen to look, and you stop assuming your tooling is current when you have no evidence that it is.

The check itself also changed from a warning to a refusal. Past 45 days it will not run an assessment at all against stale data, with an explicit override for when you accept the risk knowingly. A warning is advice. A refusal is a decision.

What runs now

The rule is a new category on the review checklist with four checks: rules a capable model would follow anyway, examples that repeat what the tool already tells it, long specifications that belong in a separate file, and instructions that reimplement something the platform now does itself. The checklist is version stamped, so every review records which version it was judged against.

The job runs nightly and takes one or two skills at a time, oldest first. The expensive pass, the one that researches current best practice for each skill’s subject, runs twice a week instead of nightly.

The rule that makes it safe to leave running: it proposes, and never edits. No file changed, nothing committed. Findings land in a queue marked pending, and a notice when I start a session tells me how many are waiting. Keeping or dropping each one is my call, made in a normal working session.

That boundary matters more than the automation does. An unattended process allowed to edit your instructions can degrade them while you sleep, and you would find out slowly.

What the first night produced

It ran for the first time this morning and finished clean. Two skills reviewed, eight findings queued, nothing changed.

The findings are small and specific. One constraint stated four separate times in a single file. A fixed list of banned phrases being checked by reading when a search would do it properly. A missing completion line that the neighbouring skill already defines.

None of it is dramatic. All of it is the kind of thing that accumulates for a year and never rises far enough up anyone’s list to fix.

First unattended run	Result
Started	02:00:01
Skills reviewed	2
Findings queued	8
Edits applied	0

One scan, two destinations

My Claude Code Coach has a frontier scan capability that scans weekly for new techniques and tools I am not using yet. The frontier scan sends its findings to two places.

One goes to me. When the scan finds something I do not do yet, it gets embedded into my coach’s frontier skills for it to coach me on, raised at the moment the work in front of me would actually benefit from it. Not a newsletter I skim. A nudge at the point of use.

The other goes to my tooling. The same finding becomes a check on the skill quality review checklist, and from then on every skill I own gets measured against it automatically, on a schedule, without me deciding to care.

That is the whole idea. One unattended scan keeps both halves current: what I am being coached on, and what my tools do. The field is moving faster than anyone can track by hand, and the answer is not to read harder. It is to have something read for you, teach you at the moment it matters, and hold your tooling to the same standard without being asked.

What this does not establish

One night is one night. Eight findings from two skills says the process produces output, not that the output is worth acting on. The real test is what fraction I keep versus drop over the next few weeks, and if most of it turns out to be not applicable, the best response is to drop the cadence or scrap it.

The percentage I cut may not be your percentage. Yours may be more or less than mine… so someone with leaner instructions would cut less, and someone with a file older than mine would cut more.

And the whole approach rests on the claim that current models need less instruction than older ones. That claim comes with evidence for Claude Code’s own prompt. It is reasonable to expect it generalizes, and it is not proven for your particular rules on your particular work.

The cleanup is not the achievement. Anyone can delete text once. The thing worth building is whatever notices, without being asked, that both you and your tools have fallen behind.