The most common misunderstanding about agent skills is that they add capability. They do not. A skill is markdown the model reads before acting; it changes behaviour and tone, not reach.
What the split looks like
Across 35 skills in the directory, 13 are coding workflows, 10 are productivity, 3 research, 3 writing, and the rest are media or specialty. Almost all of them are instruction packs. The ones that look like capability — a design system search, a security audit pipeline — are still instructions wrapping tools that already exist.
That is why a skill cannot make an agent able to query your database. If the agent cannot reach the thing, the fix is a tool, not a longer instruction file.
What a good skill looks like
Four sections: when it applies, what to do, what not to do, and how to verify. We score entries on the last two, because they are the ones that change output instead of changing vibe.
**What not to do** is the prohibition. 'Do not comment on formatting' is more effective than 'focus on correctness', and every useful skill we have read contains an explicit constraint of that shape.
**How to verify** is the section almost everyone omits, and its absence is why a skill can produce confident wrong work: the agent has no instruction to check anything, so it produces output that looks finished.
Why the ecosystem floods with weak skills
Because a skill is cheap to publish and its quality is invisible until you use it. The README can promise anything; the file is 40 lines of instructions and no tests. Compare with a package: at least `npm install` fails loudly if it is broken.
That asymmetry is why the `bestFor` / `notFor` field on each skill entry carries more weight than the description. A skill that never says when it does not apply will fire on everything, and firing on everything is the same as doing nothing.