Most people discover skills after their prompts get long. You find yourself pasting the same six paragraphs of context every time you do a particular task, and eventually it occurs to you that this should live somewhere.
That instinct is right, but the conclusion people draw from it is usually too broad. Not everything repeated deserves a skill.
What a skill actually is
A skill is a packaged procedure: instructions, and optionally supporting files, that load when the task matches. Instead of describing your deployment checklist every time, the checklist exists as a thing, and it gets pulled in when it is relevant.
The important property is conditional loading. A skill does not consume context until it is needed, which is the whole reason it beats stuffing the same material into a permanent instruction file.
The line worth drawing
Build a skill when all three of these are true:
- The procedure has steps that are easy to get subtly wrong, and the wrongness is not obvious immediately
- You will run it more than a handful of times
- The correct version lives in your head or in a document, not in the code itself
If it is a one-liner you happen to type often, that is a shell alias, not a skill. If the procedure is already encoded in a script, the better move is to make the script discoverable rather than describe it in prose.
The test is whether a competent new hire would get it wrong without being told. If yes, it is worth a skill. If they would figure it out from the codebase, it is not.
Where people over-engineer
The common failure is building a skill library before having the problem. Someone reads about skills, spends an afternoon writing twelve of them, and then discovers that eleven describe things obvious from context and one is genuinely useful.
Work the other direction. Notice yourself explaining the same thing a third time, then write that one down. A skill library that grew out of real friction is small and every entry earns its place.
Writing one that works
Be concrete about when it applies. A vague description means it loads at the wrong moments or fails to load at the right ones, and both feel like the feature is unreliable when the description is the problem.
Then write the instructions the way you would brief a capable colleague: what the goal is, what the constraints are, and what the specific traps are. Skip the general advice. The value is entirely in the parts that are particular to your situation.