A skill is a bundle of specialist instructions that a sub-agent activates on demand. Instead of one large system prompt attempting to cover every topic a sub-agent might face, you attach skills and let the sub-agent load the relevant one when the conversation calls for it.
How loading works
A sub-agent with skills assigned starts each turn with access to a directory of those skills — names and descriptions, not full bodies. It reads the directory, decides which specialist knowledge the current request needs, and loads it.
The mechanism is a virtual load_skill tool inside the ReAct loop. This has a specific consequence worth understanding: there is no separate pre-flight classification call. Triage happens inside the loop, with full conversation context, at no extra model call.
Skills vs. tools
They are often confused because both are "things you attach to a sub-agent", but they do different jobs:
| Skill | Tool | |
|---|---|---|
| Provides | Instructions and knowledge | An action with side effects |
| Changes | How the agent reasons | What the agent can do |
| Result | Text loaded into context | A call to an external system |
| Gated by permissions | No | Yes |
A skill teaches; a tool acts. If you find yourself writing a "skill" that fetches live data, you want a tool or an MCP server.
Why not just one big prompt
Three reasons. Long prompts dilute attention across irrelevant instructions. They cost tokens on every turn regardless of relevance. And they make behaviour hard to change safely, because editing one domain's guidance risks perturbing another's.
Prompt vs. skill-body iteration
An operational subtlety: prompt edits are immediately testable in a draft run, but skill bodies are resolved from stored content and may lag until the agent version is promoted. If a skill edit appears to have no effect on a draft run, this is usually why.