The format I write these posts in lives in a single markdown file — rules for voice, for HTML fragments, for slugs, for keeping the English version equivalent rather than a literal translation. It is, in effect, a skill. Just hand-written, and never once verified. Does it work? No idea. When something comes out wrong, I add another sentence of instruction and hope. That is roughly how most people write instructions for a model: by feel, with nothing measured.

skill-creator is the skill that makes skills. It installs as a plugin in Claude Code — /plugin install skill-creator@claude-plugins-official, then /reload-plugins — and offers four modes: create, eval, improve, benchmark. It sounds like a writing assistant. It isn't. What it actually brings is a loop, not a template.

The creation part is the predictable one. A short interview — what the skill should enable, what phrasings should trigger it, what the output looks like, where the edges are — and out comes a folder with a SKILL.md: YAML frontmatter carrying name and description, a markdown body, and optionally scripts/, references/, assets/. Loading happens on three levels: name and description sit in context permanently, the body enters only when the skill triggers, and the bundled resources only when they're actually needed. Which is why the body stays under roughly 500 lines and everything else moves into a reference file the model reads on demand. (Where CLAUDE.md ends and a skill begins — I've written about that separately.)

The real work starts afterwards. skill-creator drafts two or three realistic test prompts and runs each of them twice: once with the skill, once without. The second run is the baseline. A control group. Without it there's no way to tell whether the skill helped or whether the model would have managed anyway — and that's the difference between engineering and superstition. The outputs land in an HTML viewer where you read them side by side and leave notes, and those notes feed the next iteration. Write, run, look, fix — a loop, not a prompt.

The most underrated field is description. Claude only ever sees the name and the description, and decides from those alone whether to open the skill at all. The description is the cue — the signal that makes the situation recognizable. A skill that never triggers is a skill that doesn't exist, and the model tends to under-trigger rather than over-trigger. So the description has to be a little pushy and spell out the situations where it belongs. There's a separate loop for exactly this: around twenty queries, half of which should trigger the skill and half of which are deliberate near-misses; a 60/40 train/test split, each query run three times, and the winning description chosen by its score on the held-out test set rather than on train. Ordinary ML hygiene, applied to a paragraph of prose.

On claude.ai the loop is clipped — no subagents, so no baseline and no benchmark; the test cases get run by hand, inside the conversation. The full version lives in Claude Code (docs here). Even the clipped version is more than what I used to do, which was nothing.

The most useful thing, though, wasn't in the scripts. It was in the style guidance. skill-creator tells you to explain why rather than pile up MUSTs; a run of capital letters is a yellow flag. That rang familiar. A hard rule buys literal compliance and switches off thinking — in a model and in a person alike. The instruction that explains its intent is the one that survives the case you failed to anticipate.

A skill isn't a document. It's a hypothesis — and now there's something to test it with.