A skill nobody reaches for is dead weight

Same task. Two ways of asking. Two very different results. That was the moment it clicked for me, and it has bugged me ever since.

I gave my AI coding agent something to do, got back work that was fine but not good, rephrased the request, and got back exactly what I wanted. Nothing else changed. Same model, same repo, same afternoon. The only variable was me, and how I happened to frame it.

The model was fine. I was the variable.

That is an uncomfortable thing to admit, because it means the quality of my output was riding on whether I remembered the right way to ask on any given day. On a good day I pointed the agent at the failure log first, told it to reproduce before fixing, reminded it of the pattern we already use. On a distracted day I forgot half of that and got half the result.

The knowledge of how to do the work well existed. It just lived in my head, and only when I was paying attention. Nowhere I could reuse it. Nowhere anyone else could either.

Now picture a whole team doing that

For one person this is just friction you learn to live with. Scale it to a team and it turns into something worse. Everyone drives the agent a little differently. One person knows the trick that gets clean results. Another doesn't. One remembers the generator exists and another hand-writes the thing it would have scaffolded correctly.

The output stops being a function of the tool and starts being a function of who is holding the keyboard. That is the real cost, and it hides well, because on any given day the work looks fine. It is the variance that gets you, not the average.

So I wrote the good version down

I started capturing the ways of working that actually produced good results, as small reusable skills the agent could pick up on its own. Not a wiki page nobody opens. Not one giant instructions file that scrolls past the point of being read. Just focused playbooks, each describing how one kind of task should go. How to chase down a hard bug. How to build something test-first. How to turn a rough idea into a proper spec before a line of code gets written.

The part that mattered most was making them easy to reach for. I added a single front door, a router, so nobody has to memorize a catalog. You describe what you are about to do and it points you at the right playbook. All of it is opt-in and made of plain text, which sounds like a small detail but isn't. When a playbook is wrong, fixing it is a one-line change, not a debate.

Matt Pocock's thinking on skills, and on where automation is actually worth adding, shaped a lot of how I approached this (@mattpocockuk). The idea that stuck: a skill only earns its keep if the agent reaches for it at the right moment. Writing it is the easy half. Making it get used is the real work.

What changed wasn't speed

Before, every session started cold. The method lived in whoever was at the keyboard that day. Now the method is the same no matter who asks. The agent runs the same disciplined loop on a bug whether I kick it off or a teammate does.

There is some speed in that, but speed is not the point. Predictability is. I stopped spending attention on remembering how to ask, and I stopped quietly worrying that a good result today would be an average one next week.

Two things surprised me. A skill nobody reaches for is dead weight, so the router ended up mattering as much as the skills. And the ones that earn their place are almost always the boring repeated tasks, not the clever edge cases I thought I was building for.

If you're the one deciding this for a team

You do not standardize how a team uses AI by publishing a policy document. Nobody reads it, and it is stale a week later. You standardize it by making the good path the default path, so the right way to do something is also the easy way.

That is cheap to try. Low risk, easy to change, easy to throw away whatever doesn't prove useful. For something that quietly sets the quality of a growing share of your team's work, that is a trade worth making.