For most of the short history of applied generative AI, the unit of work has been the prompt. We wrote prompts, refined prompts, versioned prompts in spreadsheets, and called the discipline "prompt engineering." That framing is now visibly running out of road. As language models have become agents — systems that read files, run code, call tools, and carry out multi-step work — the interesting question has shifted from "what do I say to the model?" to "what does the model need to know, and when?"
Agent skills are one of the clearest answers to that question to emerge so far. A skill, in the sense popularized by Anthropic's SKILL.md convention, is a small, self-contained package of procedural knowledge: a folder containing a markdown file of instructions, optionally accompanied by scripts, templates, and reference documents, that an agent discovers and loads on demand. The idea sounds almost trivially simple. Its consequences for how GenAI systems are built — and for what GenAI specialists are actually hired to do — are not.
What a skill actually is
Structurally, a skill is a directory. At its root sits a SKILL.md file with a short frontmatter block — a name and a one-line description — followed by the instructions themselves: how to perform a task, which conventions to follow, which edge cases to watch for, which bundled scripts to run and when. Alongside it, the skill can ship whatever supporting material the task requires: a Python script that fills PDF forms, a reference document describing a company's brand guidelines, a validated color palette for charts, an example of a correctly formatted output.
The critical design property is progressive disclosure. The agent does not load every skill into its context window. At startup, it sees only the metadata — a catalog of names and descriptions, costing a few dozen tokens per skill. When a task matches a description, the agent reads the full SKILL.md. Only if the instructions call for it does the agent open the deeper reference files or execute the bundled code. Knowledge is revealed in layers, each layer paid for only when it earns its place.
This mirrors how human organizations handle expertise. A new employee is not handed the entire company wiki on day one; they are told what exists and where to look. Skills give agents the same affordance: a table of contents for institutional knowledge, with the chapters left on the shelf until needed.
The problem skills solve
To understand why this pattern matters, it helps to name the failure mode it replaces. The naive way to make an agent good at a task is to write everything it might need into the system prompt. This fails in three predictable ways.
First, it fails economically. Context windows are large but not free — every token in the prompt is paid for on every request, attended to on every forward pass, and, past a point, actively dilutes the model's focus. Stuffing ten tasks' worth of instructions into a prompt to support the one task at hand is waste in the strict engineering sense.
Second, it fails organizationally. Prompt text embedded in application code is invisible to everyone except the developer who wrote it. It cannot be reviewed by the domain expert whose knowledge it encodes, reused by a neighboring team, or versioned independently of the application. Hard-won operational knowledge — how finance formats its reports, how the deploy process actually works — ends up trapped in string literals.
Third, it fails behaviorally. Instructions for task B, sitting inert in the context while the agent performs task A, are not truly inert. They leak. Models conflate adjacent instructions, apply rules out of scope, and lose the thread in long prompts. The reliability of an agent degrades not just with too little guidance but with too much of the wrong guidance at the wrong time.
Skills address all three failures with the same move: they make expertise modular, discoverable, and lazily loaded. The economics improve because context is spent only on relevant knowledge. The organizational problem improves because a skill is a plain-text artifact — reviewable, diffable, ownable by the person who knows the domain rather than the person who knows the API. And behavior improves because the agent's working context contains the instructions for the task it is doing, not the union of every task it might ever do.
Code where it counts, judgment where it counts
A second, subtler property deserves attention: skills can bundle executable code, and this changes the reliability calculus of agent systems. Some steps in a workflow genuinely benefit from a model's judgment — interpreting a vague request, adapting to a messy input. Other steps do not. Sorting a spreadsheet, rotating a PDF, validating a color contrast ratio: these are solved problems, and asking a language model to perform them token-by-token is both expensive and less reliable than running twenty lines of Python.
A well-designed skill draws this line explicitly. The SKILL.md tells the agent when to reason and when to delegate to a bundled script. The result is a hybrid system — deterministic where determinism is cheap and correct, model-driven where flexibility is the point. Much of the practical craft of skill authoring is deciding where that boundary sits for a given task.
What this means for the GenAI specialist
Here is the claim I would defend most strongly: the emergence of skills marks a shift in what GenAI expertise is. The specialist's job is moving from writing prompts to engineering capability — and those are different disciplines with different skill sets.
Prompt engineering was largely conversational craft: phrasing, few-shot examples, coaxing. Capability engineering looks more like a blend of software architecture and curriculum design. The relevant questions become: How should this domain's knowledge be decomposed into discrete, composable units? What belongs in the always-visible metadata versus the lazily-loaded body? Which parts of the procedure should be code rather than instruction? How will we test that the agent triggers the right skill at the right time — and doesn't trigger it at the wrong time? How do we version a skill as the underlying process changes, and roll it out across a fleet of agents without regressions?
These are engineering questions, and they reward engineering habits: evaluation suites for trigger accuracy, code review for instruction files, semantic versioning, ownership boundaries. A GenAI specialist who can only iterate on prompt wording will find their work increasingly commoditized by better base models. A specialist who can take a domain expert's tacit process and turn it into a tested, versioned, portable skill is doing work the base model cannot absorb — because the knowledge in question was never in the training data to begin with. It lives in the organization.
There is also a portability argument that is easy to underestimate. Because a skill is just files — markdown, scripts, references — it is agnostic to the surface it runs on. The same skill can serve an agent in a terminal, an API-driven backend, and a chat interface. As the ecosystem standardizes around conventions like SKILL.md, skills become an asset class: transferable between platforms, shareable between teams, publishable as open source. Organizations are beginning to accumulate skill libraries the way they accumulate internal tooling. Knowing how to build, evaluate, and maintain that library is becoming a role in itself.
Practical guidance for writing skills
For those starting to build skills, a few principles carry most of the weight.
- Write the description as a routing decision, not a summary. The one-line description is the only thing the agent sees before deciding whether to load the skill. It should state precisely when the skill applies and, where confusion is likely, when it does not.
- Keep the SKILL.md lean and push depth into references. If the main file exceeds a few hundred lines, split it. The agent should read the minimum necessary to act, with deeper material one hop away.
- Prefer scripts for anything deterministic. Every step you move from instruction-following into executed code is a step that stops varying between runs.
- Encode failure modes, not just happy paths. The most valuable lines in a mature skill are usually the ones that begin with "if X goes wrong." That is where tacit expertise actually lives.
- Evaluate triggering, not just execution. A skill that performs beautifully but fires on the wrong tasks — or fails to fire on the right ones — is a net negative. Test both directions.
- Treat skills as production code. Review them, version them, assign owners. A skill encodes how work gets done; it deserves the same rigor as the systems it drives.
Conclusion
Every maturing layer of computing eventually develops a packaging format: functions became libraries, services became containers, and agent expertise is becoming skills. The pattern is the same each time — knowledge that was ambient and personal becomes explicit, modular, and shared, and a new engineering discipline forms around producing it well.
For GenAI specialists, this is the opportunity hiding inside the hype cycle. Models will keep improving on their own; nothing you write today makes frontier-class reasoning better tomorrow. But the gap between a generally capable model and an agent that reliably does your organization's work, your organization's way, is exactly the gap skills exist to close. The people who learn to close it — rigorously, testably, and in plain text — are the ones this field will keep needing long after prompt tricks have faded.