context engineering for claude 5: what to delete from your project instructions.
anthropic rewrote how it prompts claude and deleted most of it. the instructions you wrote a year ago are probably the thing holding your output back.
context engineering is everything claude sees before it answers: standing instructions, memory, references, and the tools it can reach. in july 2026 anthropic rewrote its own, cutting over 80% of claude code's system prompt with no measurable loss on coding evaluations. the lesson applies even if you never write code. most project instructions are now too long.
the write-up was built for developers. six shifts, all framed around a codebase. but if you run claude through project instructions, a handful of skills, and whatever it remembers about your business, every one of them still applies. they just need a translation. that is what this post is.
what anthropic actually changed
anthropic found that claude 5 generation models needed far fewer explicit rules than older models to produce the same quality of work, so they deleted most of them. the post, "the new rules of context engineering for claude 5 generation models," was published july 24, 2026 by Thariq Shihipar, a member of technical staff at Anthropic (claude.com/blog).
anthropic "removed over 80% of Claude Code's system prompt" with no measurable loss on its coding evaluations.
that is the headline, and it is the opposite of what most people do when output disappoints. the instinct is to add: another rule, another example, another "always remember to." anthropic went the other way and got the same results from a fraction of the instructions.
the six shifts, then and now
here is anthropic's framing in the left two columns, and what it means for a setup with no codebase in the third.
| then | now | what that means without code |
|---|---|---|
| give claude rules | let claude use judgement | if your project instructions read like a contract, you are briefing a 2025 model. keep hard rules for what is expensive to get wrong. |
| give claude examples | design interfaces | three sample posts teach claude to copy your samples. a short brief (audience, goal, constraint) lets it reason instead. |
| put it all upfront | use progressive disclosure | this is what skills are for. lean standing rules, and separate skills claude pulls in only when the task calls for them. |
| repeat yourself | simple tool descriptions | anthropic's duplication sat between the system prompt and the tool descriptions. yours sits between project instructions and the skills that restate them. |
| memory in claude.md files | auto-memory | in claude code, hand-written memory files gave way to claude saving what is relevant on its own. |
| simple specs | rich references | stop summarizing your brand guide into a paragraph to save space. hand claude the actual document. |
why the repetition one gets misread
this shift is about where instructions live, not about how well the model listens. anthropic's problem was that the same guidance appeared in the main system prompt and again in a tool's own description, so they consolidated it into the tool definitions and deleted the duplicate. it is an architecture fix.
the operator version is the same shape. if a rule sits in your project instructions and again inside three separate skills, pick the one place it belongs and delete the other two. not because claude missed it the first time, but because every duplicate is context you are paying for and a second copy you now have to keep in sync. i wrote the fuller version of that argument in more context isn't better.
what to delete first
pull up your project instructions and read them with one question: does claude still need this line, or did an older model need it? work in this order.
- rules written to prevent an old failure. anything that exists because a 2025 model used to hallucinate a format, forget an instruction, or drift off tone. that is the biggest block, and it usually goes first.
- anything you wrote twice. the same rule in project instructions and in every prompt "just in case."
- long worked examples. if you pasted three samples to set a vibe, replace them with a description of the goal and the constraint.
- task-specific detail sitting in standing instructions. move it into a skill so it loads only when relevant. the difference between the two is in prompts vs skills.
- summarized references. swap the paragraph version of your pricing sheet or style guide for the real file.
what stays: the handful of rules that are genuinely expensive to get wrong. pricing, compliance language, anything client facing. those are worth the context they cost. the starting structure for what remains is in the claude.md for founders.
why this is worth an afternoon
about 85% of people have access to AI and about 25% use it on real work, per the IBM 2026 Global CEO Study. that 60-point gap is the most expensive problem in business AI right now, and it is mostly not a model problem. it is a setup problem, which is the whole argument of the ai adoption gap.
context engineering is one of the few levers that closes it without adding headcount, tools, or budget. it is a rewrite, not a rebuild. and now it is a rewrite in the direction of less.
what i deleted from my own setup
my setup already ran on most of these shifts, which is less foresight than it sounds. it is what happens once you stop trying to write down every rule. instead of one master prompt covering every content type, i keep narrow skills that trigger only when the task matches: one for screening and replying on x, separate ones for reel scripts, carousels, and email. project-level instructions stay short. tone, formatting, the few things that are non-negotiable.
what i cut after reading the post: a block of formatting rules that existed because an older model kept ignoring them, and three places where the same voice rule was restated inside individual skills. nothing broke. the output did not change. the instructions just got shorter, which means the next thing i add has room.
does any of this need code
no. context engineering originated in developer tools, where it looks like CLAUDE.md files and skill definitions. but the practice is just deciding what the model sees before it answers, and the non-developer equivalents map cleanly: project instructions are your standing rules, skills are the narrow playbooks pulled in on demand, memory is what carries across conversations, and references are the real documents you hand over instead of a summary. none of that requires writing a line of code.
one caveat worth stating plainly, because it is the piece most likely to be over-read: the auto-memory shift is described in the context of claude code replacing hand-written CLAUDE.md files. how far that extends to every chat interface is not something the post claims, so treat your own memory setup as something to check rather than something already handled. the background on that is in context engineering for operators.
the takeaway
the shortest useful summary of anthropic's post: your instructions were written for a model that no longer exists. rules that once prevented a worst case now constrain a model that would have made the right call anyway. go delete the ones an older model needed, keep the few that protect something expensive, and give claude the real document instead of your summary of it.
want the skills, not the trial and error?
the ai builder toolkit is the set of claude skills that do the jobs in this post, already narrow, already scoped, ready to install and run in claude today. no course, no call.
see the toolkitbuilding this out with people doing the same thing is faster than doing it alone. that happens in the ai builders lounge.
or just follow along. new field notes most weeks on x, instagram, and tiktok.