Should You Delete Your Claude Skills and CLAUDE.md File?

Should You Delete Your Claude Skills and CLAUDE.md File? - THELOSTOFFER.COM

Short answer: if you're an individual using Claude Code, it's worth trying — that's literally the advice from the person who built it. If you're running a multi-agent setup with dozens of automated workflows, the answer gets murkier, and depends on which corner of the AI power-user world you ask.

As of late July 2026, this exact question is spreading fast through AI circles, kicked off by one specific interview and immediately complicated by people building businesses on the opposite advice. Here's where it came from, who's arguing against it, and what to actually do with your own setup.

Where This Actually Started

The advice traces back to Boris Cherny, the engineer who created and now leads Claude Code at Anthropic. In a conversation with Y Combinator at Startup School 2026 — recorded days after Anthropic shipped its Opus 5 model — Cherny told the room something blunt: every six months, delete your CLAUDE.md file, delete your skills, and delete your hooks, then see what the model does without them.

His reasoning isn't about tidiness. It's that models improve fast enough that the instructions you wrote to prop up an older, weaker model often become dead weight on a newer one — context the model no longer needs, quietly eating into every response. Cherny's own team reportedly builds this way: strip the system prompt back to nothing with each release, and only add instructions back for things they actually watch the model get wrong. He's framed it elsewhere as models having "overhang" — untapped capability that scaffolding and over-specified prompts end up suppressing rather than supporting.

That's a meaningfully different claim than "skills are useless." It's closer to: skills have a shelf life tied to model generations, and most people never check whether theirs expired.

CLAUDE.md, Skills, and Hooks — Quick Definitions

If you're newer to Claude Code, the three things Cherny mentions aren't interchangeable, and the advice hits each one differently:

The common thread: all three are ways of telling the model what to do. Cherny's bet is that as models get more capable, telling matters less than trusting — and the only way to know is to delete and observe.

should you delete your calude setup - thelostoffer.com

The Pushback: Not Everyone Is Deleting

Not everyone reacting to this is on board — and the disagreement isn't really about facts, it's about what kind of Claude user you are.

One vocal counter-voice is a creator who goes by James, who runs an education-focused AI product called Campus AI Operating System. His response to Cherny's comments wasn't to delete his setup — it was to double down on structure, just under different names. Instead of skills, he talks about giving Claude "job descriptions": a defined outcome, criteria for what counts as done, guardrails on what needs your approval first, and shared memory the AI can draw on. Instead of one Claude instance, he runs what he calls an "agent org chart" — a lead orchestration agent (he calls his "Dean") that delegates work to specialized AI "employees" across departments, complete with its own audit trail and the ability to flag when a new "hire" is needed.

Here's the detail worth noting if you're evaluating this: James's own pitch says "skills are dead," but he still offers a library of roughly 300 prebuilt skills for download, and the "playbooks" his system runs on — named triggers, ordered stages, one owner per stage — are structurally similar to the skill files he's arguing against. It's less a rejection of Cherny's advice and more a rebrand of the same instinct (give the model structure) dressed up as a business org chart instead of a folder of markdown files.

That's not necessarily wrong — a solo builder running Claude Code for coding tasks is a very different use case than someone trying to run multiple business functions through AI unattended. It just means "skills are dead" and "you need an agent org chart" are both true for someone, depending on what you're actually building.

So What Should You Actually Do?

Rather than picking a side, treat this as two different questions depending on your setup:

If you're an individual using Claude Code for coding or personal tasks:

• Back up your current CLAUDE.md, skills, and hooks somewhere safe
• Delete them and run your normal workflow for a few days
• Note where the model trips up without guidance — those are the only instructions worth re-adding
• Repeat this check with each major model release, not just once

If you're coordinating multiple AI agents across a business function:

• Cherny's advice still applies to any individual skill file that's propping up an old model's weaknesses — audit those the same way
• But some coordination layer (whether you call it an org chart, a playbook, or just a project brief) is still doing real work when multiple agents need to hand off tasks to each other — that's a coordination problem, not a prompting problem, and deleting instructions doesn't solve it
• The test either way: can you explain what you want as an outcome and a definition of "done," instead of a numbered list of steps? If yes, you've probably outgrown the old skill file regardless of which camp you land in

FAQ

Does this only apply to Claude Code, or claude.ai too? 

Cherny's specific comments were about Claude Code and its CLAUDE.md/hooks system. The same logic — old instructions written for an older model may no longer be needed — reasonably extends to Skills used on claude.ai, though that wasn't the direct subject of his comments.

What if I delete everything and performance gets worse? 

Then you've found instructions worth keeping. The point isn't to delete permanently — it's to stop assuming old instructions are still necessary without checking.

Is "product overhang" an official Anthropic term? 

It's the phrase Cherny used to describe the gap between what a model can do and what a product or prompt actually lets it do. It's his framing, not a formal Anthropic product term.

Should teams delete shared skill libraries too? 

The same audit logic applies, but with more caution — a shared skill might be compensating for something a teammate observed that you haven't. Test changes in a copy before removing anything a team depends on.