Your judgement, written down. And version-controlled.
A skill is a document, not a fine-tune: the decision rules, the exceptions and what good looks like, in language the person who owns that process can read and correct.
Written, not trained
The person who owns refunds can fix the refund rule.
Encoding a policy usually means describing it to an engineer, who turns it into a prompt you cannot read back. A skill removes the translator: it is prose with rules in it, and the person whose judgement it captures can open it and say whether it is right.
- A change is a diff What moved, who moved it, when. Roll it back and the behaviour goes with it.
- No retraining The correction applies on the next run rather than the next training cycle.
- It travels Change model provider and the skills come with you. They are files, not weights.
Scoped, not global
What is in play for a run is a thing you can point at.
A skill is on or off per workspace, and fires either always or when the agent reaches for a tool it is bound to. Tone and escalation rules stay on; guidance about one system arrives only when that system is in play.
- Per workspace Finance runs finance rules. Support does not inherit them by accident.
- Always or on a tool match Two triggers, so a skill is not loaded into every conversation it does not concern.
- Connectors bring their own An app can ship guidance on when to reach for it, overridable per workspace.
Skills
Questions people ask about skills
What is an agent skill?
A document that tells the agent how your business handles something: the decision rules, the exceptions, and what a good outcome looks like. It loads when it is relevant, so the behaviour it describes applies without anybody re-prompting.
How is a skill different from fine-tuning a model?
A fine-tune changes the weights and cannot be read, diffed or partly undone. A skill is a file: the person who owns the process reads it, corrects a line, and sees the effect on the next run, with a diff if it turns out to be wrong. It also travels: change provider and the skills come with you.
Who is supposed to write them?
The person who owns the process, with help. That is the point of the format: refund policy is written by whoever owns refunds, rather than by an engineer translating a conversation with them into a prompt nobody else can audit.
When does a skill actually load?
Always, or on a tool match, when the agent reaches for a tool the skill is bound to. Always-on suits tone and escalation rules. Tool-matched suits guidance that only matters when a particular system is in play.
Can an app bring its own skill?
Yes. An MCP app can ship usage guidance alongside its tools, so deploying a capability also installs the advice on how to use it well. That guidance is a file like any other and can be overridden per workspace.
What stops skills contradicting each other?
Scope, mostly: a skill is on per workspace and most are bound to a tool, so the set in play for any run is small and inspectable. When two do overlap, they are files, so you can read both, see the conflict, and fix it in a diff rather than in a support ticket.
More of the platform
Each capability has a page. These are the ones nearest this.