Position skills in the GitHub Copilot component model
A skill is a distinct kind of component in the GitHub Copilot harness. Placing it well starts with understanding what a skill is at runtime, how it relates to the other components you have available, and the design cues that separate a good candidate for a skill from a scenario better served by something else.
What a skill is on the GitHub Copilot harness
A skill is a portable behavior module: a name, a description, and a set of Markdown instructions the orchestrator activates when a user's request matches the description. Skills can also bundle supporting files (scripts, templates, and reference documents) packaged alongside the instructions.
Three parts of a skill do specific jobs at runtime:
- Name: A short, hyphenated identifier for the skill (lowercase letters, numbers, and hyphens; no leading or trailing hyphen). Names must be unique inside a single agent.
- Description: A one-line summary the orchestrator uses to decide whether a user's request should route to this skill. The description is model-facing. It's the signal the orchestrator matches against, so write it for routing rather than for readers.
- Instructions: The Markdown body that guides the agent's behavior while the skill is active. Instructions cover the task or scenario the skill handles, the steps the agent follows, response formatting, edge cases, and, where relevant, the specific tools the agent should use.
A skill is self-contained: everything the agent needs to execute the task lives inside the skill file or its package. That self-containment is what lets a skill be authored once and reused across agents.
How skills fit alongside other agent components
An agent on the GitHub Copilot harness composes several components, each with a distinct job. Skills sit next to tools, workflows, knowledge, connected agents, and the agent's own instructions. The following table describes what each component contributes and who typically maintains it.
| Component | What it contributes at runtime | Where the behavior lives |
|---|---|---|
| Agent instructions | The agent's default identity, tone, scope, and standing guidance | Configured on the agent |
| Skills | A reusable, task-specific behavior the orchestrator activates when the request matches | A SKILL.md file or ZIP package |
| Tools | An external action; an operation the agent invokes against a service | A connector, API, or MCP server |
| Workflows | A deterministic sequence of steps with defined inputs and outputs | A workflow definition |
| Knowledge | Information the agent grounds its answers in | A knowledge source |
| Connected agents | A separately owned and published agent the main agent delegates to | Another agent |
Skills add the reusability layer the other components can't cover on their own:
- Reusability across agents. A skill authored once can be added to many agents; the same description and instructions apply everywhere the skill is uploaded.
- Modularity within an agent. Rather than expanding the agent's own instructions to cover every specialized behavior, you factor each specialized behavior out into a skill the orchestrator activates only when it's relevant.
- Portability outside the agent. Because a skill lives in a
SKILL.mdfile (or ZIP), you can download, edit, review, and share it as a discrete artifact independent of any single agent's configuration.
Skills also compose with the other components: a skill's instructions can direct the agent to use a specific tool while the skill is active, or to consult a specific knowledge source before responding. The skill doesn't replace the tool or the knowledge source; it choreographs how the agent uses them for a particular kind of request.
When to choose a skill
Skills are the right choice when the behavior you're designing carries three characteristics: it's a repeatable, task-specific pattern; it needs to run consistently every time the pattern applies; and it stands to be reused beyond the single agent you're designing it for.
Concrete cues that a skill is the appropriate component include:
- You find yourself writing similar guidance into more than one agent's instructions (an escalation policy, a report-generation routine, or a compliance checklist) and you want one canonical version.
- A specific pattern needs to activate only for a subset of the requests the agent handles, and general agent instructions can't be scoped tightly enough to that subset.
- You need to hand the same behavior to another team (or across another environment) without rebuilding it inside their agent.
Cues that a skill is not the appropriate component:
- The behavior is one-off and specific to a single agent. General agent instructions cover it, and there's no reuse target to justify the packaging overhead.
- The behavior is a single external action. A tool is the direct fit; a skill that wraps a single tool adds indirection without adding reuse value.
- The behavior is a fixed sequence with defined inputs and outputs that runs the same way every time. A workflow enforces the sequence more strictly than a skill's Markdown instructions can.
- The behavior is a separately owned capability with its own lifecycle. A connected agent is the fit; the other team maintains and publishes it independently, and your agent delegates to it.
Reflect: Think about an agent you plan to build or maintain. Is there a repeatable behavior in its scope that another agent in your organization also needs, such as an escalation flow, a summarization pattern, or a policy check?