I once asked, while using /review: how is this different from just typing “review my code”? The answer came back:
“Honestly? It’s a well-made prompt.”
When I first opened a skill file, it didn’t click. It’s a .md file. CLAUDE.md is .md, commands are .md, skills are .md. I expected some special internal mechanism, but the essence is just a structured prompt template.
And yet “it’s just a prompt” undersells it — the more I used skills, the more they turned out to be the core building block for designing agent behavior. At one point in that conversation I asked back:
“So it’s ‘when doing this kind of task, handle it this way’?”
“Exactly. That’s the essence of a skill.”
A skill has exactly two parts. The when (the description): “when this kind of task comes in.” The how (the body): “handle it like this.” Four properties fall out of that simple structure, and this post walks through skills using those four.
One: it can constrain the agent’s behavior
I used to put every rule I had into CLAUDE.md. It’s always loaded, so it’ll always be followed — that was the theory. In practice, the longer a conversation ran, the more certain rules got ignored. The “present but forgotten” pattern. CLAUDE.md is re-read with every message, but as the file grows, the model’s attention on any individual rule dilutes. It’s buried far away, competing with everything else.
Skills differ exactly here. The body gets injected fresh, right next to the task, at the moment it triggers. No competition — it surfaces precisely when needed. So for the “forgets in long sessions” failure mode, skills are clearly stronger. Pin a procedure the agent must follow for a given task into a skill, and its behavior during that task is bound to that procedure.
It’s not free, though. The nature of the misses changes: from CLAUDE.md’s “applied inconsistently” to the skill’s “if triggering fails, nothing shows up at all.” If the description doesn’t match the task, that case is a 100% miss. A convention was at least always present — so a skill with a weak description can actually be worse than a convention.
Two: it’s reusable
When I asked about the right time to create a skill, the signal was singular: the friction of “wait, I’m typing the same explanation to Claude again.” The moment you feel that, it’s time. If you never feel it, don’t bother.
That’s precisely where /review earns its keep. If you could write a high-quality review prompt yourself and type it identically every time, there’d be almost no difference. But typed by hand, items get dropped here and there. A skill lets you use that well-crafted prompt as a single word — consistently, in version control. Make the file once and the same checklist runs every time, lives in git, and once you fix it, it runs fixed from then on.
Three: it invokes itself when needed
Commands are .md, skills are .md — confusing — but the key difference is who triggers them. A command fires only when I type /name myself. Manual, predictable. A skill fires automatically when Claude judges it fits the task at hand. It gets used without me calling it.
That’s why the description is more than half the game for a skill. A command doesn’t need a when — I invoke it myself. A skill needs Claude to match “this situation applies” on its own. If the trigger condition is fuzzy, it won’t fire when you need it, or it barges in at odd moments.
Write “stock-related” and triggering gets erratic. Write “when writing or modifying P&L calculations or profit/loss logic” and it surfaces exactly then. How sharply you write the when determines the skill’s quality.
Four: it’s easy to make
Say “make me one” and it genuinely does. A skill is ultimately a markdown file, so prompting Claude Code produces everything from the frontmatter to the body procedure.
But being generated and working right are separate things. It drafts the how well enough — the “when should this fire” part needs your exact intent. So the good pattern is: take the draft, then review and sharpen just the when. As generation becomes nearly free, the bottleneck moves from generation to specification and verification. When this skill should surface, and whether it actually does — that’s still yours to define and confirm.
Putting it together
A skill pins “when this task comes in (when), handle it this way (how)” into a single file. Traditional code expresses logic in a language machines read; a skill expresses logic in natural language an LLM reads. Different execution engine, same act of describing conditions and procedures. Hence the four properties: it constrains behavior, it’s reusable, it surfaces automatically when needed, and it’s easy to make.
If your CLAUDE.md feels overloaded, pick the one rule that slips most often and split it out into a skill. Write the when concretely — “P&L calculations” — then run the same task a few times and check that it fires. Just remember: with a weak description, it can end up worse than the convention was.