The skill ecosystem has the same shape as the app store: thousands of entries, most of them a paragraph of adjectives. Installing indiscriminately does not make an agent better, it makes the model average between conflicting instructions.
The five-minute test
Open the SKILL.md and look for four things, in this order.
**Does it name a trigger?** A skill that does not say when it applies will apply to everything, which is the same as applying to nothing. "Use when reviewing a diff before merge" is a trigger; "use for code tasks" is noise.
**Does it contain a prohibition?** Skills that only say what to do change tone. Skills that say what not to do change output. If there is no "do not" anywhere in the file, expect a mood shift rather than a behaviour shift.
**Does it have a verification step?** How does the agent — or you — know the result is correct? A skill without this trains confident wrong work.
**Does it fit in the harness?** Some skills assume a specific client, a specific tool, or a specific directory layout. Read the install section: if it requires a tool you do not have, the instructions will fail silently.
What to do with a skill that passes
Install one at a time. Run the same task twice, with and without it, and compare the outputs. If they are indistinguishable, remove it — a skill that changes nothing is pure context cost.
Then try a task the skill should decline. A skill that fires on everything is a liability: it will apply a review checklist to a deployment, and the agent will follow it.
What to do with one that fails
Most can be fixed in five minutes with an edit: add a trigger, add a prohibition, add a check. That is often better than searching for another skill, because you now understand what it was missing.
Browse the skill directory — every entry carries a `bestFor` and a `notFor`, which is that five-minute test done once and written down.