I keep coming back to a simple observation about working with AI agents: most of what I type into them is not new. It is the same setup, the same conventions, the same "here's how we actually do it here" that I have explained a hundred times. Agent skills are where that repetition finally goes to die.
A skill, in the sense I mean, is a small, named, reusable instruction set the agent can load on demand. It is not a prompt I paste. It is a durable file that captures a process once and gets reused forever. Over the last few months I have leaned on them hard, and the value has been sharper than I expected.
Skills Are the Things I Type Constantly
Start with the most boring benefit, because it is also the most valuable. My skills are, quite literally, the things I type over and over. "Run the tests this way." "Format commits like this." "When you touch the API layer, regenerate the client." "Here's the directory that actually matters." None of that is interesting to write a second time, let alone a fiftieth.
Encoding those keystrokes into a skill turns muscle memory into shared infrastructure. Instead of re-explaining the workflow every session, I invoke the skill and the agent already knows the moves. The payoff is not just saved typing — it is consistency. The process runs the same way whether I am sharp at 9am or tired at 6pm.
Skills Fix the Context Problem
Here is the failure mode skills quietly solve. Left to its own devices, an agent reads too much into context. It crawls files it does not need, re-derives conventions it could have been told, and burns tokens rediscovering things that were never in question. The output is often fine, but the path there is noisy and expensive.
A good skill inverts that. Instead of letting the model guess what matters, I tell it exactly what matters and, just as importantly, what to ignore. The skill becomes a filter: the relevant process is loaded, and the irrelevant exploration never happens. Less context, more signal, faster answers. The model stops reading the whole house to change a light bulb.
Skills Pin Down Process
The place skills shine most is nailing down a specific process. Prompts are good at intent; skills are good at procedure. When there is one correct sequence — build, then migrate, then seed, then run — a skill records that sequence so it is executed the same way every time, by me or by anyone else on the team.
This is why I think skills belong at companies, not just in my personal toolkit. Every engineer who joins a new company spends their first weeks drilling down the process: how the repo is laid out, how to run things locally, which scripts are load-bearing, what "done" looks like. That knowledge usually lives in people's heads and gets transmitted by interruption.
A skills registry inside the repo is a far better home for it. New developers — and the agents they work alongside — read the same skills and inherit the same process. Onboarding stops being an oral tradition and becomes something you can version, review, and improve like any other code. The process is written down once, in the place the work actually happens.
Skills Get Better When They Use MCPs
The step change comes when a skill does not just describe a process but reaches out and performs it, using an MCP server to pull in live context the model could never infer on its own.
My favorite example is a screenshot skill. It uses the Playwright MCP to open the UI I am working on, capture exactly the screen or component in question, and then attach that image as context to a pull request or a board comment. The agent is no longer reasoning about the interface in the abstract — it has looked at the real rendered thing, and so has everyone reviewing the change.
That combination is the whole thesis in miniature. The skill pins down the process (which URL, which viewport, where the screenshot goes). The MCP fetches the precise context (the actual pixels). And the noise — everything the model would otherwise guess about the UI — disappears, because the ground truth is right there in the comment.
The Pattern
So the mental model I have settled on is this: if I find myself typing the same thing again, it is a skill. If the agent keeps wandering into context it does not need, the fix is a skill that scopes it. If a process must run the same way every time, it is a skill. And if a skill can grab real context through an MCP instead of asking me to describe it, it should.
Skills are not magic. They are just the discipline of writing the process down, close to where the work happens, in a form both people and agents can execute. That turns out to be most of the battle.