Why we write our own skills

Most AI coding setups now come with skills, which are packaged instructions the agent loads before it starts working. There are marketplaces full of them; you install one with a click, and the agent immediately knows how to build slide decks, review pull requests, or talk to your CRM.

It’s a useful mechanism, and we use it heavily. The part worth arguing with is the one click.

A skill is a document that sits in your agent’s context and changes how it behaves. Sometimes it also carries scripts the agent will run. That’s worth saying plainly, because “skill” sounds like a feature you switch on, and what you’re doing is closer to onboarding a subcontractor with a work manual you may or may not have opened.

When you install a skill without reading it, you’re trusting that whoever wrote it shares your defaults. They decided how thorough a review should be and what good copy sounds like. They decided whether a failing check blocks the work or gets noted and skipped, and what the agent is allowed to do without asking. You won’t find any of that in the marketing description. It’s in the file, if you read it.

The clearest example is what we’ve been building around our current production project. We’ve packaged the delivery workflow itself into a set of skills, a plugin we call Athlon Code. One skill takes a ticket from our tracker, codes the fix in an isolated worktree, opens a merge request, and moves the ticket to review. Another collects the reviewer’s comments and fixes against them, and when CI is red, it reads the failing logs first instead of guessing at the problem. A third runs a planning session we call grilling: one question at a time, every question offered with concrete options, and anything that’s a fact gets looked up in the repo rather than asked. It ends in a written spec and a set of tickets, and there’s a designer’s version of the same flow, with the engineering questions swapped for experience ones.

None of it sounds spectacular, and that’s fine. Each skill is a few pages of markdown that encode decisions we’d otherwise re-make every week: how branches are named, what a commit message says, when a ticket counts as in review, and the person driving the session getting credited on every commit. One of them is a governance rule rather than a style preference – the agent’s work never merges itself – and it sits in a skill precisely because a rule that lives in someone’s head gets skipped on a bad Friday. The instructions are versioned and reviewed like any other code, so when we change how we work, we change a file, and everyone’s agent works the new way the next morning.

Could we have assembled something similar from marketplace skills? Some of the mechanics, probably. The value was somewhere else, though. What we have now is our process written down precisely enough for an agent to follow it, and no marketplace has that, because it’s ours.

We install third-party skills too. For generic work, like building a PDF or converting a spreadsheet, someone else’s skill is usually better than what we’d write, because they’ve hit more edge cases than we have.

The rule is that it gets read first, the same way code from outside the team gets reviewed before it merges. Reading a skill takes ten minutes. What does it actually instruct the agent to do? Does any of that conflict with how we work? And does it run anything, because a skill that carries scripts is a dependency, with everything that implies.

The alternative is installing on reputation and hoping. The temptation is understandable, since the whole point of the mechanism is convenience. But an unread skill sits in your agent’s context on every task it touches, nudging output in directions nobody on your team chose. If it updates upstream, the behaviour changes and nothing tells you. You find out when something ships that doesn’t sound like you, or doesn’t check what you thought was being checked.

There’s now a measurement of what’s actually out there. A group of researchers indexed 98,380 agent skills across two public registries in January 2026 and went hunting for the malicious ones. They confirmed 157, a small share of the total, and the honest way to put it is that, as it stands, the odds that any particular skill you install is deliberately hostile are low. The shape of what they found is the useful part. Remote script execution was the most common pattern at about a quarter of everything they labelled, with credential harvesting at 18%. The one in the middle, behaviour manipulation at roughly 19%, is the one worth your attention. It’s a preprint, so treat the exact counts as provisional (Liu et al.).

Behaviour manipulation is the category I’d watch, even though it’s probably the least damaging of the three. A skill that changes what the agent prioritises steals nothing, so no scanner flags it, and no incident report ever names it. It moves your output, on every task, in a direction nobody chose. A badly written honest skill does the same thing by accident, and that’s the reason to make reading the control.

An example of skills which sell well and end up… not doing so great, is the typical one promising xx% reduction in tokens, and ending up bloating the repository with tons of irrelevant files. I’m sure that the developer’s intent was genuinely good; however, that doesn’t mean that it fits each project. And in these dynamic times, who has time to maintain a quick skill repo anyway?

If this sounds familiar, it’s the ticket argument in different clothes. A model given a vague ticket produces plausible code that closes the ticket, and a model given a real specification produces code that ships. A skill is a specification too, one that applies to every task rather than one, which raises the stakes in both directions. A good skill raises the floor on everything the agent does. An unexamined one lowers it too, and nobody notices until something ships wrong.

So the position we’ve landed on is unexciting: write the skills that encode your judgement, install the generic ones after reading them, and treat both as part of the codebase, so they get versioned and reviewed and somebody owns them. It’s the same discipline we apply to everything else the agent works from.

If you’re building up your own agent setup and wondering which skills to write first, start where your standards are strongest and the market’s are weakest: your review bar, and what counts as done. No off-the-shelf skill is going to write those for you. If you’d rather have someone look at the whole setup with you, that’s part of what our Production Readiness Review covers – ping us.