I make everything a skill

To me, a skill is a script for an AI agent. It's more flexible than a Python script, but less reliable, more expensive and slower. On disk it's a folder with a markdown file in it. The first few lines give it a name and say when to use it. The agent sees only those lines until a request matches, then reads the rest.

Whenever I'll ask an agent for something more than once, I write one. I have about thirty now:

• Releases of the Vulkan conformance test suite: tagging a release candidate and writing its notes, withdrawing an old release.
• Code review: preparing the queue, tagging changes for the right reviewers, rebasing changes that no longer apply, moving public pull requests into our review server.
• Triage: issues and pull requests on two trackers, my inbox, what's assigned to me, whether the release milestones are on track.
• Work on the suite's code: moving tests to a new API, checking whether an extension has tests at all.
• CI: waiting for a build, fetching its artifacts.
• My working day, a skill that runs the others in order.

The instructions could go elsewhere: typed into the chat each time, in the CLAUDE.md the agent reads at every start, in a wiki page, in a script, or behind an MCP server. I've ended up preferring skills to all of them.

What I get

• The right one loads when the job comes up. A wiki page loads when someone remembers to point the agent at it, and that someone is me. My release-tagging procedure sat next to the skills as a plain markdown file for three months, never loaded, until I moved it into a folder of its own.
• Only the name and description cost anything until it's used: about 10,000 characters for all of mine, against 235,000 for the full text. CLAUDE.md is paid for in full every session, so mine holds just two rules (dry run by default, every write goes through review).
• A fix lands once. The release-notes skill checks that the version is in the suite's list of conformance versions before it creates a tag, because a tag pushed too early has to be deleted and recreated where everyone sees it. Typed into the chat, that check would run when I remembered it.
• Being text in the repo, it gets reviewed like any other change. When the agent refuses to tag next year, git log says why.
• The script stays. The one for our review server does a dry run unless you pass -f, and the skill says when -f is fine, which is the split from an earlier post written down.
• No server to run. A skill uses whatever command-line tools are already on the machine; the MCP post has the rest of that argument.
• The trigger is my own words. I don't have to remember a command name.

Where a script does better

• Every run costs tokens and minutes; the same steps in Python cost nothing much and finish in seconds.
• A skill is advice, like a CLAUDE.md rule. The agent can skip a step, so anything that must not happen goes in the script or a permission rule as well.
• Sometimes it doesn't load. The agent has asked for one of mine by name, been told no such skill existed, read the file by hand and carried on. I still don't know why.
• The descriptions sit in context every session, and long trigger lists add up. A few of mine could probably lose half their words.
• When the tools it calls change, the skill is wrong until someone notices. A script at least fails with an error.

Skill, CLAUDE.md or script

	Skill	CLAUDE.md	Script
Read up front	Partial, the name and description	Yes, all of it, every session	No
Agent can skip a step	Yes, it's advice	Yes	No
When its tools change	Wrong until someone notices	Wrong until someone notices	Fails with an error
Handles a case nobody wrote down	Yes	Yes	No

Against a script the skill loses on everything except flexibility, so I keep both: the script does the steps that never change, the skill says when to run it. I think that's the right split, for now.

I help teams set up AI-assisted engineering workflows, skills included. See services.