Definition
AI agent skills are reusable workflow artifacts that describe how an agent should perform a task, choose tools, handle known errors, and apply previously validated patterns. Skills can be authored by humans, extracted from successful sessions, or refined over time through review and version control.
AI agent skills are the reusable procedural layer between raw prompts and fully automated tools. A prompt tells an agent what the user wants. A tool gives the agent a capability. A skill tells the agent how to combine context, tools, decisions, and known fixes to complete a class of tasks.
Skills matter because agent work often succeeds or fails on procedure, not on raw model capability. A model may know how to write code, query a database, or call an API, but it may not know which steps your team has already validated, which errors are red herrings, or which combinations of tools tend to work for a given class of task.
A skill is the artifact that carries that procedural knowledge from one run to the next, and from one engineer to the rest of the team.
Quick breakdown
| Trigger | When the skill should be considered — a task type, error pattern, file path, environment, or user goal. |
|---|---|
| Procedure | The recommended sequence of steps or tool calls. |
| Decision points | Branches based on observed state, tool output, or error conditions. |
| Troubleshooting knowledge | Known symptoms, likely causes, and fixes. |
| Boundaries | When not to use the skill, required permissions, assumptions, or safety constraints. |
| Versioning | Metadata that makes the skill reviewable, diffable, and maintainable. |
Why skills exist
Agent sessions often produce procedural knowledge that is too detailed for high-level docs and too valuable to leave in a transcript. Skills exist to preserve those repeatable procedures in a form agents can use.
The second time your agent rediscovers the same fix, the problem is no longer model intelligence. It is missing memory in the workflow.
Many useful agent sessions contain a pattern worth preserving — a tool sequence that worked, an error path that resolves to a known fix, a decision branch that avoids a dead end. Without a way to lift those patterns out of the transcript, they tend to stay private to one engineer or one session. Skills give that knowledge a durable home.
How skills differ from prompts
A prompt and a skill look similar from the outside — both are instructions for an agent. The difference is what they encode and how they are maintained.
| Prompt | Skill |
|---|---|
| Usually describes a goal or instruction | Describes a reusable procedure for a class of tasks |
| Often written before the work happens | Often refined after the work succeeds or fails |
| May not include tool sequences or error handling | Can include tool-use patterns, decision branches, and troubleshooting |
| Often lives in chat, docs, or config | Should live in a versioned, reviewable location |
The practical test: if a new engineer was given the prompt, would they hit the same dead ends an experienced engineer already routed around? A skill captures the routing.
How a skill gets created
Skills can come from at least three paths:
- Human-authored. A team codifies a known practice — how to set up a new service, how to triage a class of errors, which tools to use for a recurring task — directly into a skill file.
- Extracted from a captured session. A successful session is reviewed and the reusable pattern is lifted into a skill.
- Refined from repeated failures or newer sessions. An existing skill is updated when new evidence shows the pattern has shifted or a previously unknown failure mode has appeared.
Observed work (team practice, captured session, or failure evidence)
│
▼
Reviewed pattern
│
▼
Skill file (procedure + triggers + decisions + troubleshooting)
│
▼
Versioned library
│
▼
Future agent runs Whichever path a skill comes from, the same review discipline applies: someone should read the skill, validate the steps, and decide it is worth invoking on future runs before it lands in the library.
What makes a skill good
A skill is more useful when:
- It has a clear trigger so the agent knows when to consider it.
- It solves a recurring class of task, not a one-off.
- It states assumptions and prerequisites.
- It includes decision points and error handling, not only a happy path.
- It says when not to use it.
- It is short enough to load usefully into the agent’s context.
- It is reviewed and versioned.
- It can be tested or evaluated against future runs.
What skills should not do
Equally important is what a skill should not become:
- Skills should not encode secrets.
- Skills should not bypass review, permissions, or safety checks.
- Skills should not overfit to one messy session.
- Skills should not silently replace human judgment for high-risk decisions.
- Skills should not be treated as permanent; they should be refreshed or retired when the environment changes.
What skills make possible
Onboarding compression
A new engineer joining an agent-heavy team can inherit the procedural knowledge the team has already extracted, instead of rediscovering it. The skill library acts as a runbook the agent can read directly.
Consistent behavior across engineers
For example, five engineers debugging a flaky pipeline can otherwise produce five different guesses. A shared skill can route every agent run — regardless of who initiated it — through the same verified fix path.
A compounding knowledge base
A team of five engineers running ten sessions a day creates fifty chances to notice reusable patterns. Without a skill layer, most of those patterns stay private, disappear into transcripts, or get rediscovered later.
The knowledge base grows with use. Each reviewed pattern becomes a reusable asset for subsequent sessions. Skills are a way to convert individual problem-solving into team-level capability.
Where skills fit in the agent stack
Skills are an output of observation and review, and an input to future runs. The stack tends to look like:
Captured sessions / observed workflows / team practices
│
▼
Skill creation (human-authored, extracted, or refined)
│
▼
Versioned skill library (team-shared, reviewable)
│
▼
Future agent runs (load or reference relevant skills)
│
▼
New evidence → review/update existing skills A skill is less like a prompt snippet and more like a reusable procedure: named, reviewable, and intended to be invoked when the situation matches.
Skills vs alternatives
| Approach | What it captures | Trade-off |
|---|---|---|
| Tools | Capabilities the agent can call | Do not describe when or how to combine them. |
| Runbooks | Human-facing procedures | Useful, but not always structured for agent invocation. |
| RAG documents | Reference information | May not encode procedural sequences. |
| Prompt libraries | Reusable instructions | May not include evidence from real runs or structured troubleshooting. |
| Fine-tuning | Statistical patterns in model weights | Less inspectable and slower to update. |
| Skills | Reusable procedural guidance with triggers, decision points, and known fixes | Requires authoring, review, and maintenance. |
Skills do not replace any of these. They sit alongside them, encoding the procedural layer that the others tend to leave implicit.
How Paper Compute implements AI agent skills
Paper Compute treats skills as reviewable artifacts generated from captured agent sessions. tapes captures supported agent sessions routed through the proxy path; the skill drafting workflow is consolidating under the paper CLI. Drafted skills can be reviewed, edited, committed, shared, and loaded by future agent runs. stereOS provides an isolated runtime when applying a skill involves running code or tools.
The important shift is that useful agent behavior becomes a durable artifact, not a one-off session outcome.