Executing Skills
A Skill runs either from a chat conversation or programmatically via the API. This page covers how execution works, with a focus on running Skills in chat: the two execution modes, slash commands, and how Agents tie them together.
Ways to run a Skill
- From the Skill Library: click Use Skill (or Use This Skill on the detail page). That opens Chat and runs the Skill there.
- In chat, by asking: the AI can discover and run Skills mid-conversation. Ask for the outcome ("draft a sprint summary") and the assistant finds and runs the matching Skill.
- In chat, with a slash command: type
/and the Skill's slug to invoke it explicitly. See Slash commands below. - In an Agent chat: the Agent's attached Skills are the only ones available, and its recommended prompts can be written to trigger them. See Executing Skills with an Agent.
- Via the API: Skills can be executed programmatically, always as self-contained sessions. See the API Usage Guide. You can also send a slash command as a message through the Chat API.
Two execution modes in chat
When a Skill runs from a conversation, there are two modes. Which one is used is decided by the Skill's Operating Mode, set in the Skill builder:
- Inline: always run in the current chat.
- Subagent: always run in a separate, isolated chat session.
- Auto: the assistant picks between the two based on the task, and you can ask for one explicitly.
Inline (in context)
The Skill's instructions are loaded into your current conversation (the load_skill tool) and the assistant follows them right there. The Skill's configured tools and integrations are enabled for the chat immediately.
- The Skill sees everything you've already discussed, so the work can be driven by the conversation. You can steer, correct, and iterate as it goes.
- The work happens on the conversation's current model; an inline load does not switch to the Skill's pinned model.
- If loading the Skill would enable tools the chat doesn't already have, the load goes through the approval gate. Loads that change nothing run without approval.
Inline suits conversation-driven work. For a Skill set to Auto, ask to "run this skill here" or "in this chat" to request it explicitly.
Separately (via subagent)
The Skill runs in its own isolated child session (the skill_execute tool) with the Skill's own model and tool configuration, and returns only its final result to your conversation.
- Better for large outputs, Skills pinned to a specific model, or tasks that don't need your conversation's context.
- Keeps the main conversation clean; you see the result, not the intermediate work.
- Lets the assistant chain Skills, feeding one Skill's result into another.
For a Skill set to Auto, ask to "run this separately" or "in an isolated session" to request it explicitly.
| Inline | Separate (subagent) | |
|---|---|---|
| Sees your conversation | Yes | No |
| You can steer mid-run | Yes | No |
| Model used | The conversation's current model | The Skill's pinned model |
| Result | Work happens in the chat | Final result returned to the chat |
| Best for | Conversation-driven tasks | Large, self-contained, or model-specific tasks |
See MCP Tools → Skill Tools for the underlying tools.
Slash commands
Every Skill has an auto-generated slug (lowercase letters, numbers, and hyphens) that your organization can edit. Typing / in the chat composer opens a typeahead that suggests Skills by slug; navigate with the arrow keys and press Enter to pick one.
Slash commands are the way to start a Skill from the chat box. A Skill you pick starts right away, without the AI searching the library for it first, and if it needs information from you, the AI asks immediately.
A slash command is a standalone /some-slug token, and it works anywhere in the message, not only at the start. Sending a message that contains one is an explicit request to run that Skill:
- Text after the command becomes the subject of the task. A Skill with a single input variable receives it as that input.
- A Skill with multiple input variables is handed to the assistant, which infers what it can from your message and asks for the rest.
- The command runs the Skill in its configured Operating Mode. For a Skill set to Auto, the assistant chooses unless you ask for a mode.
- You can attach documents to the message, and the Skill run receives them.
- Slugs are matched exactly. If an organization Skill and a Global Skill share a slug, the organization's Skill wins.
- If a message starts with a slash command that matches no slug, the assistant tells you there's no Skill for that command rather than guessing. Slash-like tokens elsewhere that match nothing (paths, URLs, dates) are treated as ordinary text.
Executing Skills with an Agent
In an Agent chat, all of the above still applies, with one difference: the Agent's attached Skills are the only Skills that can be discovered or run. Slash commands resolve against the Agent's Skill set, and a command for a Skill outside it reports that no such Skill exists.
This combines well with recommended prompts. A recommended prompt pre-fills the chat input with saved text, and that text can contain a slash command. Clicking the tagline fills in something like /sprint-summary for the current project, and sending it explicitly triggers that Skill instead of relying on the assistant to infer which Skill you meant. Use this when a recommended prompt should reliably launch one specific Skill; use plain prose prompts when the assistant should decide how to help.
Where each mode applies
| Surface | How the Skill runs |
|---|---|
| Chat, inline | In your conversation, conversation's model |
| Chat, separate | Isolated child session, Skill's pinned model |
| API | Own session per request, Skill's pinned model |
Next Steps
- Skills Overview: The Skill Library and how Skills are structured
- Building a Skill: Create the Skills you'll execute
- Composing Agents & Skills: Design an Agent around its Skills
- MCP Tools → Skill Tools: The tools behind discovery and execution