I built a Claude skill for my team. 80% of it is just 'don't do that'.

I spent two days, between other tasks, turning something I do well into something the rest of the company could do without me. The premise was simple: package the knowledge required to produce a properly branded deliverable into a reusable Claude skill, so anyone on the team could ask for one and get a result they didn't have to fix afterwards.

The premise was simple. The work was not. What looked, on paper, like a one-afternoon job turned into the kind of project that quietly teaches you what AI-assisted work actually is — and what it stubbornly refuses to be.

"A reusable skill is not a clever prompt. It is a contract written in the language of every mistake the model would otherwise make."

The shape of the work

The build ran across two sessions, roughly three to four hours of active conversation, and five distinct iterations. The first version produced something that looked right at a glance and wrong everywhere else. The fifth version produced something a colleague could actually use without me hovering nearby.

Honest split of the time: about 20% was building the initial thing. The remaining 80% was the feedback, fix, re-test loop. Four rounds of structured review surfaced around twenty distinct issues — some cosmetic, some structural, several that only revealed themselves the third or fourth time the same kind of mistake crept back in.

Why it kept breaking

What the skill actually is, in the end

Fourteen rules. Some about structure, some about tone, several about the specific ways the underlying tooling lies to you. None of them are interesting in isolation. Together they encode the difference between an output that needs an hour of cleanup and one that doesn't.

Put another way: the skill is a crystallisation of every mistake I watched the model make, written down so that the next person never has to discover any of them. That is the whole product. The fancy demo is the by-product.

"The interesting work wasn't teaching the AI to do the task. It was teaching it to stop doing the task in all the wrong ways."

What I'd tell anyone building one of these

Don't treat a reusable skill as a writing exercise. Treat it as an operational document that has to survive contact with a colleague who doesn't know what to inspect, doesn't know what to question, and shouldn't have to. The bar isn't "works on a good day". The bar is "works on a Tuesday, in a hurry, for someone who has never seen the inside of it".

Budget for the loop. The first version will look correct and be wrong in ways you can't see until someone else uses it. Build in the rounds of feedback. Build in the rewrites. Build in the moment where the file gets too big and you have to take it apart. That is the work — not the bit you can demo in five minutes.

And keep it small. A skill that does one thing reliably is infinitely more useful than a skill that does five things if you squint. The unglamorous version is the one that gets used.