Every team that starts using skills ends up with the same artefact: a folder of SKILL.md files, most of which nobody has opened since the week they were added. The library looks like capability and behaves like context cost.
The fix is not a better folder. It is a maintenance rule, applied to a small number of skills. This page is about that rule, using skills across writing, productivity, and research as examples — SEO Audit, Changelog Writer, Meeting Notes, and RAG Eval.
The short answer
Keep a skill only if it has a trigger you can state, a check you can run in under a minute, and an owner. Everything else is a prompt with extra ceremony — move it to notes and delete the file.
Rule one: the trigger must be statable
A skill that says "use for any task" is not a skill; it is a tone instruction that loads at random. The trigger is the whole discipline: it tells the agent when to load the file and, just as importantly, when not to.
Changelog Writer has a clean trigger — a list of merged pull requests for a release. SEO Audit has another — a set of URLs before a launch. Both statements exclude as much as they include, which is why they work.
Rule two: the check must be cheap
The fourth section of a good SKILL.md is how to verify the output. If that takes an afternoon, nobody runs it, and the skill becomes a machine for producing consistent output that may be consistently wrong.
A changelog check is one line: does every shipped item appear, and is every item something a customer can see? A meeting-notes check is similar: does every action have a named owner, and does every decision have a reason? Both take under a minute.
Rule three: one owner, one purpose
A skill with three owners is a skill nobody updates. The owner is not a manager; it is the person who will notice when the format changes.
The purpose rule is harder: a skill that does twelve things loads twelve times the context and fails at the first one that needs a different structure. Split it or drop it.
Rule four: prune on a schedule
Once a quarter, list the installed skills and write each trigger from memory. Any trigger you cannot recall is a skill that loads unpredictably. Delete it or rewrite the trigger.
The same review catches the second decay mode: a skill whose output has drifted while its rules stayed the same. RAG Eval is a good example of a skill that ages well, because it evaluates a pipeline rather than asserting a format.
Rule five: keep the library small
Each loaded skill competes for context with the actual work. A library of twenty is a signal that the boundaries are unclear, not that the team is sophisticated.
The practical target is five to eight skills for a working team, each tied to a repeating job with a stable structure. Everything else is a prompt, and prompts should live where they are easy to edit.
The failure modes
| Failure | What it looks like | Fix |
|---|---|---|
| Random loading | The skill fires on unrelated tasks | Rewrite the trigger |
| Silent rot | Output follows an old format | Add a check, assign an owner |
| Context bloat | Responses get vague | Prune the library |
| Ceremony | A one-off task has a skill | Delete it, use a prompt |
The first two are the ones that damage trust: the skill appears to work, so nobody looks, and the output drifts one release at a time.
A worked example
Take a team that writes a weekly changelog. The prompt has drifted into six versions and two people use different ones. The skill version states the trigger, the four-section order, the constraint (no marketing adjectives), and the check (every shipped item named with a date).
Six months later the release process changes. The owner of the skill updates the constraint, the check catches the difference, and the changelog stays consistent. Without the owner and the check, the same skill would have kept producing last quarter's format, confidently.
Frequently asked questions
How many skills is too many? More than ten for a single team is usually a sign that some of them are prompts. The number is not the rule; the number of triggers you can state from memory is.
Should skills be versioned in git? Yes — with the code, so the review and the rules travel together. A skill in a shared drive is a skill nobody reviews.
What about vendor skill collections? Read them like code: a collection is a folder, not a quality guarantee. See reviewing a skill and skills.
Last checked: 10 November 2026.
Related: writing a skill, prompt to skill, and skills.
