A good skill adds what the model does not already know, and nothing else. It sources the established base before it states our opinion, it splits the work two runs must agree on from the work that needs judgement, and it gets better every time it runs. A skill that restates the model's training is not neutral. It narrows the model to the author's paraphrase, and a shallow one does more harm than no skill at all.
A shallow skill constrains more than it helps
Most published skills are a page of confident generalities. We sampled two from a collection doing the rounds, a conversion-rate specialist and a chief technology officer: 64 lines and 223, no source cited, no script or reference file shipped, and nothing a model would not have produced unprompted. They read as generated rather than earned.
The model already knows how to do all of this. When you put a skill like that into the mix you are saying: ignore your training and use only what I am telling you.
Andrew Flett
A model carries a vast and largely sound account of how conversion, architecture or accessibility work. A vague skill swaps that account for a thinner one, and the output gets worse while looking more authoritative. The value of a skill is its delta, and a skill with no delta is a tax.
What ours do instead
- Source first, opinion second. A skill cites the primary standard rather than a restatement of it, so the audit skills quote W3C and web.dev directly and age with them. Established skills are adopted as thin attributed extracts. Our opinion goes on top, and it comes from twenty-five years of building this kind of thing, not from a prompt.
- Deterministic and probabilistic, split on purpose. Scripts do what two runs must agree on: fetch, measure, parse, score. The model does what a good person would phrase differently for a different reader. The tokens skill is the clearest case: colour is generated by a package from a brand seed, the type and spacing scales are authored, and the skill exists to hold the contract between the two.
- A purpose, never a tool. Each skill reads which tool fills its slot from the project's stack manifest, so a client's framework, tracker and pipeline stay theirs.
- Tested by behaviour. Thirty-three of the thirty-five skills ship an evaluation set, the two that do not are on the list, and a description is judged by whether a fresh session fires on it, not by how it reads.
- They compound. The learning skill captures what went wrong or surprised us, names where the lesson belongs, and a human sweep folds it back into the skill that owns it. It has run on our client work and on this site, whose build alone produced seven findings about the suite that reading the skills would never have surfaced. The loop is a principle of its own: humans and machines learn and grow together.
Where this is unsure
Our skills are long, and the baseline says concise. The resolution is that concise means adding only what the model lacks, and a contract with thirty conventions in it is not padding. Even so, one skill is over the recommended body length, and that is a debt rather than a position.
The compounding loop is only as good as the sweep. Routing a lesson is not applying it, and a note nobody sweeps went nowhere. We have also not measured the with-and-without difference in a controlled way. The claim rests on builds we have watched, which is enough to hold the position and not enough to put a number on it.