# Slash Commands
Source: https://dorkos.ai/docs/guides/slash-commands

Turn a task you do often into one word you type, and learn how to write your own



# Slash Commands [#slash-commands]

Slash commands turn a multi-step task you do often into one word you type once. Type `/` in the chat, pick a command, and DorkOS handles the rest, whether that command lives in your project, on your machine, or built into the agent itself.

## Using Commands [#using-commands]

<Steps>
  <Step>
    ### Open the command palette [#open-the-command-palette]

    Type `/` in the chat input to open the command palette.
  </Step>

  <Step>
    ### Find your command [#find-your-command]

    Search or browse available commands. Commands are sorted alphabetically and grouped by namespace.
  </Step>

  <Step>
    ### Insert and run [#insert-and-run]

    Select a command to insert it into the chat input. Add arguments after the command name if needed, then send.
  </Step>
</Steps>

<Callout type="info">
  Most commands in the palette get **inserted into the chat and sent to the agent** to act on. A
  few, like `/rename`, are native: DorkOS runs them locally, right in your browser, and never sends
  them to the agent at all. You won't notice the difference day to day (both show up in the same
  palette), but if a command seems to do nothing "in the chat," that's often why: it already did its
  job without a round trip.
</Callout>

## Three commands that work on every agent [#three-commands-that-work-on-every-agent]

DorkOS runs several coding agents, and each one has its own word for the same everyday actions. DorkOS gives you one word for each, so the command your fingers already know keeps working no matter which agent a session uses. Type any of the aliases below and DorkOS runs the right action.

| Type this  | …or any of these                       | What happens                                                                            |
| ---------- | -------------------------------------- | --------------------------------------------------------------------------------------- |
| `/compact` | `/compress`, `/summarize`              | Shrinks the conversation so you free up room to keep working.                           |
| `/clear`   | `/new`, `/new-chat`                    | Starts a fresh session in the same project; the new session records where it came from. |
| `/context` | `/usage`, `/cost`, `/stats`, `/status` | Shows how much context you've used and what it has cost so far.                         |

The palette lists one row per action, so an agent's own word for it never shows up twice. Type an alias and you'll see a small "matched /…" note telling you which action you're about to run.

`/clear` and `/context` happen right in your browser, with no round trip to the agent. `/compact` asks the agent to do the shrinking, because only the agent can compact its own memory. If the agent you're on can't compact, its `/compact` row is greyed out and marked "Not supported," and typing it just tells you why, instead of quietly sending it as a message.

You can add instructions after `/compact` to guide what the agent keeps — for example, `/compact focus on the API changes`. Claude Code follows them. OpenCode's compaction doesn't take instructions, so on OpenCode the conversation still shrinks but the extra words are ignored.

## The /flow command family [#the-flow-command-family]

`/flow` is the unified workflow engine: one PM-agnostic spine that runs your work from capture to done, no detours. You drive it by hand, one stage at a time, with a command per stage. Each `/flow:<stage>` command is a thin trigger over a stage skill; the top-level `/flow` orchestrator routes a stage, a work item, or the autonomous drain.

The stages run in order. The human-review gate after `VERIFY` has no command: it is the point where you look at the work before it advances.

| Stage     | Command           | What it does                                             |
| --------- | ----------------- | -------------------------------------------------------- |
| CAPTURE   | `/flow:capture`   | Log a thought as a low-commitment work item              |
| TRIAGE    | `/flow:triage`    | Classify and route the item, simple-vs-complex           |
| IDEATE    | `/flow:ideate`    | Shape a brief into a structured ideation artifact        |
| SPECIFY   | `/flow:specify`   | Turn ideation into a validated specification             |
| DECOMPOSE | `/flow:decompose` | Break the spec into tasks and mirror them to the tracker |
| EXECUTE   | `/flow:execute`   | Implement the spec in an isolated worktree               |
| VERIFY    | `/flow:verify`    | Verify the work, gather proof, hand off to review        |
| REVIEW    | (human gate)      | You review before the item advances; no command          |
| DONE      | `/flow:done`      | Report completion, close the item, check follow-ups      |

Three more commands sit beside the spine. They observe or steer, never advance a stage:

| Command        | What it does                                                      |
| -------------- | ----------------------------------------------------------------- |
| `/flow:status` | One pane: in-flight items, parked questions, the assumption trail |
| `/flow:pause`  | Halt every autonomous mode at once                                |
| `/flow:resume` | Restore what `pause` halted                                       |

<Callout type="info">
  The stage and operator commands live in the `flow/` namespace, so they appear in the palette as
  `/flow:capture`, `/flow:status`, and so on. `/flow` itself is the orchestrator entry point that
  routes among them. To run the whole loop autonomously, see [Turning on the automatic
  loop](/docs/guides/flow/turning-on-autonomy).
</Callout>

## Command Discovery [#command-discovery]

The palette shows more than your project's commands. It also includes built-in commands like `/compact`, `/help`, and `/clear`, plus any commands you've defined on your machine in `~/.claude/commands/`, plus your project's own skills. The agent itself supplies this full list; DorkOS's project scanner then adds a couple of extra details, like which tools a command is allowed to use, for any command backed by a file in your project.

Your project commands live in `.claude/commands/`. A file directly inside that folder becomes a top-level command, and a file inside a named subfolder becomes a namespaced command using a `namespace:command` pattern:

<Files>
  <Folder name=".claude">
    <Folder name="commands">
      <File name="greet.md" />

      <Folder name="docs">
        <File name="reconcile.md" />

        <File name="status.md" />
      </Folder>

      <Folder name="flow">
        <File name="specify.md" />

        <File name="execute.md" />
      </Folder>
    </Folder>
  </Folder>
</Files>

| File                | Command           |
| ------------------- | ----------------- |
| `greet.md`          | `/greet`          |
| `docs/reconcile.md` | `/docs:reconcile` |
| `docs/status.md`    | `/docs:status`    |
| `flow/specify.md`   | `/flow:specify`   |
| `flow/execute.md`   | `/flow:execute`   |

<Callout type="info">
  A command file at the top level of `commands/` (no subfolder) appears in the palette with no
  namespace prefix, like `/greet`. Put it inside a named subfolder instead, and it appears as
  `namespace:command`, like `/docs:reconcile`.
</Callout>

## Reference: command file format [#reference-command-file-format]

Most people never touch frontmatter directly. A command works fine with just a `description` and, optionally, an `argument-hint`. Here is the full format, for when you want more control over how your own command behaves.

Commands are Markdown files with optional YAML frontmatter:

```markdown
---
description: Check developer guides for documentation drift
argument-hint: '[guide-name | --all]'
allowed-tools: Read, Grep, Glob, Bash
---

# Documentation Reconciliation

[Instructions for Claude to follow...]
```

### Frontmatter Fields [#frontmatter-fields]

<TypeTable
  type="{
  description: {
    type: 'string',
    description: 'Short description shown in the command palette',
    default: &#x22;''&#x22;,
  },
  'argument-hint': {
    type: 'string',
    description: &#x22;Placeholder text for command arguments (e.g. '[guide-name | --all]')&#x22;,
  },
  'allowed-tools': {
    type: 'string',
    description:
      &#x22;Comma-separated list of tools this command may use (e.g. 'Read, Grep, Glob, Bash')&#x22;,
  },
  'user-invocable': {
    type: 'boolean',
    description: 'Whether the command appears in the `/` palette at all',
    default: 'true',
  },
  'disable-model-invocation': {
    type: 'boolean',
    description:
      'Stop the agent from running this command on its own; only a person can trigger it',
  },
  context: {
    type: '&#x22;fork&#x22;',
    description: 'Run the command in an isolated subagent instead of the main conversation',
  },
  agent: {
    type: 'string',
    description: 'Which subagent type to use when `context` is `&#x22;fork&#x22;`',
  },
  model: {
    type: 'string',
    description: 'Override which model runs this command',
  },
  effort: {
    type: '&#x22;low&#x22; | &#x22;medium&#x22; | &#x22;high&#x22; | &#x22;max&#x22;',
    description: 'Override how much effort the model spends on this command',
  },
}"
/>

<Callout type="warn">
  If your frontmatter values contain special YAML characters (brackets, colons, pipes), wrap them in
  quotes. DorkOS includes a fallback parser for malformed YAML, but quoting is more reliable.
</Callout>

## Creating Custom Commands [#creating-custom-commands]

<Steps>
  <Step>
    ### Create the directory structure [#create-the-directory-structure]

    Create a namespace directory inside `.claude/commands/`:

    ```bash
    mkdir -p .claude/commands/mytools
    ```
  </Step>

  <Step>
    ### Write the command file [#write-the-command-file]

    Create a Markdown file with frontmatter and instructions:

    ```bash
    cat > .claude/commands/mytools/greet.md << 'EOF'
    ---
    description: Generate a greeting
    argument-hint: '[name]'
    allowed-tools: Read, Bash
    ---

    # Greeting Generator

    Say hello to the user by name.
    EOF
    ```
  </Step>

  <Step>
    ### Refresh the command list [#refresh-the-command-list]

    DorkOS caches the discovered commands for 5 minutes (a server restart also clears the cache). To see a new command right away, click the refresh button in the command palette, or call the API with `?refresh=true`.
  </Step>
</Steps>

## Reference: API [#reference-api]

```bash
# List all discovered commands
curl http://localhost:4242/api/commands

# Force refresh the command cache
curl http://localhost:4242/api/commands?refresh=true
```

The response includes a `lastScanned` timestamp and an array of `commands`, each with `namespace`, `command`, `fullCommand`, `description`, `argumentHint`, `aliases` (other names that also trigger this command, like `/cost` and `/stats` both meaning `/usage`), `allowedTools`, and `filePath`.

## Next Steps [#next-steps]

<Cards>
  <Card title="The /flow workflow" href="/docs/guides/flow/what-flow-is">
    Drive product work from capture to done with the unified /flow engine.
  </Card>

  <Card title="Tool Approval" href="/docs/guides/tool-approval">
    Control which tools your commands can use.
  </Card>

  <Card title="Keyboard Shortcuts" href="/docs/guides/keyboard-shortcuts">
    Speed up your workflow with keyboard shortcuts.
  </Card>

  <Card title="CLI Usage" href="/docs/guides/cli-usage">
    Configure the DorkOS CLI for your project.
  </Card>
</Cards>