The test for a skill is simple: what does it add that the model didn't already know? Ours answer with sources, with scripts for anything that has to come out the same twice, and with lessons from the projects they've run on. A skill that only restates the model's training isn't harmless. It narrows the model to the author's thinner version of what it already knew.
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, and nothing a model wouldn't have produced unprompted. They read as generated, not earned.
A skill that restates what the model already knows tells it to ignore its training and use only what you've written.
A model carries a large 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 what it adds, and a skill that adds nothing still costs the model's attention.
What ours do instead
- Source first, opinion second. A skill cites the primary standard, not 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 nineteen years of building this kind of thing.
- 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. There's more on this below.
- 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. Nearly every skill ships an evaluation set, and the few that don't are on the list. 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 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: people and agents learn and grow together.
More than just markdown
A skill that is only instructions can only ever be a better prompt. Around ten of ours ship code, some thirty scripts between them, plus two packages we publish to npm and drive from the skill that owns them. That's the line between a page of advice and something you can hold to a result.
The split is deliberate. Anything two runs must agree on is a script, because a model asked to measure the same page twice will phrase the answer differently each time, and a number that moves isn't a measurement. Everything that needs a view stays with the model, because a finding worth reading is phrased for the person reading it.
The audit family is the clearest case. Its scripts sample pages, drive Lighthouse, score the results and write a JSON artifact two runs must agree on byte for byte, and nothing in them reads a page and forms an opinion. The checks map a scanner's output onto the standard: axe results onto WCAG's four principles, Lighthouse timings onto the Core Web Vitals, gitleaks and Semgrep onto the artifact. Without a browser, the accessibility audit doesn't run at all, instead of guessing a score.
The tokens skill is the same argument from the other end. Colour is generated from a single brand seed by @designtools/tokens, a package we publish; the type and spacing scales are written by hand. The skill holds the contract between the two, so a re-seeded palette can't silently break a scale.
Every skill that ships code says on its own page what that code settles, so nobody has to open a folder to find out which skills are more than a page of instructions.
Anyone can make one
The same rules hold for skills made outside engineering, and we built a skill to apply them. mxs-skill-builder helps anyone at the studio make a new one. It starts by working out whether the thing should be a skill at all, then asks the questions that matter and agrees a one-page spec, then builds and tests the skill from that spec. Where a skill pulls from several of our systems, it works through the connectors the organisation already has, and it never builds a connector or holds a credential.
It sits alongside the rest of the studio set (copywriting, slides, our shared knowledge, and the learning loop), which apply the same rules to work that isn't software.
How they ship
The skills ship as two plugins: the delivery suite for making products, and the studio set for everything else. Each is versioned, checked by the official validator before release, and distributed through our organisation's plugin marketplace, so they're already on every studio Claude account. A change to a skill reaches people only when its plugin is released, which keeps what everyone is running known and reviewable.
We've watched this happen on client work and on this site. We haven't run it as a controlled comparison, and we won't put a number on something we haven't measured.