Slash Commands Reference

Comprehensive reference for every /command registered in the agents-fleet REPL. Authoritative source: src/commands/registry.ts at HEAD (v0.36.3). Last reconciled against source: every command below cites src/commands/<file>.ts:<line>.
At v0.36.3 the registry ships 68 built-in commands plus 7 bundled auto-discovered workflow commands (/init, /research, /code-review, /bug-autopilot, /code-review-autopilot, /github-issue-worker-autopilot, /fixer-loop). Additional project/user workflow commands may be synthesized at startup — see Workflow-driven commands.

This document covers what each command does, how to invoke it, and what it actually executes in the current build. For deeper feature mechanics, follow the cross-links:

Workflow YAML schema, stage files, bundled workflows → workflows reference
Crew YAML schema, activator lifecycle, bundled crews → crews reference
End-to-end orchestration walkthrough → orchestration-tutorial.md
All CLI flags + environment variables → configuration

Quick index

Command	Category	What it does
`/help`	Utilities	List every registered command with aliases
`/clear`	Utilities	Clear the terminal screen (visual only)
`/exit` (`/quit`, `/q`)	Sessions & diagnostics	Graceful shutdown: extract → synthesize → save → exit
`/version`	Utilities	Print agents-fleet version
`/plan`	Planning	Toggle plan mode
`/sessions`	Sessions & diagnostics	Interactive picker over saved sessions
`/history`	Sessions & diagnostics	Paginated conversation history
`/scroll` (`/more`, `/less`)	Sessions & diagnostics	Open the transcript in `more`
`/compact`	Sessions & diagnostics	Ask coordinator to summarise context
`/resume`	Sessions & diagnostics	Resume by session id (placeholder — use `--resume`)
`/name`	Sessions & diagnostics	Get or set a label for this session
`/doctor` (`/diag`)	Sessions & diagnostics	Environment diagnostics
`/diagnose`	Sessions & diagnostics	Live runtime diagnostics (coordinator, queues, watchdog)
`/stats`	Sessions & diagnostics	Session statistics summary
`/workers`	Workers & tasks	List workers with status + activity
`/stop`	Workers & tasks	Stop a worker by id
`/send`	Workers & tasks	Send a message to a worker
`/broadcast`	Workers & tasks	Send a message to all team members
`/fleet-log` (`/log`, `/activity`)	Workers & tasks	Tail fleet activity log
`/pause-dispatch` (`/pause`)	Workers & tasks	Halt auto task dispatch
`/resume-dispatch` (`/unpause`)	Workers & tasks	Resume auto task dispatch
`/tasks`	Workers & tasks	Task DAG + readiness
`/team`	Workers & tasks	List teams or delegate create/delete/members
`/topology`	Workers & tasks	hub / mesh / silent messaging mode
`/view`	Workers & tasks	Switch chip-strip view (Ink only)
`/skill` (`/sk`)	Crews & skills	Create or list skills
`/skills`	Crews & skills	Show v2 library (roles + skills + workflows)
`/skills-migrate`	Crews & skills	Convert v1 skill/crew files to v2
`/crew`	Crews & skills	Activate / create / generate / rollback / mcp / export / import
`/crews`	Crews & skills	Render v2 crews overview
`/init` (`/investigate`)	Planning	Adversarial codebase investigation → `.fleet/context/`
`/brainstorm` (`/brain`, `/bs`)	Planning	Adversarial pre-feature brainstorming (3 inquisitors grill you)
`/feature` (`/feat`, `/epic`)	Planning	Workflow-driven feature pipeline
`/do`	Planning	research → plan+DoD+tasks → execute (3 phases)
`/fast-do` (`/quick`)	Planning	Skip planning, up to 3 workers, verify, done
`/new-project` (`/kickoff`, `/project`)	Planning	7-phase new-project kickoff
`/start` (`/go`, `/run`)	Planning	Loop-execute the active plan
`/loop-target` (`/auto`, `/execute`, `/loop`)	Planning	Recurring loop, optionally goal-driven
`/loops`	Planning	List / stop active loops
`/compete` (`/race`, `/bakeoff`)	Planning	Parallel impl competition in git worktrees
`/dod` (`/definition-of-done`)	Planning	Show/verify/mark Definition of Done
`/research` (`/investigate-topic`, `/deep-dive`)	Planning	Workflow-driven adversarial research
`/code-review` (`/review`, `/cr`)	Planning	Workflow-driven multi-agent code review
`/fleet-intel` (`/intel`)	Intelligence	Cross-session intel insights from SQLite
`/learn` (`/intelligence`)	Intelligence	Learnings, steering, evolution, dashboard
`/model` (`/m`)	Models & config	Show or switch model
`/models`	Models & config	Interactive model picker
`/effort`	Models & config	Show or set reasoning effort
`/config`	Models & config	Show or update persisted config
`/mcp`	Models & config	Manage MCP server entries
`/tokens` (`/usage`, `/ctx`)	Models & config	Token + context window stats
`/cost`	Models & config	Brief token cost summary
`/diff`	Git & utilities	Show `git diff`
`/commit`	Git & utilities	Stage + commit (delegates to coordinator)
`/copy`	Git & utilities	Copy last assistant message to clipboard
`/worktree` (`/wt`)	Git & utilities	Manage git worktrees
`/docs` (`/doc`)	Utilities	Browse and read the shipped fleet docs in chat
`/restart`	Utilities	Relaunch agents-fleet in a new window with the same flags (Windows-only v1)
`/stall-history`	Sessions & diagnostics	Recent coordinator stall + recovery events from the intel DB
`/experiment` (`/exp`)	Intelligence	Define, run, and report A/B experiments over skills/roles/crews
`/wf`	Workflows	Workflow observability + scaffolding (list runs, drilldown, scaffold, reload)
`/context-tier` (`/context-window`)	Models & config	View or set coordinator/worker context-window caps
`/context-status` (`/init-status`)	Project context	Show project context status (files from `/init`)
`/context-scopes` (`/init-scopes`)	Project context	List `.fleet/context/` scopes
`/context-load` (`/init-load`)	Project context	Load a context scope into the conversation
`/bot-set-token`	Telegram	Persist a Telegram bot token to `~/.fleet/telegram.json`
`/bot-clear-token`	Telegram	Remove the persisted Telegram bot token
`/init` (`/investigate`)	Workflow-driven	Adversarial codebase investigation → `.fleet/context/`
`/research` (`/investigate-topic`, `/deep-dive`)	Workflow-driven	Adversarial deep research
`/code-review` (`/review`, `/cr`)	Workflow-driven	Multi-agent code review
`/bug-autopilot` (`/bugfix-autopilot`)	Workflow-driven	End-to-end bug-fix autopilot (reproduce → fix → review → PR)
`/code-review-autopilot` (`/cr-auto`, `/review-loop`)	Workflow-driven	Iterative review→triage→fix→validate autopilot
`/github-issue-worker-autopilot`	Workflow-driven	GitHub-issue worker autopilot (sub-coordinator bridge)
`/fixer-loop`	Workflow-driven	Iterative fix loop over an existing plan

/loop is not a separate command — it is an alias of /loop-target. The dormant createLoopCommand in src/commands/utilCommand.ts:66 is not wired into the registry.

Conventions

How to invoke

Type /<name> (case-sensitive) at the REPL prompt. Aliases are accepted exactly the same as the canonical name.
Anything not starting with / is forwarded to the coordinator as a prompt.
A bare / or / is rejected by classifyInput (src/commands/registry.ts:153) as malformed-command and surfaces an error instead of being silently sent to the LLM.

Subcommand syntax

Subcommands and flags are space-separated tokens (/feature --new "Add JWT").
The first token after the command is usually the subcommand (/learn evolve, /dod verify).
Free-form text following the subcommand is treated as the remainder argument (/fleet-intel remember <note>).
Quoting ("…") is treated as plain characters — every command splits on whitespace and re-joins the trailing tokens. Quotes are not stripped before tokenisation, but the resulting argument string still works for most commands because the joiner re-collapses spaces.

Reading the syntax notation

<required> — you must supply this token.
[optional] — may be omitted.
a | b | c — pick one.
--flag — boolean flag (presence enables it).
--flag <value> — flag with an argument.

Commands available under `--no-coordinator`

The --no-coordinator startup flag spawns the REPL without a coordinator session. Only commands with type: 'local' (in SlashCommand.type) are safe in that mode — they read or mutate local state only and never call coordinator.sendPrompt / sendAndWait:

/help, /clear, /exit, /version, /sessions, /history, /scroll, /resume, /name, /doctor, /diagnose, /stats, /fleet-log, /skill, /skills, /skills-migrate, /crew, /crews, /model, /models, /effort, /config, /mcp, /tokens, /cost, /diff, /copy, /worktree, /view, /fleet-intel, /learn.

type: 'fleet' commands (e.g. /workers, /feature, /start, /tasks, /team, /topology, /code-review, /research, /init, /dod, /compete, /do, /fast-do, /loop-target, /loops, /new-project) require the fleet manager and/or coordinator. type: 'prompt' commands (/compact, /plan, /commit, /fast-do) compose a prompt and hand it to the coordinator via shouldQuery: true.

Commands that require `--unattended` under `--provider claude`

Goal-driven loops bypass restricted permissions in the Claude SDK code path for full-trust agent types (coder, general-purpose, custom). To prevent surprise:

/loop-target <interval> <goal> — when <goal> is non-empty AND provider === 'claude', the command refuses to start unless --unattended is present (src/commands/projectKickoff.ts:449).
/loop is an alias of /loop-target, so the same rule applies.

Task-driven loops (no goal) and all loops under --provider copilot are unaffected. SEC-2 (v0.19.0) tightened restricted agent types so they no longer bypass permissions even under Claude — but the loop guard remains because full-trust types still do.

Planning & Execution

/brainstorm — pre-feature adversarial brainstorming

Category: Planning & Execution Syntax: /brainstorm "<topic>" [--rounds N] [--agents 0|1|2|3] [--resume <slug>]Aliases: brain, bsType: fleetSource: src/commands/brainstormCommand.ts:847

Pre-feature adversarial brainstorming. Spawns 3 explorer-class "inquisitor" workers (UX / technical / edge-cases angles) in parallel that grill you with sharp questions until you've surfaced unknown assumptions. Produces two artifacts (00-brainstorming.md narrative + 00-brainstorming.context.md machine-readable) that /feature --from-brainstorm <slug> can consume.

Flags:

Flag	Type	Description	Default
`--rounds N`	integer (1..10)	How many rounds of grilling before the auto-summarize gate	`2`
`--agents N`	integer (0..3)	How many inquisitors to spawn in round 1. Drop order if `N < 3`: `edge-cases` first, then `technical`; `ux` is always kept. `--agents 0` = single-coordinator mode (no inquisitor spawn) — useful for cost-sensitive runs and for A/B comparison against the multi-agent default	`3`
`--resume <slug>`	string	Continue a prior brainstorm by slug	—

--unattended is refused (FR-11). /brainstorm is interactive by design; use the two-step /brainstorm → /feature --from-brainstorm flow for the unattended path.

How it works:

Round 1: spawns 3 (or --agents N) inquisitor explorers in parallel via the coordinator.
Harvest: their JSON partial_result payloads are read by the JS layer via a MessageBus tap; deduped (Jaccard ≥ 0.6), prioritized, capped at ≤8 questions.
Grill: each question asked one at a time via the coordinator's askUser (interactive dialog).
Rounds 2+: coordinator-only follow-up questions based on the prior Q/A transcript. Prior user answers are wrapped with wrapUntrusted() before re-feed (FR-23 — prompt-injection defense).
Auto-degrade: if all inquisitors return 0 parseable questions in round 1 (FR-25), the run does NOT abort — it drops to coordinator-only grilling with a yellow warning and dumps raw bodies to .plans/<slug>/.brainstorm-debug.json for inspection.
Termination: after --rounds N rounds, the user is asked "summarize or keep grilling?". The loop exits on "summarize".
Synthesis: the coordinator composes both artifacts as JSON; the JS layer writes them atomically with mode: 0o644 (NFR-20) plus a .brainstorm-complete sentinel file (FR-24).

Artifacts produced (under .plans/<slug>/):

00-brainstorming.md — human-readable narrative (transcript, top assumptions, carry-forward hints).
00-brainstorming.context.md — YAML-frontmatter machine-readable companion (qa_pairs, assumptions, open_questions, carry_forward_hints, inquisitor_status). Schema version 1 (FR-18 errors on newer schemas).
.brainstorm-complete — sentinel; absence means the run was interrupted mid-flight.

Examples:

> /brainstorm "build a Slack notification system for /feature releases"
> /brainstorm "auth refactor" --rounds 3
> /brainstorm "topic" --agents 0           # single-coordinator (no inquisitor spawn)
> /brainstorm --resume i-want-to-abc123    # continue prior brainstorm

Common pitfalls:

--unattended is rejected — use /brainstorm then /feature --from-brainstorm <slug> --unattended for the unattended path.
Headless harnesses whose MessageBus stub omits .subscribe() are rejected up-front (DEC-11).

Related: /feature (especially --from-brainstorm and --deep-brainstorm), /init, /research

/feature — workflow-driven feature pipeline

Category: Planning & Execution Syntax: /feature [--new | --resume <slug> | --from-brainstorm <slug> | --deep-brainstorm] <description>Aliases: feat, epicType: fleetSource: src/commands/featureCommand.ts:248

Runs the resolved feature workflow as a sequence of phases (default: brainstorm → requirements → research → design → validation → DoD → tasks). Each phase writes an artifact under .plans/<slug>/ and pauses for ask_user. After phase 7 ends, run /start to begin fleet execution.

Since v0.25.0, Phase 1 treats the description you pass as authoritative: it deepens and clarifies that description instead of asking you to restate what the feature should do from scratch.

Workflow-driven (T-148): the bundled default is feature-pipeline. An active crew may set workflows.feature: <name> in its frontmatter to swap pipelines without touching the handler. The resolved workflow name is printed in the banner and a yellow ⚠ warns when a crew override is active.

Flags:

Flag	Type	Description	Default
`--new`	boolean	Always create a fresh plan dir, bumping `-2`, `-3`, … if the slug exists	off
`--resume <slug>`	string	Resume an existing `.plans/<slug>/`; errors if missing. Description optional	—
`--from-brainstorm <slug>`	string	Seed Phase 1 from a prior standalone `/brainstorm` run (see below)	—
`--deep-brainstorm`	boolean	Run `/brainstorm` inline as Phase 1 of `/feature` (see below)	off

--new, --resume, --from-brainstorm, and --deep-brainstorm are mutually exclusive with each other (any pair is rejected at parse time). The default (no flag) auto-resumes when the slugified description already exists, else creates fresh.

Examples:

> /feature "Add JWT authentication to the API"
🎯 Feature Planning: Add JWT authentication to the API
  Plan: .plans/add-jwt-authentication-to-the-api/
  Workflow: feature-pipeline (7 stages, default)

> /feature --new "Refactor database layer"   # force fresh draft
> /feature --resume add-jwt-authentication   # pick up where you left off

Pre-feature brainstorming flags

/feature integrates with /brainstorm via two flags:

--from-brainstorm <slug>: seed Phase 1 from a prior standalone /brainstorm run. Reads the brainstorm's .context.md, writes a Phase-1 pointer stub at <feature slug>/01-brainstorming.md, and prepends a digest of key Q/A pairs to the Phase 2 (Requirements) prompt. Schema-version-too-new errors are surfaced (FR-18). Use after a standalone brainstorm when you want to defer the feature-spec work.
--deep-brainstorm: runs /brainstorm inline as Phase 1 of /feature. Writes 01-brainstorming.md + 01-brainstorming.context.md directly in the feature's plan dir (NOT a sibling slug — DEC-12). Default --agents 3, --rounds 2. Refuses --unattended since brainstorming requires interactive grilling (use the two-step /brainstorm → /feature --from-brainstorm path for unattended).

These flags are mutually exclusive with each other and with --resume.

Examples:

# Two-step: standalone brainstorm, then feature
> /brainstorm "Slack notify on /feature release"
> /feature slack-notify --from-brainstorm i-want-to-abc123

# One-step: deep brainstorm inline
> /feature slack-notify --deep-brainstorm

Per-stage retries: when a stage declares artifact: <file> and the file is missing after the run, the handler retries once with an explicit create instruction (src/commands/featureCommand.ts:229). Stages with workersRequired: N retry once with an explicit spawn_worker instruction (:207). The tasks stage additionally retries once if task_create was never called (:413).

Common pitfalls:

Without prior /init, the pipeline runs but the prompt context is thinner — phase 3 spawns workers blind. Run /init first for best results.
A typo in workflows.feature on the active crew surfaces a loud ✗ Workflow not found error rather than falling back silently — this is intentional.

Related: /init, /start, /dod, /tasks, /research

/do — 3-phase task pipeline

Category: Planning & Execution Syntax: /do <task>Type: fleetSource: src/commands/doCommand.ts:171

Streamlined pipeline for well-understood changes on existing codebases: research → plan+DoD+tasks → execute+verify. Skips brainstorming and requirements. Creates .plans/<slug>/ artifacts (01-research.md, 06-definition-of-done.md, 07-task-breakdown.md, execution-log.md).

Examples:

> /do "Add JWT authentication"
> /do "Fix the failing tests in auth module"

Common pitfalls:

Phase 3 executes immediately — the coordinator is told NOT to do the implementation itself but to delegate via spawn_worker. Watch /workers to confirm.
For trivial fixes use /fast-do; for full feature planning use /feature.

Related: /feature, /fast-do, /dod, /start

/fast-do — skip planning, just execute

Category: Planning & Execution Syntax: /fast-do <instruction>Aliases: quickType: fleet (composes a shouldQuery prompt) Source: src/commands/fastDoCommand.ts:4

Sends an explicit "FAST-DO mode" override to the coordinator: no adversarial research, no DoD, no task_create, no plan-critic. Up to 3 parallel workers, verify, report in 1-3 sentences. Best for small well-understood tasks.

Examples:

> /fast-do add a .gitignore for node projects
> /fast-do fix the typo in README.md
> /quick rename the utils module to helpers

Common pitfalls:

No task tracking, no DoD — anything you care about reviewing later should use /do or /feature instead.

Related: /do, /feature

/new-project — guided new-project kickoff

Category: Planning & Execution Syntax: /new-project [project-name]Aliases: kickoff, projectType: fleetSource: src/commands/projectKickoff.ts:337

7 interactive phases for building from scratch: brainstorming → requirements → research → adversarial design → validation → DoD → task breakdown. Each phase pauses for ask_user and writes a numbered .md artifact under .plans/<slug>/. After phase 7, run /start.

The difference from /feature is /new-project does not assume an existing codebase — phase 3 researches the problem space rather than the current code.

Examples:

> /new-project "CLI task manager"
> /new-project           # uses "New Project" as the name

Related: /feature, /start, /tasks, /dod

/start — execute the active plan

Category: Planning & Execution Syntax: /start [--plan <slug>] [interval]Aliases: go, runType: fleetSource: src/commands/projectKickoff.ts:936

Begins fleet execution of the active plan's tasks. Loops on a configurable interval (default 30m); each cycle dispatches ready tasks to workers and progressively verifies DoD. The loop auto-stops when all tasks are complete.

Flags:

Flag	Description
`--plan <slug>`	Activate the named plan before starting the loop
`<interval>`	Override loop interval (`30s`, `2m`, `5m`, `1h`)

If no active plan and multiple plans exist in .plans/, an interactive SelectMenu picker appears. If no tasks have been registered for the chosen plan, /start reads <slug>/07-task-breakdown.md (or the legacy 06- filename) and asks the coordinator to load them via task_create before starting the loop.

Examples:

> /start                       # default 30m cycles on active plan
> /start 2m                    # 2-minute cycles
> /start --plan my-feature 5m  # activate plan + 5m cycles

Common pitfalls:

If /start reports No tasks found for plan "X", the /feature Phase 7 likely did not call task_create. Re-run /feature or load manually.
The loop fires on coordinator.idle (T-33). interval is a minimum delay, not a strict period — cycle N+1 cannot start while cycle N is in flight.

Related: /loop-target, /loops, /tasks, /dod

/loop-target — recurring loop, optionally goal-driven

Category: Planning & Execution Syntax: /loop-target <interval> [goal] [--unattended]Aliases: auto, execute, loopType: fleetSource: src/commands/projectKickoff.ts:404

Two modes depending on whether [goal] is supplied:

Task-driven (no goal) — re-prompts the coordinator with current task status each cycle. Auto-stops when all tasks complete. Equivalent to /start with a custom interval but no plan-loading helper.
Goal-driven (free-form goal) — runs even with zero tasks. Cycle prompt asks the coordinator to plan toward the goal each iteration (call task_create, spawn_worker, or signal_loop_complete(reason) to exit).

Flags:

Flag	Description
`--unattended`	Required for goal-driven loops under `--provider claude`. Acknowledges full unrestricted access.

Examples:

> /loop-target 2m
> /loop-target 5m finish implementing the auth module
> /loop-target 30m "polish docs until v0.18.x release" --unattended

Key behaviours:

Interval supports 30s, 1m, 5m, 1h. It is a minimum delay (ticks fire on coordinator.idle after intervalMs elapses).
A 60-min SessionSendQueue hang detector (v0.27.29; was 10 min in v0.20.1, originally 5 min) and a 60-s warn-only CoordinatorWatchdog operate underneath. See /diagnose.
Loops are not persisted across --resume — restart manually after resume; a chalk.dim warning is printed on resume.
Inaction warning: a goal-driven cycle that ends without spawn_worker or task_create prints ⚠ Cycle #N ended without spawning a worker or creating a task. (v0.18.6).
Auto-stop after AGENTS_FLEET_LOOP_MAX_NOOPS (default 3) consecutive no-op cycles (:553).

Common pitfalls:

Forgetting --unattended under Claude produces a red error — read the suggested command and re-run.
An infinite loop on a vague goal (e.g. "improve the docs") may run forever; use /loops stop-all or Ctrl+C to break.

Related: /start, /loops

/loops — list and manage active loops

Category: Planning & Execution Syntax: /loops [stop <id> | stop-all]Type: fleetSource: src/commands/loopsCommand.ts:13

Lists every active loop with id, interval, dispatched-cycles / total-ticks, elapsed, and expiry. Goal-driven loops display the user-supplied goal string (truncated to 80 chars). Stop selectively or all.

Subcommands:

Form	Effect
`/loops`	List all active loops
`/loops stop <id>`	Stop one loop by id
`/loops stop-all`	Stop every active loop

Examples:

> /loops
  🔄 Active Loops
  ● cycle — every 120s | 4 dispatched / 5 ticks | running 612s | expires in never
    goal: finish implementing the auth module

> /loops stop-all
✅ Stopped 1 loop(s).

The dispatched / ticks split (L1) surfaces when the coordinator is wedged: if dispatchedCycles stops climbing while raw scheduler ticks keep firing, the gap is your first signal something is wrong. Confirm with /diagnose.

Related: /loop-target, /start, /diagnose

/compete — adversarial implementation competition

Category: Planning & Execution Syntax: /compete <description> | /compete status | judge | pick <name> | cleanupAliases: race, bakeoffType: fleetSource: src/commands/competeCommand.ts:35

Creates 3 git worktrees and spawns coder workers in parallel: pragmatic (simplest), clean (best architecture), alternative (unconventional). Each implements the same feature in its own worktree, then /compete judge spawns reviewer workers that score on correctness, quality, testing, performance, simplicity, and integration (each 1-5). /compete pick <name> merges the winner and cleans up.

Subcommands:

Form	Effect
`/compete <description>`	Start a new competition (rejects if one already exists)
`/compete status`	Show competition worktrees
`/compete judge`	Spawn reviewers, build comparison table
`/compete pick <name>`	Merge a winner, clean up
`/compete cleanup`	Remove all competition worktrees

Examples:

> /compete "Implement the caching layer"
> /compete status
> /compete judge
> /compete pick pragmatic

Common pitfalls:

Requires git. Returns Not a git repository. /compete requires git. outside a repo.
If a previous competition is still active, you must /compete cleanup before starting another.
pick runs a real merge; conflicts surface as an error and the worktrees are left in place for manual resolution.

Related: /worktree

/dod — Definition of Done

Shows and manages DoD items for the current (or specified) plan. Items track measurable completion criteria with a VERIFY: method (a command to run, a file to check, etc.). Status persists in dod-status.json alongside the DoD file.

Subcommands:

Form	Effect
`/dod`	Show DoD for active plan; if multiple plans, interactive picker
`/dod plans`	List plans that have a DoD file
`/dod verify`	Run automated checks; non-runnable items delegated to coordinator
`/dod pass <id>`	Mark item passed (e.g. `/dod pass 3` or `/dod pass DoD-3`)
`/dod fail <id>`	Mark item failed
`/dod pass-all`	Mark every item passed
`/dod reset`	Clear all verification status
`/dod <plan-name> <sub>`	Operate on a specific plan slug

Examples:

> /dod                     # status view
> /dod verify              # run all `VERIFY:` commands in the allowlist
> /dod pass DoD-3 "manually confirmed"
> /dod my-feature verify   # scope to a specific plan

verify behaviour: only commands in VerifierNode.isAllowed() actually run; others are routed to the coordinator via dod_update. Each run stores exit code, duration, and the (truncated) stderr in dod-status.json.

Common pitfalls:

A VERIFY: line with a command not in the allowlist surfaces a yellow warning in the status view (command "X" not in allowed list) and is silently skipped by verify.
pass <id> accepts both 3 and DoD-3 forms.

Related: /feature, /do, /start

/init — adversarial codebase investigation

Category: Planning & Execution Syntax: /init [refresh | load <scope> | scopes | status]Aliases: investigateType: fleetSource: src/commands/initCommand.ts:40

Spawns explorer agents in parallel to investigate the codebase, then a reviewer-tier critic to challenge their findings, then synthesises results into .fleet/context/. Refuses to re-run if context already exists (use refresh).

Workflow-driven (T-146): the bundled default is init-investigation. Crews may set workflows.init: <name> to override. Workflow resolution runs after the subcommand router, so status / scopes / load cannot fail with a workflow error.

As of v0.22.0 /init honours its resolved workflow end-to-end: the runner walks stages[] via the shared runWorkflowStages in sequential mode (src/commands/initCommand.ts:159-179). Crew overrides change which agents /init actually spawns — previously the override only changed the banner. See workflows reference §Generic stage runner.

Subcommands:

Form	Effect
`/init`	Run full investigation if no context yet; otherwise hint to use `refresh`
`/init refresh`	Re-run, overwriting existing context
`/context-status` (was `/init status`)	List context files. Alias: `/init-status` (deprecated, removal next major)
`/context-scopes` (was `/init scopes`)	List scopes defined in `scopes.json`. Alias: `/init-scopes` (deprecated, removal next major)
`/context-load <scope>` (was `/init load <scope>`)	Load a specific scope into the current conversation (uses `shouldQuery`). Alias: `/init-load` (deprecated, removal next major)

Examples:

> /init                    # first-time investigation
> /init refresh            # re-run after major changes
> /context-status          # what context exists today?
> /context-load backend    # load backend-specific context mid-session

Generated artefacts:

FLEET.md — project summary
profile.json — language / framework / testRunner / packageManager / moduleSystem / conventions / riskAreas
scopes.json — flat { scopeName: [filename, …] } map (or wrapped variants — ContextStore.loadScopes() normalises both shapes; v0.19.0)
Domain-specific analysis files (architecture.md, api-surface.md, build-and-test.md, etc.)

Common pitfalls:

/context-load <bad-scope> returns No context files found for scope "X" if the scope is unknown. Use /context-scopes to list.
Re-running /init refresh does not delete domain files — workers overwrite them. Manually delete .fleet/context/ if you want a true clean slate.

Related: /feature, /research, /code-review

/research — adversarial deep research

Category: Planning & Execution Syntax: /research <topic or question>Aliases: investigate-topic, deep-diveType: fleetSource: src/commands/researchCommand.ts:35

Spawns multiple researcher workers in parallel + a critic. The roster is taken from the resolved workflow's stages: stages with parallel: true contribute researchers; sequential stages contribute the critic. The coordinator synthesises a structured report (summary, verified findings, open questions, assumptions, alternatives, risks, recommendation).

Workflow-driven (T-148): bundled default adversarial-research. Crews override via workflows.research.

Examples:

> /research "best approach to implement auth with JWT vs sessions"
> /research "performance implications of switching from REST to GraphQL"

Output is a coordinator response, not a saved file. Copy the report or /copy it after.

Common pitfalls:

Every researcher is told to flag ⚠️ ASSUMPTION: lines; the critic verifies them against actual source. If the topic has no code in your repo, the critic returns thin results.
Default roster (adversarial-research workflow): primary-researcher, counter-researcher, context-researcher, edge-case-researcher, plus research-critic.

Related: /init, /feature

/code-review — multi-agent code review

Category: Planning & Execution Syntax: /code-review [path, glob, or git range]Aliases: review, crType: fleetSource: src/commands/codeReview.ts:38

Spawns the reviewer roster declared in the resolved workflow (the first stage with a non-empty agents: list — typically the review stage with parallel: true). Each reviewer focuses on a different aspect; the coordinator synthesises a unified report saved to CODE_REVIEW.md.

Workflow-driven (T-148): bundled default code-review. Crews override via workflows.code-review.

Examples:

> /code-review                    # review entire project
> /code-review src/auth           # review a directory
> /cr src/**/*.ts                 # glob (passed verbatim into the prompt)
> /code-review HEAD~1..HEAD       # review files changed between two refs
> /code-review main..feature-branch # review files changed on a branch

Git range parsing uses git rev-parse; if parsing fails, /code-review falls back to path mode, so path-like inputs such as foo..bar.ts still work.

Output: CODE_REVIEW.md at the project root, with Executive Summary (A-F health grade), Critical Issues, Recommendations, Detailed Findings (by reviewer). Since v0.25.0, the CLI waits for reviewer agents to finish synthesising CODE_REVIEW.md before exiting (previously could exit early on long reviews).

Common pitfalls:

A reviewer name in the workflow that does not resolve to a registered skill falls through to a generic Review the code for issues. prompt — surfacing as a thin contribution rather than an error.
Repeated /code-review runs overwrite CODE_REVIEW.md. Move the previous report aside first if you want history.

Related: /init, /research, /dod

/plan — toggle plan mode

Category: Planning & Execution Syntax: /plan [topic]Type: promptSource: src/commands/utilCommand.ts:51

Toggles the coordinator's plan mode. In plan mode the coordinator outlines an approach before executing. With [topic] it enters plan mode focused on that topic; without args it toggles based on current state.

Examples:

> /plan
> /plan auth refactoring

Workers & Tasks

/workers — list workers

Category: Workers & Tasks Syntax: /workersType: fleetSource: src/commands/fleetCommand.ts:4

Shows every worker (active, completed, failed, killed) with its id, agent type, status icon (🔄 spawning, 🟢 running, 💤 idle, ✅ completed, ❌ failed, 🛑 killed), duration, cwd, and last activity description.

Examples:

> /workers
Workers:

  🟢 agent-3f9a (coder) — running [42s]
     📂 .worktrees/worker-agent-3f9a
     editing src/auth/jwt.ts
  ✅ agent-1b22 (explorer) — completed [18s]

Related: /stop, /send, /view

/stop — stop a worker

Category: Workers & Tasks Syntax: /stop <worker-id>Type: fleetSource: src/commands/fleetCommand.ts:46

Terminates a worker by id (full id, not prefix). The worker's task is marked failed; new task assignment continues normally.

Examples:

> /stop agent-abc123
Worker agent-abc123 stopped.

Related: /workers, /pause-dispatch

/send — message a worker

Category: Workers & Tasks Syntax: /send <agent-id> <message>Type: fleetSource: src/commands/fleetCommand.ts:243

Sends a text message to a specific worker via the message bus. Useful for additional context or course-correction mid-task.

5-s ack timeout (T-77): the underlying send_message coordinator tool returns a queued status if the recipient does not ack within 5 s, keeping the coordinator responsive when a worker is busy.

Examples:

> /send agent-abc123 focus on the auth module first
> /send agent-abc123 skip the migration tests

Related: /broadcast, /workers

/broadcast — message all team members

Category: Workers & Tasks Syntax: /broadcast <message>Type: fleetSource: src/commands/fleetCommand.ts:265

Sends a message from coordinator to every team member via MessageBus.broadcast. Reports Broadcast sent to N members. Use for project-wide constraints or announcements.

Examples:

> /broadcast use TypeScript strict mode for all new files
> /broadcast stop working on the deprecated API

/fleet-log — tail fleet activity log

Category: Workers & Tasks Syntax: /fleet-log [lines]Aliases: log, activityType: localSource: src/commands/fleetCommand.ts:67

Shows the last N entries (default 30) from the fleet activity log file, plus the absolute log path and a tail -f hint for external tailing.

Examples:

> /fleet-log         # last 30 entries
> /fleet-log 100     # last 100 entries

/pause-dispatch — halt auto task dispatch

Category: Workers & Tasks Syntax: /pause-dispatchAliases: pauseType: fleetSource: src/commands/fleetCommand.ts:284

Sets state.dispatchPaused = true. New tasks will not be auto-assigned to workers. Currently running workers continue. Idempotent (warns when already paused). Emits dispatch.paused event.

When paused with active workers, output lists them so you know what is still in flight.

Related: /resume-dispatch, /workers

/resume-dispatch — resume auto task dispatch

Category: Workers & Tasks Syntax: /resume-dispatchAliases: unpauseType: fleetSource: src/commands/fleetCommand.ts:315

Sets state.dispatchPaused = false and runs catch-up: every ready task is enumerated and the coordinator is prompted to assign workers. Reports the catch-up count. Emits dispatch.resumed event.

/tasks — task DAG + readiness

Category: Workers & Tasks Syntax: /tasksType: fleetSource: src/commands/taskCommand.ts:4

Shows every task with status (⏳ pending, 🔄 in_progress, ✅ completed, 🚫 blocked, 🗑️ deleted), owner, blocked by deps, blocks deps, plus a tail line listing ready-to-start task ids.

Tasks are created by /feature, /do, /new-project, or directly by the coordinator (task_create).

Related: /start, /dod

/team — team management

Category: Workers & Tasks Syntax: /team [list | create <name> | delete <name> | members <name>]Type: fleetSource: src/commands/teamCommand.ts:4

/team and /team list print every team with member status icons. Other subcommands (create, delete, members) are delegated to the coordinator via shouldQuery — the coordinator decides how to assemble or modify the team. In practice humans rarely drive teams directly; use /broadcast or /crew instead and let the coordinator manage team membership.

Examples:

> /team                  # list teams
> /team create backend   # delegated to coordinator

Related: /workers, /topology

/topology — messaging mode

Category: Workers & Tasks Syntax: /topology [hub | mesh | silent]Type: fleetSource: src/commands/topologyCommand.ts:13

Controls how agents may communicate:

Topology	Behaviour
`hub`	Workers ↔ coordinator only (default)
`mesh`	Workers may send directly to other workers
`silent`	No inter-agent messaging at all

Without arguments, opens an interactive picker. Setting via CLI overrides any crew-defined default — a dim suffix (overrides crew "X" default) is appended when an override is active.

Examples:

> /topology           # picker
> /topology mesh
> /topology hub

/view — switch chip-strip view (Ink only)

Category: Workers & Tasks Syntax: /view [name | agent-id | coordinator | focus]Type: localSource: src/commands/viewCommand.ts:94

Switches the active chip-strip view, lists views, or enters strip-focus mode. Available only in the Ink REPL — emits a friendly warning in non-Ink test harnesses where the chip strip is not initialised.

Form	Effect
`/view`	List views; the active one is marked `●`
`/view <name>`	Switch by agent id, display name, or unique prefix (case-insensitive)
`/view coordinator` (alias `coord`)	Return to coordinator transcript
`/view focus`	Enter strip-focus mode (same as `Ctrl+G`)

Examples:

> /view                 # list
> /view coordinator
> /view worker-3        # exact display name
> /view ag              # unique prefix → first matching worker
> /view focus

Keybindings (chip strip):

Key	Mode	Effect
`Ctrl+]` / `Ctrl+[`	normal	Cycle next/prev chip (canonical — reliable across terminals)
`Ctrl+Tab` / `Ctrl+Shift+Tab`	normal	Cycle (opportunistic — many terminals intercept)
`Esc` (input empty)	normal	Return to coordinator
`Ctrl+G`	normal	Enter strip-focus mode
`←` / `→`	strip-focus	Move chip cursor
`Enter`	strip-focus	Apply cursor as active view
`Esc`	strip-focus	Exit focus without applying
`d` / `Delete`	strip-focus	Dismiss the cursored chip (completed/failed/killed only)
`Shift+D`	strip-focus	Dismiss all terminal chips at once

Common pitfalls:

Worker views are read-only in v1 (v0.16.0). Typing in a worker view and pressing Enter surfaces a quiet hint; the input is never sent anywhere. Steering arrives in v2.
Shift+D and CapsLock+d are indistinguishable (Ink synthesises key.shift=true for any uppercase letter). Use Delete for single-dismiss if Caps Lock is on.

Related: /workers, worker-views.md

Crews & Skills

/skill — create or list skills

Category: Crews & Skills Syntax: /skill create <name> [--type <agent_type>] [--desc <description>] | /skill listAliases: skType: localSource: src/commands/skillCommand.ts:12

Subcommand	Effect
`/skill create <name>`	Generate a `.fleet/skills/<name>.md` template (project tier)
`/skill list` (default)	Show every skill — bundled, user, and project tiers

Flags (for create):

Flag	Default	Description
`--type <agentType>`	`general-purpose`	Agent type — `explorer`, `coder`, `reviewer`, `tester`, `custom`, `general-purpose`, `researcher`
`--desc <description>`	`Custom <name> skill`	Free-form description

Examples:

> /skill list
> /skill create api-tester --type reviewer --desc "Tests API endpoints"
> /sk list

Tier precedence: project > user > bundled. Override a bundled skill by writing a same-named file to .fleet/skills/ (project) or ~/.fleet/skills/ (user).

Related: /skills, /crew, docs/crews-reference.md

/skills — show v2 library

Category: Crews & Skills Syntax: /skills [migrate [--dry-run]]Type: localSource: src/commands/skillCommand.ts:125

Lists the v2 skills library in three sections: Roles (agent role definitions, *.role.md), Atomic Skills (composable units, *.skill.md), Workflows (multi-stage orchestration, *.workflow.md). Each entry shows source tier and metadata.

The migrate subcommand is sugar for /skills-migrate.

Examples:

> /skills                    # show library
> /skills migrate            # convert v1 files in cwd
> /skills migrate --dry-run  # preview without writing

Related: /skill, /skills-migrate, /crews

/skills-migrate — v1 → v2 conversion

Category: Crews & Skills Syntax: /skills-migrate [--dry-run]Type: localSource: src/commands/skillsMigrate.ts:290

Walks {bundled,user,project}/{skills,crews}/, converting v1 .md files to v2: skills become *.role.md (or *.skill.md), crews become *.crew.md. Idempotent — skips files whose v2 target already exists. Leaves originals in place for git mv.

--dry-run prints what would be written without touching disk.

/crew — crews swiss-army

The single entry point for crew management. Without arguments, opens an interactive picker showing every crew, marking the active one and offering a ⏹ Deactivate crew shortcut.

Subcommands:

Form	Effect
`/crew`	Interactive picker (activate / deactivate)
`/crew <name>`	Activate the named crew
`/crew activate [name]`	Direct activation; picker if no name and multiple crews; auto-selects when exactly one crew exists
`/crew stop`	Deactivate the active crew
`/crew list`	Same as `/crews`
`/crew create <name>`	Write a starter template to `.fleet/crews/<name>.md`
`/crew generate <name> [--prompt <text>]`	Synthesize a project-specific crew via the coordinator using optional steering text; `/crew generate <name> -- <steering>` is also supported (writes role / skill / crew bundle to project tier)
`/crew rollback <crew> [skill] [version]`	Show rollback points for a crew, or roll back an evolved skill to a prior version
`/crew mcp <crew>`	Show MCP servers configured for a crew
`/crew mcp <crew> add <server>`	Add an MCP server to a crew's `mcpServers`
`/crew mcp <crew> remove <server>`	Remove an MCP server from a crew
`/crew export <name> [output-path]`	Export a file-based crew (with its roles/skills/workflows) to a `.crew-bundle.zip`
`/crew import <path> [project\|user]`	Import a v2 crew bundle into the project (default) or user tier

Examples:

> /crew list
> /crew code-review-crew
> /crew create my-team
> /crew generate frontend-team --prompt "React + Vite + Tailwind, no SSR"
> /crew generate api-hardening -- focus on REST endpoints under src/api
> /crew rollback research-crew primary-researcher v1
> /crew mcp code-review-crew add github
> /crew export code-review-crew ./code-review.crew-bundle.zip
> /crew import ./shared-team.crew-bundle.zip user

Common pitfalls:

/crew create only generates a v1 template; for v2 authoring, edit by hand or /crew generate.
/crew generate refuses if a bundled crew of the same name already exists (project/user crews are user-owned and overridable).
/crew export requires a file-based crew — bundled crews cannot be exported (use /crew create first to fork them).
Bundle imports validate via importCrewBundleV2; malformed bundles surface a structured Import failed: … error.

Related: /crews, /skills, /topology, docs/crews-reference.md

/crews — render crews overview

Category: Crews & Skills Syntax: /crewsType: localSource: src/commands/crewCommand.ts:642

Renders the v2 crews overview (workflow, topology, coordinator role, per-agent roster) plus a compact view of any remaining v1 crews. The active crew is marked with ● active.

Examples:

> /crews
🛠 Crews

── v2 Crews (3) ──
  code-review-crew ● active [bundled]
  …

Related: /crew

Project Context & Research

/init, /research, and /code-review are all workflow-driven and grouped above under Planning & Execution because they emit plan/report artifacts. They share the crew-override mechanism documented in Workflow-driven commands & crew overrides below.

Intelligence & Learning

/fleet-intel — cross-session intel

Reads the IntelDatabase SQLite store accumulated across past sessions (events, agent_runs, suggestions, search index, skill stats). Useful for spotting recurring failures, expensive agent types, and skill-usage patterns.

Subcommands:

Form	Effect
`/fleet-intel` or `/fleet-intel summary`	Sessions tracked, success rates, top errors
`/fleet-intel agents`	Per-agent-type usage, fail rate, mean duration
`/fleet-intel failures`	Top errors with counts
`/fleet-intel tokens`	Token usage per agent type
`/fleet-intel stats`	Top sessions by tokens, usage trends
`/fleet-intel search <query>`	Free-text search across event history (LIKE-escape sanitised — SEC-NEW-4)
`/fleet-intel skills`	Skill usage frequency + recency
`/fleet-intel remember <note>`	Append a note to `.fleet/context/memory.md`
`/fleet-intel suggest`	Generate suggestions from observed patterns
`/fleet-intel apply <id>`	Apply a suggestion (8-char prefix accepted)
`/fleet-intel dismiss <id>`	Dismiss a suggestion (8-char prefix accepted)
`/fleet-intel insights`	Aliases: `insights`, `insight`, `report` — generate insight report (FR-37)

Examples:

> /fleet-intel agents
> /intel search "auth module"
> /intel remember "JWT tokens expire after 24h in this project"
> /intel suggest
> /intel apply 7c3f9a2b

Related: /learn, /stats

/learn — learnings, steering, evolution

The learning + evolution surface. Extracts steering insights from conversations, generates evolved skill prompts, manages shadow proposals (A/B tests for skills), and provides a dashboard.

Subcommands:

Form	Effect
`/learn` or `/learn overview`	Summary of learnings, steering insights, suggestions
`/learn steering`	Show extracted steering insights by category
`/learn extract`	Extract steering insights from current conversation; persists to `.fleet/context/memory.md`
`/learn synthesize` (aliases `synthesis`, `report`)	Synthesize learnings across sessions into a structured report
`/learn synthesize --all`	Include every session, not just the current one
`/learn evolve`	Generate evolved-skill proposals from outcome data
`/learn dashboard`	Visual dashboard of learning metrics
`/learn shadows`	List active shadow proposals (skill A/B tests)
`/learn eval <skill>`	Run evaluation on a shadow skill
`/learn promote <skill>`	Promote a winning shadow — v2 shadow files go to project tier; legacy DB shadow patches go to user tier
`/learn reject <skill>`	Reject a shadow proposal
`/learn apply <id>`	Apply a suggestion (prefix match)
`/learn dismiss <id>`	Dismiss a suggestion
`/learn clear-memory`	Clear `.fleet/context/memory.md`

Pipeline: extract → evolve → shadows → eval → promote/reject. Steering and evolution can be toggled via /config set steering.enabled <bool> and /config set evolution.enabled <bool>.

Examples:

> /learn                      # overview
> /learn extract              # mine insights from this conversation
> /learn synthesize           # report for this session
> /learn synthesize --all     # report across every session
> /learn evolve               # propose skill improvements
> /learn shadows              # who is A/B testing right now?
> /learn promote api-tester
> /learn dashboard            # visual metrics

Common pitfalls:

Before v0.21.1, /learn synthesize would print "no agent runs in this session" even when workers ran — caused by a session-id mismatch between IntelCollector and the coordinator session. Fixed in v0.21.1 via IntelCollector.setSessionId().
extract returns Steering extraction is disabled unless steering.enabled is true in ~/.fleet/config.json (default: true).

Related: /fleet-intel, /config

/stats — session statistics

Category: Intelligence & Learning Syntax: /statsType: localSource: src/commands/fleetCommand.ts:111

Compact dashboard: session duration, current model + effort, worker counts (completed / active / total), task progress, total tool calls, token totals (input/output, context %), and a one-line intel summary (sessions tracked + success rate).

For granular token data use /tokens; for cross-session intel use /fleet-intel.

Sessions & Diagnostics

/sessions — interactive session picker

Category: Sessions & Diagnostics Syntax: /sessionsType: localSource: src/commands/sessionCommand.ts:6

Opens a searchable picker over the 30 most recent saved sessions (provider, model, task count, msg count, timestamp). Selecting a session prints the agents-fleet --resume <id> command — the actual resume is performed from the CLI startup line, not in-REPL.

Related: /resume, /history

/history — paginated history

Category: Sessions & Diagnostics Syntax: /history [page]Type: localSource: src/commands/sessionCommand.ts:48

Renders the current session's transcript in pages of 5 messages. User prompts, assistant responses, and tool calls are tagged with distinctive markers. Assistant text is rendered through the markdown renderer.

Examples:

> /history        # page 1
> /history 3      # page 3

For long conversations, /scroll is more comfortable.

Category: Sessions & Diagnostics Syntax: /scrollAliases: more, lessType: localSource: src/commands/sessionCommand.ts:113

Writes the transcript to a temp file and opens it in more (works on Windows out of the box; on Unix systems more is also present in the base install). Press q to exit.

/compact — summarise context

Category: Sessions & Diagnostics Syntax: /compactType: promptSource: src/commands/sessionCommand.ts:160

Asks the coordinator to summarise the conversation into a compact context, preserving decisions, task status, and key findings. Run when /tokens shows the context bar trending into yellow/red.

/resume — resume a session by id

Category: Sessions & Diagnostics Syntax: /resume <session-id>Type: localSource: src/commands/sessionCommand.ts:174

Placeholder in-REPL. The actual resume happens at startup: agents-fleet --resume <id>. Use /sessions to copy the id and re-launch.

/name — session label

Category: Sessions & Diagnostics Syntax: /name [label]Type: localSource: src/commands/nameCommand.ts:4

Without arguments, prints the current session name (or a dim hint if unset). With [label], sets the session name — persists into session meta so /sessions shows it.

Examples:

> /name
  Session name: refactor-auth-2026-05

> /name JWT refactor
  Session name set: JWT refactor

/doctor — environment diagnostics

Category: Sessions & Diagnostics Syntax: /doctorAliases: diagType: localSource: src/commands/fleetCommand.ts:177

Static environment checks: Node.js, platform, GitHub CLI presence and auth, current model + effort, session id, worker capacity, memory (RSS + heap), token totals. Each check shows ✓ (pass), ✗ (fail), or ⚠ (warning).

For runtime state (queue depth, in-flight sends, watchdog) use /diagnose.

/diagnose — live runtime diagnostics

Category: Sessions & Diagnostics Syntax: /diagnose [--json]Type: localSource: src/commands/diagnoseCommand.ts:317

Reports what is happening RIGHT NOW inside the running process. Use when the REPL appears stuck or unresponsive. Five sections:

Section	Reports
Coordinator	`isProcessing`, `isDrainingQueue`, `queueLength`, `currentPlan`, `sessionId`, `timeSinceLastActivity` (chalk-coloured)
Session-send queue (`SessionSendQueue`)	`inflightCount`, `lastResolvedAt`, `lastResolvedDuration`
Message bus	mailboxes with backlog + top-5 by depth (per-agent message queues)
SDK events	`lastSdkActivityAt` ISO + ago; recent event type count (not yet tracked)
Watchdog	enabled, threshold ms, time-to-warn, last-triggered timestamp

Examples:

> /diagnose                  # human-readable (chalk-coloured)
> /diagnose --json           # machine-parseable JSON, PII-redacted

--json shape: top-level keys coordinator, sendQueue, messageBus, sdkEvents, watchdog. All free-text fields are passed through PiiRedactor before serialisation, so the output is safe to paste into bug reports.

Watchdog and hang detector:

CoordinatorWatchdog (warn-only): emits coordinator.error if isProcessing=true and no SDK activity for thresholdMs (default 60 s). Killswitch: AGENTS_FLEET_WATCHDOG_DISABLED=1.
SessionSendQueue hang detector: throws FleetError('TIMEOUT') after hangThresholdMs (default 60 min as of v0.27.29; was 10 min in v0.20.1, originally 5 min). On timeout withRecovery triggers onSessionRecovery, which surfaces a 🔄 Session recovered chip (v0.20.0). Override via AGENTS_FLEET_HANG_THRESHOLD_MS or constructor option.

When to use: stuck REPL → /diagnose. Coordinator section + watchdog section tell you whether the session is actually wedged (no SDK activity ≥ threshold while isProcessing=true) or just slow (recent SDK events, deep mailboxes).

Common pitfalls:

/diagnose is read-only — it never aborts, resets, or otherwise mutates state.
lastSdkActivityAt colours: ≤ 30s green, > 30s yellow, ≥ threshold red.

Related: /doctor, /stats

/exit — graceful shutdown

Category: Sessions & Diagnostics Syntax: /exitAliases: quit, qType: localSource: src/commands/utilCommand.ts:20

Exits the CLI through the full graceful-shutdown pipeline (v0.17.0+):

Steering extraction — mine the just-finished session for steering insights
Insight synthesis — distill learnings (capped at 20 s)
Session save — flush the transcript and session state to disk
Exit — process.exit(0)

This pipeline is wired through the onShutdown dependency-injection seam on CommandContext. /exit, /quit, /q, SIGINT (Ctrl+C), and Ctrl+D (v0.17.1 follow-up via handleRequestExit) all run the same pipeline.

In-band status messages (Extracting learnings from N message(s)…, Found N steering insight(s), Insight synthesis complete, Session saved: …) render through the Ink transcript when shutdown is initiated from inside the REPL, so feedback is consistent regardless of exit path.

Fallback: when onShutdown is unavailable (e.g. test harnesses), the command falls back to a bare process.exit(0) without the pipeline.

Models, Tokens & Config

/model — show or switch model

Category: Models, Tokens & Config Syntax: /model [model-name]Aliases: mType: localSource: src/commands/modelCommand.ts:7

Without arguments, prints current model + effort. With a name, calls coordinator.setModel and persists the choice to ~/.fleet/config.json.

Examples:

> /model
  Current model: gpt-5.4
  Effort: high

> /model claude-sonnet-4-5-20250929
  ✓ Model switched to claude-sonnet-4-5-20250929

Claude 1M-context (v0.18.6): append -1m to a Sonnet model id to enable the Anthropic context-1m-2025-08-07 beta header — claude-sonnet-4-5-20250929-1m.

Related: /models, /effort, /tokens

/models — interactive model picker

Category: Models, Tokens & Config Syntax: /modelsType: localSource: src/commands/modelCommand.ts:34

Opens a picker over coordinator.listModels() results. Each entry shows context size (Nk ctx), supported reasoning efforts, and billing multiplier (Nx cost when ≠1). The current model is marked. Selection persists.

/effort — reasoning effort

Category: Models, Tokens & Config Syntax: /effort [low | medium | high | xhigh]Type: localSource: src/commands/systemCommand.ts:120

Without args, opens a picker. With a level, calls coordinator.setReasoningEffort and persists.

Level	Description
`low`	Faster, less thorough
`medium`	Balanced speed and quality
`high`	Thorough reasoning (default)
`xhigh`	Maximum reasoning depth

Note: a model that does not advertise the requested effort will reject the call (e.g. some Claude models don't support reasoning effort tiers — surfaces as Model 'X' does not support reasoning effort).

/config — show or update configuration

Category: Models, Tokens & Config Syntax: /config [set <key> <value>]Type: localSource: src/commands/systemCommand.ts:7

Without arguments, dumps the full runtime + persisted configuration: session (model, maxWorkers, verbose, cwd, activeTeam, planMode), defaults from ~/.fleet/config.json, worktrees, steering, evolution.

Valid keys for set:

Group	Keys
Core	`model`, `reasoningEffort`, `maxWorkers`, `verbose`
Worktrees	`worktrees.enabled`, `worktrees.directory`, `worktrees.symlinkNodeModules`
Steering	`steering.enabled`, `steering.timeoutMs`, `steering.maxInsights`, `steering.maxMessages`, `steering.memoryThreshold`
Evolution	`evolution.enabled`, `evolution.autoEvolve`, `evolution.maxPromptTokens`, `evolution.minSampleSize`, `evolution.confidenceThreshold`, `evolution.rollbackAfterSessions`

Type coercion: boolean keys parse "true"/"false", numeric keys parse via parseInt. Unknown keys are rejected with the full valid list.

Examples:

> /config
> /config set maxWorkers 8
> /config set worktrees.enabled true
> /config set steering.enabled true

Persistence: writes to ~/.fleet/config.json. Runtime session values may differ from persisted defaults (e.g. --model on the command line overrides the persisted default for this session only).

/mcp — manage MCP servers

Category: Models, Tokens & Config Syntax: /mcp list | add <name> <transport> <url-or-command> | remove <name> | statusType: localSource: src/commands/mcpCommand.ts:14

Manages MCP (Model Context Protocol) server entries in ~/.fleet/config.json. Transports: stdio, sse, streamable-http.

Form	Effect
`/mcp list`	Show configured servers (name, transport, endpoint)
`/mcp add <name> <transport> <url-or-cmd>`	Add a server — for `stdio`, the first token is the command and the rest become args
`/mcp remove <name>`	Remove a server
`/mcp status`	Show which servers are active in the current session

Examples:

> /mcp list
> /mcp add my-tools stdio npx my-mcp-server
> /mcp add remote-tools sse http://localhost:3001/sse
> /mcp remove my-tools
> /mcp status

Common pitfalls:

Changes require a session restart to take effect — the message bus and tool routing are bound at session-init time.
Project-level MCP discovery (.mcp.json, .cursor/mcp.json, .vscode/mcp.json, <cwd>/agency.toml) is opt-in as of SEC-1 (v0.19.0). Use --trust-project-mcp or AGENTS_FLEET_MCP_TRUST_PROJECT=1 to load them. User-level sources (~/.config/claude, ~/.cursor, ~/.agency) load unconditionally.

/tokens — token + context usage

Category: Models, Tokens & Config Syntax: /tokensAliases: usage, ctxType: localSource: src/commands/tokensCommand.ts:21

Detailed token usage and context window status. Visual progress bar for the context window (green < 70%, yellow 70-90%, red > 90%), session totals (input/output/total), per-model breakdown (in/out/cache-read/cache-write/calls), and per-agent breakdown sorted by total usage.

For the simpler workers-cost view, use /cost.

/cost — token cost summary

Category: Models, Tokens & Config Syntax: /costType: localSource: src/commands/systemCommand.ts:101

Three-line summary: total workers spawned, active workers, total tokens consumed across all workers. For detailed breakdowns use /tokens.

Git & Utilities

/diff — git diff

Category: Git & Utilities Syntax: /diffType: localSource: src/commands/gitCommand.ts:4

Runs git --no-pager diff and prints uncommitted changes (unstaged only — does not show git diff --staged). For a smarter commit workflow use /commit.

/commit — create a git commit

Category: Git & Utilities Syntax: /commit [message]Type: promptSource: src/commands/gitCommand.ts:24

Delegates to the coordinator:

With a message — git add -A then commit with the supplied message.
Without a message — coordinator reviews git diff and generates a conventional-commit-style message.

> /commit "feat: add JWT authentication"
> /commit                                  # auto-generated message

/copy — copy last assistant message

Category: Git & Utilities Syntax: /copyType: localSource: src/commands/systemCommand.ts:164

Copies the last assistant message to the system clipboard. Platforms:

Platform	Tool used
Windows	`clip` (built-in)
macOS	`pbcopy` (built-in)
Linux	`xclip -selection clipboard` (install separately)

/worktree — git worktree management

Category: Git & Utilities Syntax: /worktree [list | cleanup [--all] | status]Aliases: wtType: localSource: src/commands/worktreeCommand.ts:5

Manages git worktrees used for worker isolation. Each worker can run in its own worktree to avoid conflicts when multiple agents modify files simultaneously.

Subcommand	Effect
`/worktree list` (default)	Show every worktree with name, branch, path
`/worktree cleanup`	Remove `worker`-prefixed worktrees only
`/worktree cleanup --all`	Remove all worktrees (including `compete`)
`/worktree status`	Git version, worker/compete counts, worktrees root

Examples:

> /wt list
> /wt status
> /worktree cleanup --all

Worktrees are created automatically by /compete and by fleet workers when worktrees.enabled is true (/config set worktrees.enabled true).

Related: /compete

/help — list available commands

Category: Git & Utilities Syntax: /helpType: localSource: src/commands/registry.ts:34

Prints every registered command with aliases and short descriptions, in registration order, plus the worker-view keybinding cheat sheet. Auto-discovered workflow commands carry a dim [workflow:<bundled|user|project>] suffix so they are visually distinct from hand-curated built-ins (src/commands/registry.ts:54-58).

/clear — clear the screen

Category: Git & Utilities Syntax: /clearAliases: clsType: localSource: src/commands/utilCommand.ts:6

Writes ANSI clear-screen + cursor-home. Conversation history and session state are unaffected — only the visual display.

/version — show version

Category: Git & Utilities Syntax: /versionType: localSource: src/commands/utilCommand.ts:40

Prints agents-fleet vX.Y.Z from src/version.ts.

Workflow-driven commands & crew overrides

Four commands consult the active crew at invocation time to decide which workflow to run:

Command	Default workflow	Crew override key
`/feature`	`feature-pipeline`	`workflows.feature`
`/code-review`	`code-review`	`workflows.code-review`
`/init`	`init-investigation`	`workflows.init`
`/research`	`adversarial-research`	`workflows.research`

Resolution happens via resolveCommandWorkflow(registry, activator, commandName, bundledDefault) in src/skills/workflowResolver.ts:

If a crew is active AND its workflows.<command> field points at a workflow that resolves → use that workflow.
Otherwise → use the bundled default.
A typo or missing referenced workflow surfaces as a loud error (✗ Workflow not found …), not a silent fallback — misconfigurations don't masquerade as defaults.

Every workflow-driven command prints the resolved workflow name in its banner:

Workflow: feature-pipeline (7 stages, default)

When a crew override is active, a yellow ⚠ warning is also printed:

Workflow: my-feature-pipeline (7 stages, via crew "my-team")
⚠ Active crew "my-team" overrides /feature with workflow "my-feature-pipeline" (default: "feature-pipeline").

For workflow authoring (YAML schema, stage fields, prompt files), see workflows reference. For crew authoring (workflows: map, agent roster, mcpServers), see crews reference.

Shared stage runner. All four workflow-driven commands now delegate stage iteration to runWorkflowStages (src/skills/workflowRunner.ts:194) — /feature runs in per-stage-prompt mode, /code-review in roster mode, and /research / /init in sequential mode. Each mode preserves its command's historical contract while sharing artifact-retry and workers_required-retry semantics. See workflows reference §Generic stage runner.

Auto-discovered slash commands. Any workflow declaring a command: field on its frontmatter synthesises a slash command via the same runner — drop a *.workflow.md with command: release-prep into ~/.fleet/workflows/ and /release-prep is invokable immediately, no TypeScript changes required. Synthesised commands appear in /help with a dim [workflow:<bundled|user|project>] suffix (src/commands/registry.ts:54-58) so operators can distinguish auto-generated commands from built-ins. Project-tier auto-discovery is opt-in via --trust-project-workflows, AGENTS_FLEET_TRUST_PROJECT_WORKFLOWS=1, or workflowDiscovery.trustProjectSources: true in ~/.fleet/config.json (mirrors SEC-1's MCP discovery posture). See workflows reference §Authoring auto-discovered commands.

Bundled auto-discovered commands (v0.36.3). The following ship in src/skills/bundled/workflows/ and are available in every fresh install:

Command	Aliases	Workflow file	Purpose
`/init`	`/investigate`	`init-investigation.workflow.md`	Adversarial codebase investigation → `.fleet/context/`.
`/research`	`/investigate-topic`, `/deep-dive`	`adversarial-research.workflow.md`	Adversarial deep research on a topic.
`/code-review`	`/review`, `/cr`	`code-review.workflow.md`	Multi-agent code review of a path or git range.
`/bug-autopilot`	`/bugfix-autopilot`	`bug-autopilot.workflow.md`	Reproduce → fix → regression-test → review loop → PR → human approval → merge.
`/code-review-autopilot`	`/cr-auto`, `/review-loop`	`code-review-autopilot.workflow.md`	Iterative review → triage → fix → validate until convergence; optional `--ship` PR handoff. Sub-coord-routed (Phase 3c.2).
`/github-issue-worker-autopilot`	—	`github-issue-worker-autopilot.workflow.md`	Drive a GitHub issue to completion via the in-process sub-coordinator bridge (Phase 3c.0).
`/fixer-loop`	—	`fixer-loop.workflow.md`	Iterative fix loop over an existing plan (Phase 3c.1).

The autopilots (/bug-autopilot, /code-review-autopilot, /github-issue-worker-autopilot, /fixer-loop) are long-running and route through the workflow-runner sub-coordinator bridge by default; pass --legacy-workflow-dispatch per call to use the legacy LLM-driven path. See workflows reference for stage details and the dispatch contract.

/init placement caveat: workflow resolution runs after /init's status/scopes/load subcommand router. Those subcommands are pure reads over .fleet/context/ and have nothing to do with the investigation workflow — they cannot fail with a workflow error even if a crew references a missing investigation workflow.

Appendix: command lifecycle

How a slash command flows from input to render. Useful for future contributors.

┌────────────────────┐
│ user types `/x …`  │
└────────┬───────────┘
         │
         ▼
┌──────────────────────────────────────┐
│ classifyInput(input)                 │  src/commands/registry.ts:153
│   → 'command' | 'malformed-command'  │
└────────┬─────────────────────────────┘
         │
         ▼
┌──────────────────────────────────────┐
│ parseSlashCommand(input)             │  src/commands/registry.ts:134
│   → { command, args }                │
└────────┬─────────────────────────────┘
         │
         ▼
┌──────────────────────────────────────┐
│ findCommand(name)                    │  src/commands/registry.ts:128
│   matches by .name or .aliases       │
└────────┬─────────────────────────────┘
         │
         ▼
┌──────────────────────────────────────┐
│ command.handler(args, context)       │  the per-command logic
│   returns CommandResult              │
└────────┬─────────────────────────────┘
         │
         ▼
┌────────────────────────────────────────────────────────────────────┐
│ CommandResult shape (src/types/commands.ts)                        │
│   { output?: string,                  → printed in transcript      │
│     shouldQuery?: boolean,            → if true, send prompt to    │
│     prompt?: string,                    coordinator (next step)    │
│     dialog?: (done) => ReactElement } → Ink dialog (e.g. picker)   │
└────────┬───────────────────────────────────────────────────────────┘
         │
         ▼
┌──────────────────────────────────────┐
│ REPL renders output OR sends prompt  │  Ink: InkRepl.tsx
│ OR mounts dialog                     │  Legacy: Repl.ts
└──────────────────────────────────────┘

Command types (SlashCommand.type):

'local' — runs entirely client-side; never calls the coordinator (/help, /clear, /config, /skill, …).
'fleet' — needs the fleet manager and/or coordinator; reads/writes fleet state (/workers, /feature, /start, /tasks, …).
'prompt' — composes a prompt and returns shouldQuery: true for the REPL to forward to the coordinator (/compact, /plan, /commit, /fast-do).

Why findCommand matters for aliases: the registry stores commands once but exposes them under every name in aliases. /q, /quit, and /exit all resolve to the same SlashCommand object — no per-alias divergence is possible.

Adding a new command: write createXCommand() returning a SlashCommand, export it from src/commands/index.ts, then add it to the commands: SlashCommand[] array in registry.ts. Each command must have a unique name (case-sensitive) — overlapping aliases between commands are not enforced but would lead to surprising shadowing. Add tests alongside the source file (<name>Command.test.ts).

Slash Commands Reference ​

Quick index ​

Conventions ​

How to invoke ​

Subcommand syntax ​

Reading the syntax notation ​

Commands available under --no-coordinator ​

Commands that require --unattended under --provider claude ​

Categories ​

Planning & Execution ​

/brainstorm — pre-feature adversarial brainstorming ​

/feature — workflow-driven feature pipeline ​

Pre-feature brainstorming flags ​

/do — 3-phase task pipeline ​

/fast-do — skip planning, just execute ​

/new-project — guided new-project kickoff ​

/start — execute the active plan ​

/loop-target — recurring loop, optionally goal-driven ​

/loops — list and manage active loops ​

/compete — adversarial implementation competition ​

/dod — Definition of Done ​

/init — adversarial codebase investigation ​

/research — adversarial deep research ​

/code-review — multi-agent code review ​

/plan — toggle plan mode ​

Workers & Tasks ​

/workers — list workers ​

/stop — stop a worker ​

/send — message a worker ​

/broadcast — message all team members ​

/fleet-log — tail fleet activity log ​

/pause-dispatch — halt auto task dispatch ​

/resume-dispatch — resume auto task dispatch ​

/tasks — task DAG + readiness ​

/team — team management ​

/topology — messaging mode ​

/view — switch chip-strip view (Ink only) ​

Crews & Skills ​

/skill — create or list skills ​

/skills — show v2 library ​

/skills-migrate — v1 → v2 conversion ​

/crew — crews swiss-army ​

/crews — render crews overview ​

Project Context & Research ​

Intelligence & Learning ​

/fleet-intel — cross-session intel ​

/learn — learnings, steering, evolution ​

/stats — session statistics ​

Sessions & Diagnostics ​

/sessions — interactive session picker ​

/history — paginated history ​

/scroll — open transcript in a pager ​

/compact — summarise context ​

/resume — resume a session by id ​

/name — session label ​

/doctor — environment diagnostics ​

/diagnose — live runtime diagnostics ​

/exit — graceful shutdown ​

Models, Tokens & Config ​

/model — show or switch model ​

/models — interactive model picker ​

/effort — reasoning effort ​

/config — show or update configuration ​

/mcp — manage MCP servers ​

/tokens — token + context usage ​

/cost — token cost summary ​

Git & Utilities ​

/diff — git diff ​

/commit — create a git commit ​

/copy — copy last assistant message ​

/worktree — git worktree management ​

/help — list available commands ​

/clear — clear the screen ​

/version — show version ​

Workflow-driven commands & crew overrides ​

Appendix: command lifecycle ​

Slash Commands Reference

Quick index

Conventions

How to invoke

Subcommand syntax

Reading the syntax notation

Commands available under `--no-coordinator`

Commands that require `--unattended` under `--provider claude`

Categories

Planning & Execution

/brainstorm — pre-feature adversarial brainstorming

/feature — workflow-driven feature pipeline

Pre-feature brainstorming flags

/do — 3-phase task pipeline

/fast-do — skip planning, just execute

/new-project — guided new-project kickoff

/start — execute the active plan

/loop-target — recurring loop, optionally goal-driven

/loops — list and manage active loops

/compete — adversarial implementation competition

/dod — Definition of Done

/init — adversarial codebase investigation

/research — adversarial deep research

/code-review — multi-agent code review

/plan — toggle plan mode

Workers & Tasks

/workers — list workers

/stop — stop a worker

/send — message a worker

/broadcast — message all team members

/fleet-log — tail fleet activity log

/pause-dispatch — halt auto task dispatch

/resume-dispatch — resume auto task dispatch

/tasks — task DAG + readiness

/team — team management

/topology — messaging mode

/view — switch chip-strip view (Ink only)

Crews & Skills

/skill — create or list skills

/skills — show v2 library

/skills-migrate — v1 → v2 conversion

/crew — crews swiss-army

/crews — render crews overview

Project Context & Research

Intelligence & Learning

/fleet-intel — cross-session intel

/learn — learnings, steering, evolution

/stats — session statistics

Sessions & Diagnostics

/sessions — interactive session picker

/history — paginated history

/scroll — open transcript in a pager

/compact — summarise context

/resume — resume a session by id

/name — session label

/doctor — environment diagnostics

/diagnose — live runtime diagnostics

/exit — graceful shutdown

Models, Tokens & Config

/model — show or switch model

/models — interactive model picker

/effort — reasoning effort

/config — show or update configuration

/mcp — manage MCP servers

/tokens — token + context usage

/cost — token cost summary

Git & Utilities

/diff — git diff

/commit — create a git commit

/copy — copy last assistant message

/worktree — git worktree management

/help — list available commands

/clear — clear the screen

/version — show version

Workflow-driven commands & crew overrides

Appendix: command lifecycle