A Claude Code skill is simple to describe: a SKILL.md file with a name, a description, and a body of instructions, optionally shipping with scripts and supporting files. The agent reads only the description until it decides it needs the skill - then it loads the rest. It's an elegant mechanism. And it's precisely because it's elegant that people start turning everything into a skill.
I sit on Bamse's AI Committee, and the question I hear most isn't "how do I make a skill". It's a disguised version of "doesn't this deserve to be a skill?". And most of the time the honest answer is no. A task you did once isn't a procedure. It's an event.
The three criteria
A skill only pays off when the procedure meets all three conditions at once. First: it repeats often. Second: it's non-obvious or easy to get wrong - there's a specific order, a gotcha, a step everyone forgets. Third: it's stable enough to be worth documenting, because a skill that changes every week is debt, not leverage. My Resume Skills Toolkit came straight out of this filter: a procedure that repeats, has typographic gotchas, and barely changes.
"A task you did once isn't a procedure. It's an event - and events don't become documentation."
The bad reasons to create a skill are always the same two. "It felt clever" - you solved something in an ingenious way and want to freeze it. And "I might reuse it someday" - the bet that the future will justify the effort of now. Both ignore that the opposite of a useful skill isn't the absence of one. It's just asking again, in plain language, when you need it.
The description is the most important line
Here's the part almost nobody takes seriously. The agent decides whether to invoke the skill by reading the description - and only the description. The body, the scripts, the supporting files: none of it enters the context until the trigger fires. So a vague description isn't a cosmetic detail. It breaks triggering. The skill exists, it's perfect, and it never gets called because the description doesn't clearly say when it applies.
Before writing the body, write the description. If you can't say in one sentence when the skill should fire and when it should NOT, it isn't a skill yet - it's a note.
The hidden cost
Every skill is surface area you now have to maintain. When the process changes, the skill lies. When its description overlaps with another's, triggering gets ambiguous and the agent picks wrong. Twenty mediocre skills get in the way more than three good ones, because each description competes for attention at decision time. The right question isn't "could this be a skill". It's "am I willing to maintain this for the next six months". If the answer is no, leave it as a plain-language request - it's cheaper and never goes stale.