The highest-leverage thing in my artificial intelligence (AI) workspace is a folder of skills. A skill is a plain markdown file describing how one job gets done: what triggers it, what inputs it needs, the deterministic steps, and the checks that say whether it worked. There are dozens of them. They cost me almost nothing until the moment one is needed, and they are the reason the system gets better instead of merely staying useful.
Why a File Beats a Good Prompt
The ordinary way to work with an assistant is to solve a problem well and then lose the solution. You write a careful prompt, get a good result, close the window. Next month you solve the same problem again from scratch, slightly worse, because you no longer remember which details mattered.
A skill is that solution written down in a form the assistant can load on its own. The mental model I use: a skill is how I do X, and an agent is go do X and report back. The skill is the playbook, and the playbook is the durable asset.
They Are Free Until They Are Needed
The mechanic that makes a large library practical is progressive disclosure. The assistant does not load every skill. It sees a lightweight index of names and one-line descriptions, and it reads the full file only when a task matches the triggers. So a library of dozens costs roughly one line of context each until one earns its place.
This is why the description field deserves more care than the steps. The description is what the dispatcher matches against, so it has to name observable situations rather than aspirations. "Use when publishing a document to the wiki" is a trigger. "Use for documentation tasks" is not, and a skill with a vague description is a skill that never fires.
| Section | What it does | Failure it prevents |
|---|---|---|
| Triggers | Names the situations that should load this | A good skill that never fires |
| Required inputs | States what must exist before starting | The agent inventing a missing input |
| Deterministic steps | Same steps, same result, no judgment calls | Plausible improvisation |
| Pass or fail checks | Mechanical verification the work is correct | Confidently reporting done too early |
The last row is the one most people skip and the one that makes a skill trustworthy. An agent will tell you it finished long before it actually has. A check that either passes or does not is what stands between that claim and your trust.
The Rule That Makes the Library Grow
One meta-rule ties it together, and it is the whole compounding mechanism: before any non-trivial task, classify it and load the matching skill first; if no skill exists, create one. That is it. Every one-off solution becomes permanent capability on the way past, so the second time you meet a problem you are editing a file rather than starting over.
Over a year this is the difference between an assistant that is equally useful in month twelve and a system that is meaningfully better. Skills accumulate, and unlike a chat history they are structured, testable, and readable by both of us.
Take It
Here is the skeleton I write against: SKILL-template.md. Copy it, fill in one job you have already solved twice, and put it where your assistant can see it. The first one takes half an hour. The tenth takes five minutes, and by then the library is doing the work.
This is part of a track on agent tooling and spec-driven development that goes deeper than a field report, with something you can download and run in each one. Free for now while the track grows; the deepest installments become a paid tier later.