# Slash commands

> Type / in the composer to run an app feature such as /usage, or to call a skill's command directly instead of describing what you want and hoping the agent picks it.

Typing **`/`** in the composer opens a list of the commands this agent can run. Picking one tells the agent exactly which tool to start with, rather than leaving the choice to it.

## When to use it

Use a slash command when you already know the procedure you want. *"/weekly-report"* is faster and more reliable than *"can you do the weekly report the way we did last time"* — the second is a request the agent has to interpret first.

Describe what you want in prose when you do not know which skill applies, or when the job spans several. The agent still chooses freely from everything bound to it.

## Using one

<Steps>

1. **Type `/` at the start of the composer.** The list appears above the input.

2. **Keep typing to filter.** Arrow keys move through the list; hovering or selecting a row shows what that command does.

3. **Open the ⓘ beside a row** to read the whole skill — what it is for, and every command it carries.

4. **Press Enter to insert it, then write the rest of your message** — a command usually needs context. *"/summarize the thread from Hana about pricing"* is a command plus a subject.

5. **Send.** The agent starts its [run](/docs/work/runs/) with that command, then continues normally.

</Steps>

## What is in the list

The list has two groups, and they behave differently.

### Built-in commands

Built-in commands are features of the app rather than things the agent does. They are always there, on every agent, and running one starts no [run](/docs/work/runs/) and spends nothing.

| Command | Does |
| --- | --- |
| **`/usage`** | Shows what this conversation has spent — tokens, credits, and the models involved. See the [usage dashboard](/docs/account/usage/) |

Built-in names are reserved. If a skill happens to carry the same name, the built-in is what runs; the skill's row stays in the list so you can still see it is there.

### Skill commands

The rest come from the [skills](/docs/capabilities/skills/) bound to this agent. Two consequences:

- **A different agent has a different list.** The same command is not available everywhere unless the skill is bound in both places.
- **If the group is empty, no skill is bound yet.** Bind one in [Agent Builder](/docs/build/agent-builder/); the list follows on the next message.

## What picking a skill command actually does

The command names a tool, and the agent is required to call that tool **on its first step**. After that step it is back to normal: it reads the result and decides what to do next, including calling other tools.

That is the useful shape. You get a reliable start — the right procedure, opened with your input — without freezing the rest of the run into a script.

<Aside type="note" title="Some commands ask before they act">
  A command whose skill declares that it needs confirmation still stops at the
  [approval](/docs/work/approvals/) gate when it reaches an outbound or destructive
  step. Choosing it from the list is not approval.
</Aside>

## A name that is not a command

Sending `/something` that matches nothing does not go to the agent. The composer stops it and says the name is not a command, so a typo does not become a message the agent has to interpret.

Only a message that is a slash and a single word, with nothing after it, is read as a command. `/usage in July`, a file path, and a sentence that happens to start with a slash are ordinary messages and are sent normally.

## Limits

- Skill commands are per agent. There is no global list of them; only built-in commands are the same everywhere.
- A skill command directs the **first** step only; the agent chooses the rest of the run.
- Sending a command while a run is in progress [steers](/docs/work/steering/) that run instead of starting the command — steering carries your text, not the tool choice.
- The list shows what the agent can call right now. A skill you bind mid-conversation appears on the next message.
- What a built-in command draws is local to that screen. It is not a message, so it is not in the transcript and is gone after a reload.

## Related

<CardGrid>
  <LinkCard
    title="Skills"
    href="/docs/capabilities/skills/"
    description="Where commands come from, and how to bind one."
  />
  <LinkCard
    title="Runs"
    href="/docs/work/runs/"
    description="What happens after the first step."
  />
  <LinkCard
    title="Approvals"
    href="/docs/work/approvals/"
    description="The gate a command does not bypass."
  />
</CardGrid>