Skills

A skill is a named instruction packet with a description of when it applies — your house style, your editorial rules, the shape you want a product description to take.

Two sources, one catalogue

CopilotPlugin({
    skills: [
        {
            name: 'house-style',
            description: 'How we write headlines and standfirsts.',
            instructions: '…',
            always: true
        }
    ],
    providers,
    config
});

Code-declared skills are validated at construction, like the provider list.

The two are merged, and code wins a name collision. The admin write routes refuse a colliding name up front, so reaching that merge means a deploy took a name over rather than a request doing so.

Three ways a skill reaches a run

All three are the system prompt.

That third channel is the interesting one. Every other enabled skill is advertised by name and description only, so the model can recommend a skill it was not given — “this looks like a product description; want me to use the product-copy skill?” — without its instructions costing context on every run.

Skill bodies are injected after the security rules a skill must not override, and before the style rules it should refine.

No tool delivers a skill

Progressive disclosure through a copilot_skill_read tool is the obvious design, and it is rejected.

It would mean either carving an exception into the untrusted-content fence for one tool name, or handing the model instructions labelled as inert data and relying on it to disobey the label. Neither is a good trade for saving some prompt tokens.

Skills arrive through the system prompt or they do not arrive.

Managing skills

A code-declared skill is not editable through these routes — it is part of the deployment.