A skill has three parts
The description does the real work: an agent that never loads a skill was
not told when to. Say what the skill covers and the moment to reach for it.
Write the instructions themselves as positive, imperative rules — what to
do, in what order — rather than examples of mistakes to avoid; smaller models
copy whatever they read.
Creating and publishing
publish points them at:
PATCH /v1/skills/{id}savesname,descriptionorinstructions. A change becomes a new version; agents keep getting the active one.POST /v1/skills/{id}/publishmakes the latest version active. Every agent referencing the skill gets it on its next turn — no agent republish.POST /v1/skills/{id}/activatewith aversion_idpoints agents at an earlier version: that is how you roll back.GET /v1/skills/{id}returns the record withlatest(the working copy),active(what agents get) anddirty, which is true when the two differ.
Attaching skills to an agent
On the agent draft,skills lists the skills by id:
GET /v1/skills/{id}/references lists the agents using a skill, and
DELETE /v1/skills/{id} is refused with a 409 while an agent draft or
active version still references it (?force=true overrides; those agents
then skip the skill until the reference is removed).
What the agent sees
The agent’s prompt gains one block:skill (load one by name), skill_search (search across the
skills’ text) and skill_read (read a skill’s reference files, none today).
The loaded instructions arrive as that tool call’s result and stay in the
conversation, so a skill is loaded once per conversation, and again only if
it has fallen out of the context window. The chat widget shows the call like
any other tool call.