I Deleted All My Claude Skills... And Claude Got Smarter
Nate Herk breaks down Boris Cherny's YC interview on cutting 80% of Claude Code's system prompt, then tests deleting his own skills to see what actually changes.
Posted
5 days ago
Duration
Format
Reaction
educational
Views
51.2K
1.6K likes
57 · 43
Big Idea
The argument in one line.
Claude Code's creator says most custom instructions builders wrote for older models now get in a newer model's way, so the real skill is deleting stale corrections and giving the agent room to verify its own work.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You maintain a CLAUDE.md, custom skills, or hooks for Claude Code and haven't revisited them since a new model shipped.
You've noticed Claude feels worse after a model update and want a diagnosis instead of a workaround.
You want a concrete framework for writing higher-level prompts with guardrails and verification instead of step-by-step scripts.
SKIP IF…
You're not using Claude Code or a similar agentic coding harness — the advice is specific to that workflow.
You're looking for a hands-on tutorial rather than a strategy discussion.
TL;DR
The full version, fast.
Anthropic's Boris Cherny explains that Claude Code's system prompt gets rewritten with every new model, because instructions written to correct one model's weaknesses can become dead weight once a smarter model no longer needs them. His advice: every six months, delete your CLAUDE.md, skills, and hooks and see what the model does without them. The creator tested this himself, comparing a fully-configured resource-guide output against one with zero custom context, and found the bare version's formatting suffered but its content held up. The bigger shift is in how to prompt: give the model a harder task than feels comfortable, describe the goal and guardrails instead of exact steps, and build in a way for the model to verify its own work before it stops.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Cold open: Nate promises three concrete changes after listening to Claude Code's creator explain why more skills and system prompts can hurt results.
00:23 – 02:05
02 · Anthropic Deleted 80%
YC interview clip: Boris Cherny explains that Claude Code's system prompt, tool set, and tool prompts are rewritten with nearly every model release because each model has different flaws and strengths.
02:05 – 03:49
03 · Delete Your Old Instructions
Boris recommends deleting your CLAUDE.md, skills, and hooks every six months to see what the model does unaided; Nate compares it to giving a veteran the same rigid instructions you'd give a beginner.
03:49 – 05:56
04 · My No-Skills Test
Nate runs the same 'make a resource guide' prompt with full custom context versus none, comparing a polished branded output against a messier but well-organized, timestamped one.
05:56 – 07:18
05 · Don't Blindly Copy Advice
Nate cautions against applying harness-builder advice wholesale, since Anthropic engineers and knowledge workers use Claude very differently.
07:18 – 08:46
06 · Unhobbling the Model
YC clip: Boris introduces 'product overhang' (capability the model already has that nobody has captured yet) and 'un-hobbling' (removing constraints that get in the model's way), plus the advice to hand the model slightly harder tasks.
08:46 – 11:31
07 · Goals and Verification
Boris frames verification as the single most important thing people get wrong; Nate connects it to setting a goal and standard for the model to iterate against, and compares managing agents to managing people.
11:31 – 11:56
08 · Final Thoughts
Nate wraps up, points to the full YC interview, and asks viewers to like the video.
Atomic Insights
Lines worth screenshotting.
Anthropic rewrites Claude Code's system prompt with almost every new model release, deleting instructions that corrected weaknesses the newer model no longer has.
Claude Code's creator recommends deleting your CLAUDE.md, skills, and hooks every six months to check whether the current model still needs them.
Instructions written to correct one model's flaws can become dead weight months later, once a smarter model handles that behavior natively.
The most common mistake with modern coding agents is giving overly specific, step-by-step instructions instead of a goal, guardrails, and an exit condition.
Product overhang means today's models can already do things nobody has built a workflow to capture yet.
Un-hobbling means removing instructions and constraints that corrected for a weakness a newer, more capable model no longer has.
Verification, not prompt engineering, is now framed as the highest-leverage skill: giving the agent a way to check its own work before declaring a task done.
A resource-guide test with zero custom context produced worse formatting but arguably better-organized, timestamped content than the version built with a fully configured skill.
Advice from people deep in harness design, like Anthropic engineers, doesn't automatically transfer to knowledge-work users who aren't building software day to day.
Managing AI agents well resembles managing people: set direction and review results, but don't micromanage every step.
Takeaway
Stop over-specifying; start verifying the work.
PROMPTING SHIFT
Claude Code's creator says most custom instructions get rewritten every model cycle, so the real skill now is deleting stale corrections, prompting at a higher level, and building in verification.
02Anthropic Deleted 80%
Every model is different enough that instructions tuned for one release can stop applying to the next, so Anthropic rewrites Claude Code's system prompt, tool set, and tool prompts with nearly every model.
Opus 5 is intelligent enough that many corrections baked into older system prompts are now unnecessary weight rather than help.
If a model update feels like a downgrade, check the harness and your own custom instructions before blaming the model itself.
03Delete Your Old Instructions
The recommended reset: every six months, delete your CLAUDE.md, delete your skills, delete your hooks, and observe what the model does unaided.
Compare a highly specific instruction set (right for a novice) against a high-level goal (right for an expert) — a strong model performs more like the latter.
Removing constraints on a capable model, called un-hobbling, can unlock output the old instructions were actually suppressing.
04My No-Skills Test
In a real test, the same prompt run with full custom context (skills, CLAUDE.md) produced a polished nine-page guide with branding, a header image, and links.
The same prompt run with zero context produced messier formatting but organized the content into clearer timestamped ideas, judged as arguably better content.
The lesson isn't zero-context forever — it's baking only the necessary specifics, like branding and links, into a lighter skill instead of over-specifying every step.
05Don't Blindly Copy Advice
Advice from people who design harnesses and train models day to day comes from a different context than most knowledge-work users operate in.
Take prompting advice from people who use AI systems the way you do, not just whoever has the most technical authority.
The practical takeaway is reworking instructions to be less specific, not deleting all of them — some brand and structural context is still worth keeping.
06Unhobbling the Model
Product overhang: today's models can already do things nobody has built the workflow to realize yet, independent of any future model release.
Give the model a task slightly harder than what feels comfortable, rather than over-specifying every step — that headroom is where the gains show up.
Describe the task, the guardrails, and the exit criteria, then let the model work instead of scripting each move.
07Goals and Verification
The highest-leverage skill now is less about prompt engineering and more about giving Claude a way to verify its own work along the way.
A useful pattern: set the goal and standard, then explicitly require iteration and self-QA until the standard is met, not just a first pass.
Managing AI agents well mirrors managing people: give direction and review results, but don't micromanage the steps — outsource the thinking, never the understanding.
Glossary
Terms worth knowing.
System prompt
The hidden instructions baked into an AI product, like Claude Code, that shape how the model behaves before any user message is sent.
Harness
The surrounding product, tools, and prompts wrapped around a raw AI model that determine how it takes actions, such as Claude Code itself.
CLAUDE.md
A project-level instructions file Claude Code reads automatically, used to give the model persistent context like business details or file locations.
Skills (Claude Code)
Packaged, reusable sets of instructions for a specific recurring task that Claude Code can invoke, similar to a saved playbook.
Hooks (Claude Code)
Automated triggers that run custom logic at specific points in a Claude Code session, such as before or after a tool call.
Product overhang
Capability a current AI model already has that hasn't been captured into a workflow yet, distinct from waiting on a future, more capable model.
Un-hobbling
Removing instructions or constraints that correct for weaknesses a newer, more capable model no longer has, so they stop holding the model back.
04:05productAIS+ (AI Automation Society membership)
Quotables
Lines you could clip.
02:11
“Every six months delete your CLAUDE.md. Delete your skills. Delete your hooks.”
Direct, quotable rule straight from Claude Code's creator→ TikTok hook↗ Tweet quote
10:15
“The verification, I think, is probably the single most important thing that people do not get right largely.”
Punchy reframe of where the real skill gap is→ IG reel cold open↗ Tweet quote
11:52
“Outsource the thinking, but never outsource the understanding.”
Standalone quotable maxim about managing AI agents→ newsletter pull-quote↗ Tweet quote
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphoranalogy
So I listened to the creator of Claude code explain why Claude has gotten worse and how to actually fix that. And I learned something that sounds really weird, but more skills and more system prompts are probably breaking your system. So I dug deeper into this and I started doing some testing, and I found that there are three super important things that everyone has to be doing right now.
It's super easy to do, and you don't need any technical experience to actually implement this stuff. So I don't wanna waste any time. Let's just get straight into the video.
So let's just start off with some real quick context on what they're actually doing behind the scenes at Anthropic. Let's talk a bit about
the new release. You actually deleted over 80% of the system prompt from Cloud Code.
Yes. Tell us more about that. I think something that a lot of people might not realize is Claude code as a product and as a harness is just always changing.
We're always adding stuff. We're always deleting stuff. Every time that a new model comes out, we delete a bunch of the system prompt, change a bunch of the system prompt.
We change the set of tools all the time. We change the prompts for the tools all the time. And the reason is every model is very different.
So something that you did for one model maybe three months ago, it just might not translate at all to the next model. And so one thing about Opus five is it's just really intelligent. And a lot of the stuff in the system prompt was correcting for these behaviors that the model should have known, but it didn't.
Now Opus five just does it. So it's interesting. It makes you think a little bit, but I just wanted to sort of lay the foundation of they're doing that adanthropic.
They are treating each different model as like a different completely different personality, different flaws, different strengths, and different ways that you should prompt it. And so whenever a new model drops, one of the things that I tell you guys is like, hey. Run you this model through your skills.
Make sure they all still work. Make sure they all still feel good. And for some reason with Opus five, it's just felt degraded to the point where I'm actually going back to 4.8 every once in a while when I need to do something and I'm just getting better results.
But I never really thought about, maybe if I just got rid of some of my instructions and got out of the model's way, it is actually just more intelligent now and it could handle those things. So take a look at this next clip.
Yeah. And and for people that aren't building agentic products but you're using Cloud Code, every six months, delete your Cloud MD.
Delete your skills. Delete your hooks. See what the model does, and it might surprise you.
And actually for Opus five, this is something we really do recommend is just try deleting all of these things because the model might really just not need all those instructions that you needed for past models.
So when you think about that for a sec,
I feel like that almost sounds counterintuitive because what we've been told is, hey. You know, if everyone has access to the same model or some this is something that I say a lot, then wouldn't everybody be getting the same results? And to an extent, that is very true.
But if Boris is basically saying, hey, remove your skills, remove your own persistent prompts, and just see what's possible, it's a different way to think about it. Because the the the immediate thing that I think about is like, Let's say that I was teaching a 10 year old, a college student, and someone that's been in the workforce for ten years how to do something, how to do something like create a slide deck.
I would probably give the 10 year old the most specific instructions. I would say, hey.
Here's exactly what you should be looking for. Here are the 10 slides to make. Here's what the title should look like.
Here's the color. Here's the way that the text should be formatted. I would be super specific, and I basically wouldn't give that 10 year old any freedom really to just kind of go experiment because if it's a high stakes thing, we wanna just steer it.
But as you work your way up the chain in, I guess, like intelligence and experience, what if you gave that same instruction set to the person who's been working for ten years and has made hundreds of slide decks? You're gonna get in their way.
They're not gonna be able to actually use their subject matter expertise and their intelligence to put their own spin on it. And so I'm not saying that it's always the case, but I think that there is an element of like removing some of the some of the like kind of instructions and constraints on a model. They call this unhobbling the model, which I'll play a clip from in just a minute here.
But take a look at this example I ran. So after I watched this interview, I made a duplicate of my repo and I took away the CloudMD and I took away all my skills, and I just started using it a little bit to see how it worked. And it was okay, but what my gut is telling me about that is when we're doing something like we have, you know, an AI operating system and we have the Cloud MD which is kind of routing around to, hey, here is Nate's business context, here are where all these files live, here are where the wikis live, that's important.
We still need that context of, hey, mister Cloud Code, here's where you find your things. But when it comes to actual tasks, maybe you just get out of the way a little bit and that's where your skills aren't as important or your skills are changed. And so what I mean by this is take a look.
Here's an output I ran where I took this YouTube video, this interview that we're watching. I gave that URL to Claude and said, hey, make me a YouTube resource guide, like the resource guides that I make for you guys when I have other videos. And so what this did is it broke it down.
Right? It it created a nine page resource guide. It's formatted nicely.
It has like these colors. It has like these little blocks, and it has my also like my header. Right?
It's got the header image. It's got my YouTube channel links right here. At the bottom, it links to AIS plus.
So those are things that are like very specific. So those are things that it's like my preferences and my styles. Now look at this version.
This is one on a fresh session where I gave it basically the same prompts, it had no skills or no context to work from. And here's what it created. Obviously, doesn't look as good.
Right? It just looks a bit messier. It doesn't have nice formatting.
There's no header. But I think that this is a better output because I didn't tell it specifically, hey for a resource guide, do this this and this.
Here's how you break it down. This actually broke this down into ideas which I thought was really nice, and each idea has a timestamp. So here we have prompts are disposable, here we have rebuild from observation.
All of these main ideas that it covers, we have timestamps. So arguably, I like the content of this version better, which had no skills, no Cloud NMD. But what I would do is I would bake this into a skill and say, hey, by the way, make the resource guide however you want, however you see fit.
But what I want you to do is take this image and put it in the header and link to my YouTube channel at the top and link to AIS plus at the bottom. So those are the areas where I think it's less in my mind about deleting all your skills. It's more about really thinking about them and maybe making versions of them that aren't as specific.
And real quick, as I'm editing this video, there's one other thing I wanted to throw out there that I think is super important to think about, which is you can't just take advice you see from Boris Churney or from some other YouTuber or from me or from someone in the community and just blanket statement apply it to your work.
It just doesn't work like that because what my gut's telling me is a lot of this advice that Boris is gonna tell you or that you might see Anjay Carpathi tweet about, a lot of their advice is coming from the perspective of someone who's, like, in the weeds, designing harnesses, working on massive code bases every day, training models.
That's not what I do. I don't know if that's what you do or not, but you should probably be taking advice from people who are using the AI systems the same way you want to. For me, that's generally bunch of research, knowledge work, creating documents, creating deliverables, but not as much like building software.
That's not what I'm doing on the day to day. So I just wanted to throw that out there. I think that Boris has some really good advice here, but the reason why I didn't actually go out and sweep delete all of my stuff is because based on my findings and my testings, that wouldn't be as valuable to me as just kind of like reworking them.
I think people that are building products and software have like these all of these skills to like build and to orchestrate, and maybe that's where those skills should be completely deleted because the model and the harness just does that better now. But as you saw from this demo, like, I still need the skills to say, hey.
You're gonna grab this image. You're gonna put that there. Um, you're gonna use these color schemes because that's like our brand guidelines.
That sort of stuff is still important context for my systems, my knowledge work. So just something important to keep in mind. And Boris seems to completely agree.
Let me show you guys this next clip. Yeah. So hobbling is this idea in research that the model is doing something and you're just getting in the way.
There there's this kind of like way of thinking about it that I really like. It's very useful when you're building products, and it it it's called product overhang.
And the the idea is the model is able to do all sorts of things with today's models, not a future model, but today's model, that we have not yet realized.
And there are so many capabilities the model has like this that people are not aware of. So there's a couple things that I would think about. One is you should give the model slightly harder tasks than what you think you can do.
I think a a really common mistake that I see is people are using quad code, they're using quad in, they they just give it, like, way overly specific instructions. They're like, I want you to do this, but I want you to do it in this way, this way, this way. You must do, like, one, then two, then three, then four.
And for modern models, that's actually really not the way to do it. You wanna go a little bit higher level. You wanna describe the task.
You wanna describe the guardrails. You wanna describe, like, the exit criteria, and then just go with the model cook and come back in a little bit.
And I think it'll it'll surprise you. Like and again, like, this is just not something that would have worked six months ago, but it does work today. So if you weren't convinced when I said that earlier, hopefully, you're convinced now that you've heard Boris Churney say that.
And I think that there's so many things that go into this. Right? There's obviously the balance of using your Claude.
M d in a way that doesn't hobble the model. Same thing with your skills. And then there's also the balance of actually getting an output that you like because I think a lot of us get frustrated when we ask Claude to do something, it comes back and the output's just very mediocre, but maybe that was on you.
Maybe it was your job to say, hey. Here is what good looks like because if it doesn't know what good looks like, how does it actually create something that's good? So like Boris said, you give it a high level goal, you set the standard and say basically, don't stop until you're done, until you've hit the standard.
So when you think of setting a slash goal when you're using these AI agents, you're not just saying, hey, here's what good looks like, you're also saying, here are x y and z things that you do in order to prove that this has been reached. And you keep iterating on that until you've actually proven it. You verify yourself so that I don't have to verify.
For example, something that I've been throwing at the end of my slash goals after I've given it all the standards and the verification methods, I basically say like, I'm not looking for a prototype or a proof of concept. I'm looking for you to give me something that has been tested and iterated on 10 times and has been fully QA'd and that's ready to go to market tomorrow.
That makes it a little bit more emotional. And sometimes when I prompt things with emotion, seems to do better. But let's take a look at what Boris said about verification.
I I think the skill nowadays
is less about prompt engineering and more about figuring out how do you give Quad a hard task that seems a little bit too hard.
And then how do you make it possible for Claude to verify its work along the way? And the verification, I think, is probably the single most important thing that people do not get right largely.
It's really, really interesting to see how the creator of Cloud Code is thinking about this because the more that I get into this space and the more that I talk to people that are starting to get into this space, the more I realize that the skills that are transferring over here it obviously doesn't matter. They're tool agnostic.
If you wanna use Cloud Code, Hermes, Agent Codec, whatever is. The tools that are the skills that really are important is managing AI agents. And when I say managing, I mean a similar way to when you manage people.
Now I haven't been managing people for very long, right? But what I do know is that good managers don't just micromanage.
Right? They're not saying this is what you should do. This is how you do it.
Go do it. They get out of their people's way. They check-in with them.
They review. They have judgment. They have taste, but they also let those people use their brains.
Like they were hired for a reason, and so essentially you should be thinking about all these agents and all these sessions that you're spinning up, you're using them for a reason. Outsource the thinking to them. Let them think and let them come up with ideas, but give them an ability to have other agents play devil's advocate.
Give them an ability to check their own work and verify. Outsource some of the thinking, but never outsource the understanding. At the end of the day, you're still like the founder of these agents and you are driving the vision, but they're able to help you so much.
So anyways, I could talk about this all day. I think that this is super interesting. If you guys wanna check out this interview, it was like a thirty five minute interview on the Y Combinator YouTube channel.
I will leave a link to it in the description as well. These are just some of the key highlights that I wanted to pull out and break down, and let me know if you guys enjoy this type of video, if you enjoy this type of breakdown. And hopefully you found it valuable, you learned something new, and there's something that you wanna try.
If you did, please give it a like. It helps me out a ton. And as always, I appreciate you guys making it to the end of the video, and I'll see you all in the next one.
The Hook
The bait, then the rug-pull.
Claude Code's own creator says he deletes 80% of the system prompt with every new model. Nate Herk takes that claim, tests it on his own setup, and comes back with three changes worth making before you touch another CLAUDE.md file.
Frameworks
Named ideas worth stealing.
00:00list
Three Changes for Post-Opus-5 Prompting
Simplify old instructions instead of deleting everything
Prompt at a higher level (goal + guardrails + exit criteria)
Give the agent a way to verify its own work
Nate's own synthesis after watching Boris Cherny's interview, adapted for knowledge-work use rather than software-building.
Steal forauditing a CLAUDE.md or skills library after a model upgrade
07:28concept
Product Overhang
The gap between what current models can already do and what builders have actually wired up into a workflow — capability sitting unused, independent of any future model release.
Steal fordeciding when to raise the difficulty of a task handed to an agent
07:24concept
Un-hobbling
Removing instructions and constraints that were compensating for a weaker model's flaws, which can throttle a newer, more capable model instead of helping it.
Steal fordeciding what to cut from an existing prompt library
CTA Breakdown
How they asked for the click.
VERBAL ASK
11:40subscribe
“If you did, please give it a like. It helps me out a ton.”
Soft engagement ask at the very end; no hard product pitch spoken in the video itself — the community/sponsor links live only in the description.
A hands-on tour of a synced, phone-controllable AI agent team — agent computers, teachable skills, scheduled routines, event triggers, and where it stops making sense versus Claude Code or Codex.
00:09
00:21
00:36
00:49
00:58
01:07
01:16
01:26
01:33
01:42
01:51
02:09
02:18
02:28
02:36
02:45
02:54
03:03
03:12
03:21
03:30
03:39
03:57
04:06
04:15
04:24
04:32
04:41
04:50
04:59
05:08
05:17
05:26
05:35
05:44
05:54
06:11
06:20
06:29
06:38
06:47
06:56
07:05
07:17
07:31
07:40
07:49
07:57
08:05
08:16
08:25
08:34
08:52
09:01
09:10
09:19
09:28
09:37
09:46
09:59
10:04
10:13
10:21
10:30
10:39
10:48
10:57
11:06
11:15
11:24
11:33
11:51
Video of the Day30:53
09:59
14:35
Video of the Day1:08:12
20:32
16:27