Delete your skills and re-test: unhobbling Opus 5 with fewer instructions

Step-by-Step Breakdown

1. Understand why the system prompt shrank

   Cherny's framing is that Claude Code as a harness is always changing — every time a new model ships, Anthropic deletes and rewrites large parts of the system prompt and changes the tool set and the tool prompts. Each model is treated as a different personality with different flaws and strengths, so an instruction written for a model three months ago may not transfer at all. For Opus 5 specifically, much of the prompt was correcting for things the model now does unprompted.

2. Duplicate your repo before you delete anything

   Herk's method: make a duplicate of the repo, strip the CLAUDE.md and all skills from the copy, and use it for a while. You are running an A/B, not a migration — the original stays intact so you can compare and roll back.

3. Run the same prompt through both setups and compare outputs

   He gave both versions the same task (turn a YouTube URL into a resource guide). The skills-loaded version produced nine formatted pages with his header image, brand colours and channel links. The stripped version looked messier — but organised the content into ideas with timestamps, which he judged the better output. The instructive part is that the two versions failed and succeeded on different axes: presentation versus structure.

4. Separate routing context from task procedure

   This is the operative distinction. Keep the CLAUDE.md content that tells the agent where things live — business context, where the files are, where the wikis are. That is navigation the model cannot infer. Delete the parts that dictate how to perform a task, because that is where a capable model gets hobbled.

5. Rewrite each surviving skill down to its invariants

   Instead of deleting the resource-guide skill, he rewrites it to say: make the guide however you see fit, but use this image in the header, link the YouTube channel at the top and AIS Plus at the bottom. Brand guidelines, required assets and colour schemes stay; the ten-step procedure goes. A skill becomes a constraint set rather than a recipe.

6. Restructure prompts as goal, guardrails and exit criteria

   Cherny's guidance for modern models: stop writing "do this, then this, then this, in this way." Describe the task, describe the guardrails, describe the exit criteria, then let the model work and come back later. He notes explicitly that this would not have worked six months ago but does today.

7. Make verification the model's job, not yours

   Cherny calls verification the single most important thing people get wrong — the skill now is giving Claude a task that looks slightly too hard, then making it possible for Claude to verify its own work along the way. Herk's practical version: after the standards, state the methods that prove the standard was reached, and require the model to iterate until it has proven it. He appends something close to "I'm not looking for a prototype or a proof of concept — I want something tested and iterated on ten times, fully QA'd, ready to go to market tomorrow."

Gotchas & Caveats

• Don't sweep-delete on someone else's advice, including this. Herk's own strongest caveat: Cherny and Karpathy are speaking as people who design harnesses and train models against massive codebases every day. If your work is research, knowledge work and deliverables rather than shipping software, the advice needs translating. Take guidance from people using AI the way you intend to use it.
• Build-and-orchestrate skills are the best deletion candidates. His read: the skills most likely to be redundant now are the ones telling the model how to build and orchestrate, because the model and harness do that better unaided. Skills carrying brand, format and asset requirements are the ones most likely to still earn their place.
• Re-test your skills on every model release, not on a calendar. The reason the six-month rule exists is that harnesses drift relative to models. A new model landing is the natural trigger to run the whole suite through and check it still feels right.
• A worse-looking output can be the better output. The stripped version lost the formatting and gained the structure. If you judge only on polish you will conclude your skills are working when they may be constraining.
• "The model got worse" may be your instructions, not the model. Herk was falling back to 4.8 for some tasks and assuming Opus 5 had degraded, before considering that his own instruction layer was the thing getting in the way.
• The model can't hit a standard you never defined. If you don't say what good looks like, a mediocre result is a specification failure, not a model failure.

Key Takeaways

• Anthropic deleted over 80% of Claude Code's system prompt for Opus 5, and rewrites prompts and tool definitions on every model release as a matter of routine.
• The official recommendation is to periodically delete your CLAUDE.md, skills and hooks entirely and observe what the model does without them.
• "Unhobbling" and product overhang: today's models can already do things people haven't realised, and overly prescriptive instructions are what prevent it.
• The durable split is routing context (keep — the model can't infer where your files live) versus task procedure (delete — the model likely knows better).
• Rewrite surviving skills as invariants and constraints, not as step-by-step recipes.
• Prompt shape for modern models: goal, guardrails, exit criteria, then let it run — and give it a way to verify its own work, which Cherny names as the most commonly-missed skill.