Fix Degraded Claude Code Output: Trim Skills, Not Add Them
Claude Code output feel worse after a model upgrade? Learn why fewer skills and less rigid instructions often produce better results.
Drafted with Claude from source material, checked by automated verification, and reviewed before release. How we make these.
Why does Claude Code output get worse after a model upgrade?
Claude Code output often degrades after a model upgrade because your old skills, CLAUDE.md rules, and hooks were written to correct behaviors the previous model struggled with. Newer models like Opus often handle those same tasks natively, so old instructions stop helping and start interfering. Anthropic’s own team has said they delete large portions of Claude Code’s system prompt with each new model release for exactly this reason. Your personal configuration usually needs the same kind of pruning.
TL;DR
- Anthropic rewrites Claude Code’s system prompt with nearly every model release, and has removed the majority of it in some cases because newer models no longer need heavy-handed correction.
- Over-specific instructions can hobble a smarter model by forcing it into rigid steps it no longer needs, which produces flatter, more mechanical output.
- Deleting your CLAUDE.md, skills, and hooks temporarily is a legitimate diagnostic step to see whether a newer model performs better without your old scaffolding.
- The best fix is usually rewriting, not deleting, keeping context the model genuinely needs (file locations, brand guidelines, business context) while cutting rigid step-by-step task instructions.
- Giving the model a goal and verification criteria tends to outperform giving it a numbered checklist, especially with more capable models.
- Advice from harness builders and researchers doesn’t automatically transfer to people doing knowledge work, writing, or content creation, so test changes against your own use case before adopting them wholesale.
What did Claude Code’s creator actually say about this?
In a Y Combinator interview, Anthropic’s Boris Cherny (a creator of Claude Code) explained that the tool is constantly changing behind the scenes. Every time a new model ships, the team deletes and rewrites large chunks of the system prompt, changes the toolset, and rewrites the prompts that control those tools. He noted that with a recent Opus release, they removed over 80% of the previous system prompt because the new model simply didn’t need most of the corrective instructions anymore.
Cherny’s advice for regular users was direct: every six months or so, delete your CLAUDE.md file, delete your skills, delete your hooks, and see what the model does on its own. He specifically recommended this for newer Opus models, saying the model likely doesn’t need as much of that old scaffolding as people assume.
This runs against a common assumption that everyone using the same model should get similar results regardless of setup. In practice, the instructions and constraints you built for an older, less capable model can actively work against a newer one.
What is “unhobbling” and why does it matter for prompting?
Unhobbling is a term researchers use for removing constraints that stop a capable model from doing what it’s actually able to do. Cherny connected it to the idea of “product overhang,” where a model already has capabilities that most users haven’t discovered yet because their instructions keep the model boxed into old patterns.
A useful analogy: think about how you’d instruct a 10-year-old versus someone with a decade of professional experience on the same task, like building a slide deck. The 10-year-old needs exact steps: which slides to make, what colors to use, how to format text. The experienced professional needs a goal and some guardrails. Give them the same rigid checklist you gave the 10-year-old, and you get in their way. Modern models are increasingly behaving like the experienced professional. Cherny made this point directly: giving overly specific, step-by-step instructions (“do this, then this, then this”) is a common mistake with current models. He recommended describing the task at a higher level, describing guardrails and exit criteria, and letting the model work before checking back in.
How do you actually test whether your skills are hurting you?
A practical way to test this without guessing:
- Duplicate your setup. Copy your project or repo so you have a version with your existing CLAUDE.md, skills, and hooks intact, and a second version with none of it.
- Run the same prompt on both. Use a task you already know well, something you’ve generated before with your current setup, so you have a baseline to compare against.
- Compare the outputs on substance, not polish. One creator tested this by asking Claude to turn a YouTube video into a resource guide, once with an existing skill and once with nothing. The version with the skill looked more polished (custom header, brand colors, consistent formatting). The version with no skill produced better structured content: it broke the video into clear ideas with timestamps, without being told to.
- Decide what’s actually worth keeping. The output with no skills wasn’t unconditionally better. It was better on structure and reasoning, but missing brand elements and consistent formatting that still needed to be specified somewhere.
The conclusion from that kind of test usually isn’t “delete everything.” It’s that your skills are probably doing two different jobs, one the model can now do on its own, and one that’s genuine business or personal context the model has no way of knowing.
Should you delete your skills or just rewrite them?
For most non-engineering use cases, rewriting beats deleting. Split what your current skills are doing into two categories:
- Context the model can’t infer. Where your files live, your brand colors, your preferred links, your business structure, your formatting standards. This kind of information isn’t something a smarter model magically knows. Keep it.
- Step-by-step task instructions. “First do this, then do this, then format it exactly like this.” This is the part that often becomes a constraint rather than a help once the underlying model gets more capable. This is the part worth cutting or loosening.
The distinction Cherny drew also matters here: his advice comes from someone building agent harnesses and working in large codebases every day. If your daily work is writing, research, or document creation rather than software engineering, the specific balance of what to keep versus cut will look different. Test changes against your own workflow rather than applying advice wholesale from people solving a different problem.
How do you write better goals and verification criteria for Claude Code?
Cherny argued that the real skill now is less about prompt engineering and more about giving the model an appropriately hard task and a way to verify its own work along the way. He called verification the single most important thing people get wrong.
In practice, this means:
- State the goal, not the steps. Describe what “done” looks like instead of prescribing the exact sequence of actions.
- Give explicit success criteria. List the specific things that must be true for the task to count as finished, so the model has a target to check itself against.
- Ask for iteration, not a first draft. Framing a request as “give me something tested and refined, not a prototype” changes the bar the model is working toward.
- Let the model self-check before you do. Building in a verification step (having the model review its own output against your criteria, or use a second pass to catch errors) reduces how much manual review you need to do afterward.
This mirrors how a good manager operates: set the objective, define what good looks like, then get out of the way rather than dictating every step. The thinking can be outsourced to the model. The underlying understanding of what you actually want should not be.
Frequently Asked Questions
Should I delete all my Claude Code skills after a model upgrade?
Not necessarily. Testing with skills removed is a useful diagnostic, but for most non-engineering workflows, rewriting skills to remove rigid step-by-step instructions while keeping essential context (file locations, brand standards, business details) tends to work better than deleting everything.
Why did Anthropic remove most of Claude Code’s system prompt?
Anthropic’s team has said that older system prompt instructions were often correcting for weaknesses in previous models. As models like Opus become more capable, those corrective instructions become unnecessary and can constrain what the model would otherwise do well on its own.
One coffee. One working app.
You bring the idea. Remy manages the project.
What’s the difference between a skill and a hook in Claude Code?
In this context, skills refer to the task-specific instructions or workflows you’ve built for Claude Code to follow, while hooks are automated triggers tied to specific events or actions in your setup. Both are user-configured additions to the base tool, and both are worth re-testing after a model change.
How often should I re-test my Claude Code configuration?
A reasonable cadence is every time a major model upgrade ships, or roughly every few months, since that’s the timeframe Anthropic’s own team referenced for how often they rework Claude Code’s internal prompting.
Does this advice apply to tools other than Claude Code?
The underlying principle, that overly rigid instructions can constrain a more capable model, applies across coding assistants and AI agents generally, not just Claude Code. The specific tuning will vary by tool and model.
