Published: 2026-08-01
Analysis & perspective

Why bad Claude skills burn your context — and how to fix them

Chapters / key moments (click to jump — plays here on the page)

Nate B Jones argues that most people install skills backwards — collecting them "like Pokémon cards" without knowing what fires when. His central mechanical point: an agent does not hold a skill in its head. It reads only the skill's name and description up front, and loads the body of the file only once a job matches that description. That makes the description the whole trigger, and it explains the two failure modes he sees most: a vague description means the skill never fires, and a broad one means it fires constantly on jobs it does not belong to, eating context other work needs. This is a mental-model video — no commands, configs, or terminal work are shown.

Source video

"Bad Claude Skills Are Burning Your Context. Here's How I Fix Them." by Nate B Jones — Watch on YouTube →

Note: the second half of the video promotes the creator's own paid skill-builder and skill-audit skills. The principles below stand on their own — you do not need to buy anything to apply them.

Key Takeaways

Skills load progressively, not all at once. The agent sees a skill's name and description on every turn, but pulls in the full SKILL.md body only when a job matches. That is why skills beat pasting a giant prompt into every chat — and why the description carries all the weight.
A vague description is a skill that never runs. If the agent cannot tell from the description when the skill applies, it will not reach for it, no matter how good the instructions inside are.
A broad description is worse than a narrow one. Overly general descriptions make the skill surface in unrelated jobs, where it adds nothing and consumes context the actual task needed.
Installation succeeding is not the same as the skill working. Jones describes grabbing well-reviewed skills that landed correctly in the file system and still changed nothing about the output — a bloated file full of every edge case leaves the agent navigating a manual instead of doing the work.
Skills from random repos are untrusted input. Pulling skills off GitHub because they sound useful means handing an agent instructions you have not read. Jones's rule is to know the source, and to open the file before letting an agent act on it. There is no app-store review layer here — no signing, no certificate, no vetting.
Write for two audiences at once. Skills are executed by agents and audited by humans. If you cannot read your own SKILL.md, you cannot tell what business judgment you delegated — and that is the part worth checking.
Past ~20 skills, subtraction beats addition. Overlapping skills conflict, and the agent averages across them, dulling results. Jones names the trap directly: output gets worse, you add another skill to fix it, and that makes it worse again. Audit and resolve conflicts before adding more.

Go deeper on skills

The description-quality point maps directly onto our skill-writing guidance — a skill's front matter is the part that decides whether it ever runs:

Writing your own OpenClaw skills — structure, front matter, and the safety warning
Claude Cowork skills guide
Skills database — what is out there, and how to review it before installing
Security center — why untrusted skill files are an instruction-injection surface

What you can actually set up from this

Extracted from the video's own transcript — the specifics the original summary left out.

Reproducible steps

How a skill loads, as the speaker describes it
A skill is a directory with a skill markdown file (SKILL.md) plus supporting material. The agent first sees only the name and description; the full instructions load when the task matches the description, and supporting files load only when the instructions point to them. That is why skills beat pasting a giant prompt into every chat.
Three ways a skill fails
A vague description means the agent never knows when to use it. A broad description makes it fire on jobs where it does not belong and clutters the context window. A huge main file stuffed with every edge case makes the agent spend its attention navigating a manual instead of doing the work. A skill can install successfully and still be unusable.
Check the source and the purpose before installing
Grabbing skills from random GitHub repos like collectible cards means unknown (possibly malicious) instructions and unknown interactions with the skills you already have. Know why you want each one.
Write for two readers
Skills are written for agents to use and for humans to read. You should be able to open the file and understand what judgment you handed the agent. Put the important trigger information up front in the front matter, keep it short, and give a few examples and counter-examples.
Fork rather than hoard
His example: Matt Pocock's "Grill Me" skill (a March 19 version had four body sentences) questions you until a plan is thought through. Nate Herk's fork kept the interview loop but made the resulting context persistent and inspectable. The speaker's rule of thumb: perhaps 10 to 20 percent of the time you can use a trusted skill as is; 80 percent of the time you want to modify one or write your own.
Audit once you have many
With 25 or more skills, conflicts between them average out the AI's behaviour, so adding a skill to fix a problem can make it worse. He offers an "advanced builder" audit skill and a skill-builder skill (both linked in the video description, not shown in the transcript).

Gotchas

Skills have no app-store-style signing or certification, so there is no guarantee of how a downloaded one behaves.
He suggests dictating what you want in your own voice, then turning the transcript into the skill.
The loading behaviour described matches what Anthropic's engineering blog says about skills, but the speaker is describing ChatGPT, Codex and Claude generally; check each product's own documentation.
Promotes his own skill-builder and audit skills; their contents are not in the transcript.