What is a skill, and how is it different from a prompt? A prompt is something you type once. A skill is a file the agent reads before it starts, describing how your organization does a particular piece of work: the sequence, the constraints, the failure modes, and how to reach the systems involved.
Which makes a skill library the first version of institutional memory that a machine can act on. Not a wiki nobody opens. Instructions that execute.
Every company already has skills, written in people
Ask why the quarterly report is built that way and you get a name, not a document. Somebody knows that 2 of the revenue lines double-count until you exclude a test account, that the number leadership means by active is not the one in the dashboard, and that the finance team wants it before Wednesday or it misses the cycle.
That knowledge is real, valuable, and stored in exactly one place. It leaves when the person does, and it takes a new hire 6 months to rebuild by making the same mistakes in the same order.
Writing it into a skill does 2 things at once. The agent can now do the work at the standard of the person who wrote it. And for the first time the process is inspectable, which usually reveals that nobody agreed on it in the first place.
What belongs in a skill and what does not
In: the order operations happen in and why. The constraints that are not obvious, meaning the test account, the excluded region, the definition that differs from the dashboard. The failure modes, so the agent recognizes a bad result instead of formatting one. And the connection mechanics, which is the part most teams leave out.
Connection mechanics deserve their own line. If the skill says how the agent reaches a system, whether by CLI, direct API or an MCP server, and how authentication works on each path, then the agent can fail clearly. It says it cannot reach the warehouse from this surface and why. Without that, it fails confusingly: a query that silently ran against the wrong project, or an auth prompt relayed somewhere it should not have gone.
Out: anything that changes. A skill that hardcodes this quarter's targets is stale in 90 days and wrong in 91. Facts belong behind a query the agent runs. The skill holds the judgment, the tool holds the truth.
Skills and MCP do different jobs
MCP gives an agent reach. Skills give it judgment. An agent with warehouse access and no skill will answer your question with a query that is syntactically fine and conceptually wrong, because nobody told it that active means something specific here.
The practical order is to write the access skill first, the one that says how to connect and what the gotchas are, and let real questions tell you which analysis skills people actually need. Teams that start by writing 12 analyst skills usually find that 9 of them answer questions nobody asked.
A skill that encodes a bad process scales the bad process
This is the part that gets skipped. Automation is not neutral about quality. If the way you do onboarding reviews is inconsistent, writing it down and handing it to an agent produces inconsistency at volume, faster, with a confident tone.
So the first draft of a skill is a process audit whether you wanted one or not. When 2 people write the same skill and disagree, that disagreement was always there. It was just cheap to ignore while it lived in 2 heads.
Freshness is the operational problem
A skill library rots the way documentation rots, except now the rot executes. The check is mechanical: change a skill file, then confirm the agent picks up the change within whatever window you are willing to live with. If nobody knows that number, the library is already drifting.
Ownership matters for the same reason. A skill without a named owner is a document, and documents decay quietly. A skill with an owner is a piece of the operating system, and it gets the same treatment as anything else in the release path.
Which is the same discipline evals need, for the same reason: something that only produces a report gets skimmed. I went through that in Evals Are the New QA.
What this is worth
The obvious value is speed, and it is the smaller half. The larger half is that a new person on the team starts with the methodology of the most experienced person rather than the confidence of the least. That gap, between how the best person does the work and how the median person does it, is where most of the variance in a company's output actually lives.
Closing it used to require training, tenure and patience. It now requires someone to write down what they know, which turns out to be the hard part, and always was.
A skill library is one layer of a larger idea, the agent that holds what the whole company knows and gets asked before a person does, which I went through in The Company Operating System.