The word "skill" is doing a lot of work in the agentic building world right now, and I want to be specific about what I mean, because when I say it, I mean something concrete that I use every day.
A skill is a small, named instruction set that an agent loads on demand when the task calls for it. That's it. It's a markdown file with a name, a short description of when to use it, and the steps or rules or examples the agent should follow when it's doing that kind of work. The agent decides whether to load it based on what you asked for. You don't have to remember to attach it. You don't have to re-paste it into every session.
The first time I wrote one, I thought it was a glorified prompt template. I was wrong about that, and the reason matters.
The problem skills actually solve
Before skills, every morning looked the same. I'd open a session, and the first ten minutes was me re-explaining context the agent should have already known. How this repo is structured. What our naming conventions are. Which files are generated and should never be hand-edited. What "deploy" means in this project. Where the tests live. What the commit message format is. Which directory has the real source of truth and which one is a legacy copy nobody's deleted yet.
I'd copy-paste the same ten paragraphs from a notes file. Sometimes I'd forget one and the agent would do the wrong thing, and I'd blame the agent, and then I'd realise I'd forgotten to tell it.
That's the problem skills solve. Not "the agent isn't smart enough." The agent is plenty smart. The problem is that you, the human, are a terrible context delivery mechanism, and skills let you stop being one.
What my skills actually look like
Concrete examples, because this is the part people never show you.
I have a skill called snappy-publish that knows how to publish a blog post to this website. It knows the MDX frontmatter format, where the content folder lives, how to name the file, the commit message convention, and which branch to push to. When I say "publish this as a blog post," the agent loads that skill and does all of it without asking me. This post you're reading right now went through it.
I have a skill called snappy-xano-mcp that knows how to call my Xano MCP server — which endpoints exist, what arguments they take, when to use execute versus query, and the gotchas I've hit that I don't want to re-hit. Before that skill existed, every Xano session started with me typing out half of the MCP docs from memory.
I have a skill called snappy-browse for driving agent-browser from the command line. It has the auth flow, the state file location, and the three or four patterns I actually use, in order. It saves me from re-reading the agent-browser README every time I need to log into something.
I have a skill called snappy-github that does my commit-and-push flow the way I actually do it — specific files, not git add ., HEREDOC commit messages with the co-author line, never force-push to main. It's guardrails as much as instructions.
None of these are clever. None of them are long. The longest one is maybe 200 lines of markdown. They are the ten paragraphs I used to paste every morning, finally put somewhere the agent can find them on its own.
Why it changes how I build
Two things change the moment you start writing skills seriously.
The first is that sessions get shorter. Not because the agent is faster, but because you stopped wasting the first ten minutes every time. You ask for the thing, and the agent already knows the context, the conventions, and the guardrails. You skip straight to the work.
The second is subtler and it's the one that actually matters. You start thinking about your repeat moves as named things. "Publish a post." "Run a Xano migration." "Spin up a new client project." Each one becomes a skill, which means each one becomes legible, which means each one becomes improvable. When I hit a new edge case on publishing, I don't memorise it — I update the skill. Next time, and every time after, the agent knows. The skill library gets smarter in a way my head never does.
That second thing is the real unlock. Your workflow stops being implicit tribal knowledge trapped in your muscle memory, and starts being an artefact you can read, edit, and share. I've handed skills to other developers and watched them pick up in ten minutes what took me six months.
When to write one
The rule I use is simple. If I do something twice and it annoyed me the second time, the third time is a skill.
Not the first time — the first time you don't know the shape of the task yet, and any skill you write will be wrong. Not the second time either, necessarily — sometimes the second time teaches you the real version. But if you're doing the same thing a third time and retyping the same context, stop, spend twenty minutes, write the skill.
The twenty minutes pays back the first time you use it. Every use after that is free.
What skills are not
They are not prompts. A prompt is what you type in the chat. A skill is a named capability the agent loads when it decides the task needs it.
They are not agents. An agent is the thing doing the work. A skill is a thing the agent reads when it needs to know how you want that work done.
They are not a replacement for documentation. Skills are documentation for the agent. Your humans still need their own docs. Though I'll admit my skills and my docs have started to merge, and I don't hate it.
They are not magic. If you write a bad skill, the agent follows the bad skill. Skills amplify whatever discipline you already have. Which is fair, and is also the reason writing them makes you better at your own job.
Start with one
If you've never written a skill, don't plan a library. Pick the one thing you re-explain to the agent most often — the thing you're tired of typing — and write that one. Keep it short. Name it something you'll remember. Use it this week and update it when you find the first edge case.
Do that twice and you'll understand why I keep talking about them.
If you want to see my actual skills — the files, the structure, how they fit together — I walk through them inside the free course in the Snappy community on Skool. Join at skool.com/snappy and I'll show you the ones I use every day.
— Robert
