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 it prompt engineering. That framing is running out of road. Language models are now agents: they read files, run code, call tools, and carry out multi-step work. The question has moved from what I say to the model, to what the model needs to know and when.
Agent skills are the clearest answer anyone has put forward so far. A skill, in the sense Anthropic's SKILL.md convention popularized, is a small self-contained package of procedural knowledge. A folder holding a markdown file of instructions, plus whatever scripts, templates, and reference documents the task needs, that an agent discovers and loads on demand. The idea is simple. Its consequences for how people build GenAI systems, and for what companies hire GenAI specialists to do, are not.
The shape of a skill
A skill is a directory. At its root sits a SKILL.md file: a short frontmatter block carrying a name and a one-line description, then the instructions themselves. They cover how to perform the task, which conventions to follow, which edge cases to watch, and which bundled script to run when. Alongside that file the skill ships whatever the task requires: a Python script that fills PDF forms, a document laying out a company's brand guidelines.
Progressive disclosure is the design property that makes this work. The agent does not load every skill into its context window. At startup it sees 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 those instructions call for it does the agent open the deeper reference files or run the bundled code. You pay for each layer when it earns its place.
Your first day at a job, nobody hands you the entire company wiki. Someone tells you what exists and where to look it up. Skills give an agent the same thing: a table of contents for institutional knowledge, with the chapters left on the shelf until somebody needs one.
The problem skills solve
The naive way to make an agent good at a task is to write everything it might need into the system prompt. That breaks down in ways worth naming.
The cost is the obvious one. Context windows are large, not free. You pay for every token in the prompt on every request, the model attends to it on every forward pass, and past some point it dilutes the model's focus. Stuffing ten tasks' worth of instructions into a prompt to support the one task in front of you is waste in the strict engineering sense.
The organizational cost is quieter. Prompt text buried in application code is invisible to anyone but the developer who wrote it. The domain expert whose knowledge it encodes cannot review it. The neighboring team cannot reuse it, and nobody can version it separately from the application. Hard-won operational knowledge, how finance formats its reports, how the deploy process works, ends up trapped in string literals.
Then there is behavior. Instructions for task B do not sit inert in the context while the agent performs task A. They leak. Models conflate adjacent instructions, apply rules out of scope, and lose the thread in long prompts. Too much of the wrong guidance at the wrong time degrades an agent as much as too little guidance does.
Skills answer all of that with one move: expertise becomes modular, discoverable, and loaded late. The token spend goes to relevant knowledge. A skill is a plain-text artifact, so the person who knows the domain can review and own it instead of the person who knows the API. And the agent's working context holds instructions for the task in front of it rather than the union of every task it might ever face.
Code and judgment
Skills can bundle executable code, and that changes the reliability calculus. Some steps in a workflow want a model's judgment: interpreting a vague request, adapting to a messy input. Sorting a spreadsheet, rotating a PDF, and checking a color contrast ratio do not. Those are solved problems, and asking a language model to do them token by token costs more and works less often than twenty lines of Python.
A good skill draws that line on the page. The SKILL.md tells the agent when to reason and when to hand off to a bundled script. The result is a hybrid: deterministic where determinism is cheap and correct, model-driven where flexibility is the point. Most of the craft of authoring a skill is deciding where the boundary sits for a given task.
The job this changes
Skills mark a shift in what GenAI expertise means. The specialist's job is moving from writing prompts to engineering capability, and those are different disciplines with different habits.
Prompt engineering was conversational craft: phrasing, few-shot examples, coaxing. Capability engineering looks more like software architecture crossed with curriculum design. You decide how to decompose a domain into composable units, what belongs in the always-visible metadata and what belongs in the lazily-loaded body, which parts of the procedure should be code rather than instruction. Then you test that the agent fires the right skill at the right moment and stays quiet at the wrong one, and you version the thing as the underlying process changes so a rollout across a fleet of agents does not regress.
These reward engineering habits: evaluation suites for trigger accuracy, code review on instruction files, semantic versioning, clear ownership. Better base models will commoditize the specialist who only iterates on prompt wording. The specialist who takes a domain expert's tacit process and turns it into a tested, versioned, portable skill is doing work no base model can absorb, because that knowledge was never in the training data. It lives in the organization.
Portability is easy to underestimate. A skill is files, markdown and scripts and references, so it does not care what surface it runs on. The same skill serves an agent in a terminal, an API-driven backend, and a chat interface. As the ecosystem standardizes on conventions like SKILL.md, skills become an asset class: transferable between platforms, shareable between teams, publishable as open source. Companies are starting to accumulate skill libraries the way they accumulate internal tooling. Building, evaluating, and maintaining that library is becoming a role of its own.
Writing them
A few principles carry most of the weight.
- The description is a routing decision. It is the only thing the agent sees before deciding whether to load the skill, so state when the skill applies and, where confusion is likely, when it does not.
- Keep the SKILL.md lean and push depth into references. Past a few hundred lines, split it. The agent should read the minimum it needs to act, with the 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 the failure modes. The most valuable lines in a mature skill start with "if X goes wrong," which is where the tacit expertise lives.
- Evaluate triggering as well as execution. A skill that performs well and fires on the wrong tasks is a net negative, and so is one that never fires on the right ones. Test both directions.
- Treat skills as production code. Review them, version them, give them owners. A skill encodes how work gets done, and it deserves the same rigor as the systems it drives.
Conclusion
Each maturing layer of computing develops a packaging format. Functions became libraries, services became containers, and agent expertise is becoming skills. Knowledge that was ambient and personal turns explicit and shared, and a discipline forms around producing it well.
Models keep improving on their own, and nothing you write today makes frontier reasoning better tomorrow. The gap that stays open is between a generally capable model and an agent that does your organization's work your organization's way. Skills exist to close that gap, in plain text, with tests behind them. That is the part of this job worth learning.