skills

No. 103 · v2026-08FR: skills

Skills are sets of instructions and resources filed away separately, which the system loads into its context only when the task calls for them. Like the ring binders on an office shelf: their spines stay visible at all times, but one is only opened on the day it is needed.

What it is not

A skill is not a system prompt, even though it is made of the same material. The system prompt is there on every request, for everyone and for every task; a skill only enters the context when it is selected, and it leaves again afterwards. Nor is it a tool: a tool carries out an action and returns a result, whereas a skill carries out nothing, it instructs, and it often describes how to use the tools already available. Finally, it is not a new capability given to the model: nothing is trained, nothing is learnt, all that is organised is what the model has in front of it.

In depth

The economics of context

The pattern answers a problem in the economics of the context. A permanent instruction that grows is paid for on every call, occupies the context window at the expense of the work in hand, and dilutes the model’s attention across instructions of which the task of the moment uses only a fraction. A skill is a self-contained block: a name, a short description, then a body that may be long, made of procedures, conventions, examples, sometimes attached files or scripts. Only the description stays visible at all times, a few lines per set, and it is on the description that the selection is made; the full body arrives only at the moment it is selected. The mechanism therefore comes in two stages, an index always present and a body loaded on demand, which is exactly the compromise of a filing system: you keep the catalogue to hand, and you go and read the folder when the question arises.

The budget effect

The first effect is budgetary and it can be measured: ten detailed procedures written into the system prompt are billed on every turn, whereas their ten descriptions cost a few lines and the procedure that is actually needed is loaded only one time in ten. The second is organisational, and it matters more in daily use: a skill is a separate artefact, therefore versionable, reviewable and attributable to a team, where a system prompt is a single text that everyone edits and nobody reads through. The third is reach, since one and the same set serves several agents: the question shifts from “how should this be worded” to “who owns this procedure”. In return, one more decision is introduced into the loop, the decision to select, and one more decision is one more opportunity to get it wrong. The trade-off is therefore settled item by item: whatever must hold for every task stays in the system prompt, whatever serves only some tasks becomes a skill, and a procedure used on every call has nothing to gain from being filed elsewhere.

Selection

Selection is the fragile point, and it fails in two symmetrical ways: a relevant set that is not picked up, because its description does not say in which situations it applies, and a set picked up wrongly, because two descriptions overlap. It is exactly the fault of tool descriptions, for the same reason: the model chooses on the strength of a few lines, without having read the body. A second trap appears when several sets arrive in the context together and contradict one another, one imposing a format that the other forbids: nobody has written the arbitration, and the model produces one that nothing makes stable. The third is the most serious: a set loaded from a source you do not control is text entering the context with the standing of an instruction, which makes it a way in for a prompt injection, all the more effective because the arrangement is designed to obey it. A catalogue of skills is therefore treated like a software dependency: you know where each item comes from, you read it before installing it, you pin it to a version, and you check with an evaluation set that the right selection really is being made on the tasks that matter.

Under the hood2 steps · the real shape of the objects

The whole entry rests on an asymmetry that is visible in the object: what stays in view permanently is short, and what costs a lot only arrives if the task calls for it.

01
What is always loaded
Here is what the system keeps in its context at all times: a list of entries reduced to a name and a description. The loading decision is made on that description, and on nothing else. It is therefore the real contract, and a vague description is paid for by a selection that gets it wrong.
json
```
[
  {
    "name": "scoping-note",
    "description": "Write an internal scoping note: fixed outline, neutral tone, one decision per section."
  },
  {
    "name": "contract-review",
    "description": "Review a service agreement and list the exposing clauses, without concluding on whether to sign."
  }
]
```
name
An identifier, not a title to be read. It serves the loading and has no bearing on the decision.
description
The only thing that competes with the others at the moment of choosing. It must say WHEN to use it, not what it contains: “write a scoping note” selects better than “document template”.
The trapThe cost of this block is paid on every request, like the rest of the context. That is what bounds the number of entries: past a few dozen, the list itself becomes the thing you were trying to avoid.
02
What enters once the entry is picked
The body only arrives afterwards, and it arrives in the same shape as everything else: one more message in the list. That explains both its strength and its failures, since it enjoys no special status once it is in place.
json
```
{
  "role": "system",
  "content": "[scoping-note] Fixed outline: context, decision, consequences, open points. One decision per section, present tense. Do not close with a summary."
}
```
role
Often the role of standing instructions, which gives the body the same weight as they have. It is nonetheless present only on this turn: that is exactly where the difference from a system prompt lies.
content
Text, like everything else. Nothing stops two entries loaded together from contradicting each other, and nothing flags the contradiction: the model will settle it silently.
The trapA body written elsewhere arrives with the standing of a permanent instruction. It is the same flaw as prompt injection, at a higher privilege.

Shown elsewhere

system promptwhat is there on every request, and the order in which it is written
contextwhere these messages sit, and what their volume costs on every turn

What variesThe vocabulary varies: depending on the product these bundles are called skills, modules or capabilities, the manifest may be a file or a configuration entry, and the body may carry files alongside the text. What does not vary: the description stays loaded permanently, the body only arrives on demand, and once loaded it becomes text like any other, with no guaranteed priority over what is already there.

Relations where the neighbours live

Runs inside: agent
Requires: context tool
Often confused with: system prompt

Check 3 questions · click your answer

Level 1 · Recognise

A system has twenty skills available. What stays in its context at all times?

Level 2 · Distinguish

An instruction applies to every request, whatever the task. Where should it go?

Level 2 · Distinguish

You install a set of instructions published by a third party. What exactly are you introducing into your system?

No. 103 · v2026-08 · first written in August 2026 · editorial responsibility Anthony Capirchio

Cite this entry

Lexigraph, "Skills", v2026-08, https://www.lexigraph.org/en/skills/, CC BY 4.0.