Write a skill: the description is the trigger, the body is the instructions

A chat message tells an AI what to do this once. A skill teaches it how to do something every time. A connector gives it hands to reach real apps and data. ¹ This room ships one skill, the one that runs the room, and every worker built here may need skills of its own. This page is the rule for writing one that fires when it should, stays quiet when it should not, and does the same thing for whoever runs it.

What a skill is, and what it costs

A skill is a folder with a SKILL.md file, plus optional scripts/, references/ and assets/. SKILL.md is the entry point: frontmatter with a name and a description, then the instructions. The smallest skill is one file with those three things and nothing else. Because it is a file on disk it versions, travels and gets reviewed like any text. ²

A skill loads in three stages, each firing only when the last said it was relevant: ²

1. Discovery. At startup the agent loads the name and description of every skill, roughly 100 tokens each. Fifty skills cost about 5,000 tokens per turn: the price of knowing what is in the library.
2. Activation. When the model matches a task to a description, it loads that skill's full body. Keep it under about 5,000 tokens; most sit at 500 to 2,000. Paid only on turns that use the skill.
3. Execution. Files the body references load only when the agent reaches for them.

Two things follow and drive everything below: the description is what fires at discovery, so it decides everything; and long bodies cost you on every matching turn, so keep SKILL.md tight and push depth into references. ² OpenAI's guidance adds the host's budget: hosts may shorten descriptions when many skills are installed, so front-load the key use case and trigger words. ³

The description is the trigger

Only two frontmatter fields are required: name, lowercase with hyphens and matching the folder, and description, the trigger surface the agent reads at discovery. ² The description decides whether the skill ever fires; the model does not read the instructions to decide relevance. The formula: what it does, when to use it, and the exact phrases a person would actually say. ¹

The scaffold gets it wrong by writing a circular one: "summarises a ticket into five sections; use when the user wants to summarise a ticket." That fires on "summarise this ticket" and misses how people actually talk: "write a handoff note for #4471", "TL;DR this thread", "give my lead the rundown before I escalate". A description that fires reliably names four things: ²

• What it produces, the actual output.
• When to reach for it, the real situations: a handoff, an escalation, a briefing.
• Keywords people actually type, including the ones that never say the obvious word.
• A do-not line for the look-alikes that must stay quiet.

The self-check that kills circular descriptions: delete the obvious keyword from your description. Does it still say when to fire? If not, it is too narrow. ² Once installed, the debugging trick is to ask the agent "when would you use my X skill, and when would you not?" It paraphrases the description back; if the answer is narrower or wider than you meant, you have found exactly what to fix. Add a negative trigger when a skill fires too eagerly: "do not use for one-off calculations or quick questions." ¹ OpenAI's guidance says the same in one line: explain exactly when the skill should and should not trigger, and test prompts against the description to verify. ³

Two more rules that prevent upload errors: no XML-style tags in the name or description, and do not put "claude" or "anthropic" in a skill's name; those are reserved. ¹

The body is the instructions

No format is required, but good bodies are imperative ("Read the full thread. List what was tried."), carry one or two real examples, worth roughly five times a description for steering, and name two or three edge cases that have actually broken. ² For every instruction line, ask one question: would two colleagues who read it do the same thing? "Flag the big payments" fails; "flag any single payment above the withholding threshold with a WITHHOLDING note" passes. A line that fails shows no error; the output just comes out different every run. ¹

Write instructions as steps with explicit inputs and outputs, and prefer instructions over scripts unless you need deterministic behaviour or external tooling. ³ The book's timing rule says where the line is: an exact step, a sum, a threshold check, belongs in a small script rather than a sentence, because code is exact and a sentence gets read a little differently each time. If the skill keeps guessing at data, that data should arrive through a connector, not from memory. ¹ This is the same rule the room applies to workers: anything that must hold regardless of the model lives in code, never only in prose.

Write instructions under the prompting guide: only what the model cannot work out on its own, neutrally framed, pruned by the delete test. A skill body that restates what a capable model already knows is resident cost with no steering.

Keep each skill focused on one job. ³ The book's decision between one big skill and several small ones: one skill is easy to discover and one activation, but every step runs in one context, nothing is reusable alone, and a mid-way failure leaves the model recovering with stale work. Several small skills can each be tested, replaced and reused, a failure is localised, and each step activates fresh. Write one skill when the steps are tightly coupled and never reused alone; write several when a step might be called on its own or when clean context matters. Separation usually wins past two or three steps. Chain them through the filesystem, not the conversation: skill A writes a file, skill B reads it, and the steps in between stay on disk for the agent, the person and the audit trail. ²

Where it lives, and how it travels

The folder has one required file and three optional folders, each with one job: scripts/ for code the agent runs, references/ for deep documents loaded on demand, one topic per file, and assets/ for templates, schemas and lookup tables. Inside SKILL.md, point at them by relative path; they resolve from the skill's own folder, not from wherever the agent is running. ²

Skills are an open standard, so a basic SKILL.md travels across compatible tools; each product adds its own install path, invocation and permissions on top, so the core is portable while the edges differ. ¹ The book's one rule for location: put skills in .claude/skills/, which Claude Code reads, OpenCode falls back to, and an SDK worker can point at directly. When a project-level skill and a user-level skill share a name, the project-level one wins, the same way a project rules file overrides a global one. ² The exact folders each tool reads are on the skill page, which also carries this record's own install instructions.

Test the trigger, then iterate

A skill is never done on the first draft. The loop: describe it and let the agent generate the first version; read it and fix anything obviously wrong; test triggering with the phrases that should activate it and with unrelated requests that should not; test the output on a realistic input; test the hard cases (an empty month, a value exactly on the threshold, a messy input); bring the failures back and tighten. ¹

The book's stronger form is a trigger eval: give the skill-building tool your fire and do-not-fire cases, let it turn them into trigger evals, run them, and tighten the description until it fires on the handoff, the TL;DR and the status phrasings and stays quiet on the near-misses. You read the pass and fail table, not the raw description. ² That table is the rigorous version of the delete-the-keyword instinct, and it is the same discipline as evals before shipping applied to one field.

When a skill misbehaves, note when it went wrong before you change anything: ¹

Those four rows are the four causes on diagnose misbehaviour, seen from inside one file.

Two notes for skills that a less disciplined model will run: put any required order between skills into a short preamble in the system prompt and keep skill bodies declarative; be explicit about what not to do, not only what to do; and remember that trigger blindness gets worse, not better, on a weaker model. Budget the strong model's effort into the skill and the weak model's effort into the system prompt. ²

A skill has no scope of its own

A connector has scopes you grant and can narrow. A skill does not: it runs with whatever access the session it runs in already has, so its reach is everything that session can reach, not only what its stated task needs. That is why reading a skill before enabling it is the control for skills, and starting read-only is the control for connectors. ¹ The full procedure for deciding whether to enable one, five checks and three outcomes, is on govern it. A skill from a stranger is a text file you are about to let an AI follow: treat it like a contract you are about to sign. ¹

Not every task deserves a skill. A task you do once is a good prompt; a skill earns its place when it encodes your specific repeated way, the thing no app does for you. ¹

The skill this room publishes was rewritten under this page: a description that names the situations and the phrases, a body of judgement steps and quality bars rather than a phase-by-phase file list, exact steps in a script, and the record, not the skill, as the place the knowledge lives. Continue to the skill to download it.

Footnotes

1. Skills & Connectors: A Crash Course. The AI Agent Factory, Panaversity, 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²

2. Building a Digital FTE: A Crash Course. The AI Agent Factory, Panaversity, 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²

3. Build skills. OpenAI developer documentation, retrieved 2026-09-09. ↩ ↩² ↩³ ↩⁴