Orchestration Tutorial: Commands, Workflows & Crews Together

A cookbook-style walkthrough that takes you from your first /init to authoring custom workflows and crews. By the end you should be comfortable deciding when to use a bundled flow vs. authoring your own.

If you want reference details, see:

• docs/commands-manual.md — every slash command
• docs/workflows-reference.md — workflow file format
• docs/crews-reference.md — crew file format
• docs/composition.md — skills + role+skills composition

---

Who this is for

You've installed agents-fleet, you've launched the REPL once, and now you want a working mental model of how slash commands, workflow files, and crews fit together — not just a list of features. This tutorial walks the same ground a new contributor would walk during their first week: kick the tires on the bundled commands, then write your own workflow and your own crew, then learn how to keep both healthy as your project grows.

You do not need to read it back-to-front. Parts 1–4 cover the bundled flows; Parts 5–6 are the "I want to customize" core; Parts 7–10 are the operational and intelligence surfaces.

---

The mental model

Three concepts. Read top to bottom.

   Commands  ──►  /feature, /code-review, /init, /research, /loop, …
       │
       │  consult the active crew's `workflows:` map
       ▼
    Crews    ──►  default · code-review-crew · research-crew · init-crew · <yours>
       │              workflow: <default>  +  workflows: { <cmd>: <override> }
       ▼
   Workflows ──►  feature-pipeline · code-review · adversarial-research
                  init-investigation · planning · freeform · <yours>
                       │ stages[] with artifact?, workers_required?
                       ▼
                  Workers run the stages    →    Tasks (DAG)

Things to internalize:

1. Commands sit on top. Most user-facing commands are workflow-driven — they don't own their phase list, they resolve a workflow at runtime.
2. Crews are the routing layer. The active crew (if any) gets to swap the workflow a command uses via its workflows: frontmatter map (see Part 6). With no crew active, commands use their bundled defaults.
3. Workflows define stages. A stage names the agents to spawn, whether to run in parallel, and optionally the artifact it must produce.
4. Workers do the work; tasks express dependencies. The same task DAG (task_create / get_ready_tasks) is used regardless of which command spawned the work.

If you remember nothing else: the workflow file is the single source of truth for what /feature, /code-review, /init, and /research actually do. Editing those files (or activating a crew that overrides them) changes behavior without touching command code.

---

Part 1 — Your first session

Pick a real project. Start the REPL from the repo root:

cd path/to/your/project
agents-fleet

❯ Type a prompt or /command... (/ + Tab for commands)
  model: claude-opus-4.6  workers: 12                    ✦ agents-fleet v0.36.3

1.1 Investigate the codebase: /init

❯ /init

This runs the init-investigation workflow:

• Stage 1 — investigate (parallel): 7 explorer workers (init-arch-explorer, init-build-explorer, init-pattern-explorer, init-decision-explorer, init-dep-explorer, init-api-explorer, init-security-explorer) each investigate one domain in parallel.
• Stage 2 — critic: init-critic cross-references claims against actual source.
• Stage 3 — synthesize: the coordinator writes the final artifacts to .fleet/context/ — one markdown per domain plus FLEET.md (one-page summary), profile.json (machine-readable), and scopes.json (logical scope → file map).

These files auto-load on every subsequent fleet session, so workers start with verified project knowledge instead of re-investigating.

1.2 Confirm context is loaded

❯ /context-status               # was /init status
  📂 .fleet/context/ exists
  ✓ FLEET.md (1.4 KB)
  ✓ profile.json (json, 7 keys)
  ✓ scopes.json (json, 4 scopes)
  Scopes: all, backend, frontend, cli

❯ /context-scopes               # was /init scopes
  Available scopes:
    • all       — every source file (default)
    • backend   — src/server/**, src/db/**
    • frontend  — src/app/**, src/components/**
    • cli       — src/commands/**, src/repl/**

❯ /context-load backend         # was /init load backend
  ✓ Loaded scope: backend (143 files)

/context-load <scope> injects the named scope's file list into the coordinator's working context so subsequent workers focus there. Re-run with a different scope at any time.

1.3 Check the coordinator is healthy: /diagnose

❯ /diagnose
🩺 Coordinator diagnostics
  Session: active (provider: copilot, model: claude-opus-4.6)
  isProcessing: false   |   queue in-flight: 0
  Last SDK activity: 2.3s ago
  Watchdog: armed (60s threshold)
  Send-queue hang detector: armed (60 min threshold)
  Mailboxes with backlog: none
  Active scheduler: none

❯ /diagnose --json
{ "coordinator": { … redacted … } }

/diagnose reports live runtime state — distinct from /doctor, which checks your install/env. --json is PII-redacted so it's safe to paste into a bug report.

---

Part 2 — Plan a small feature with /feature

You're going to add a health-check endpoint. Type:

❯ /feature add health check endpoint

What you see (abbreviated):

  🎯 Feature Planning: add health check endpoint
  Plan: .plans/add-health-check-endpoint/
  Workflow: feature-pipeline (7 stages, default)
  ✓ Project context loaded from .fleet/context/
  7 phases — each runs with your input:

    1. Brainstorm        → 01-brainstorming.md
    2. Requirements      → 02-requirements.md
    3. Research          → 03-research.md
    4. Design            → 04-technical-design.md
    5. Validation        → 05-validation.md
    6. Dod               → 06-definition-of-done.md
    7. Tasks             → 07-task-breakdown.md

  ━━━ Phase 1: Brainstorm ━━━

  > I read .fleet/context/FLEET.md and src/server/. Three quick questions:
  > 1) Should /health include downstream DB liveness or be process-only?
  > 2) Is there an existing 503 contract anywhere we should mirror?
  > 3) Auth: should /health be public or admin-only?

You answer each question. The coordinator writes .plans/add-health-check-endpoint/01-brainstorming.md. Each subsequent phase consumes the previous artifact and produces the next one:

Phase	Artifact	Notes
1 Brainstorm	01-brainstorming.md	What/Why/Where/How/Risks
2 Requirements	02-requirements.md	Numbered FR-/IR-/NFR-
3 Research	03-research.md	4 parallel explorers + critic
4 Design	04-technical-design.md	3 adversarial designers, 1 picks
5 Validation	05-validation.md	3 validators verify design vs. source
6 DoD	06-definition-of-done.md	Each item has a VERIFY: method
7 Tasks	07-task-breakdown.md	Calls task_create per task

The 7-phase list lives in src/skills/bundled/workflows/feature-pipeline.workflow.md; each phase's prompt template lives in the sibling feature-pipeline/<stage>.prompt.md. See docs/workflows-reference.md for the file format and runner semantics.

Resume, re-plan, or skip ahead

❯ /feature add health check endpoint        # auto-resumes existing plan
❯ /feature --new add health check endpoint   # forces fresh slug
❯ /feature --resume add-health-check-endpoint

Stages whose artifact already exists are skipped — except the tasks stage, which re-runs if no tasks were registered for the slug (so task_create actually fires).

Execute the plan

❯ /tasks
  Plan: add-health-check-endpoint   (9 tasks, 0/9 done)
  ── Wave 1: research ──
  T-1  ready    Audit existing /metrics handler           coder
  T-2  ready    Pick health-check library                 explorer
  ── Wave 2: implementation ──
  T-3  blocked  Write GET /health route        ← T-1, T-2
  …

❯ /start
  🚀 Fleet started — 2 workers spawning for ready tasks

❯ /diff             # accumulated diff across worker worktrees so far
❯ /dod              # status of each Definition-of-Done item

/start loops until every DoD item passes; failing items become new fix tasks automatically. /workers shows live worker progress.

---

Part 3 — Code review with a crew

So far you've used the default crew. Activate a specialist crew to change agent personas without changing commands.

❯ /crews
🛠 Crews
  ● code-review-crew    hub · 4 agents · multi-perspective review [bundled]
  ● research-crew       hub · 5 agents · adversarial research      [bundled]
  ● init-crew           hub · 8 agents · /init investigation       [bundled]
  ● agents-fleet-crew   hub · 8 agents · dev crew                  [bundled]

Activate one:

❯ /crew code-review-crew
Crew code-review-crew activated.

Now run the review:

❯ /code-review
  🔍 Code Review — workflow: code-review (default, 2 stages)
  Active crew: code-review-crew

  ━━━ Stage 1: review (parallel) ━━━
  🤖 architecture-reviewer    spawned
  🤖 correctness-reviewer     spawned
  🤖 performance-reviewer     spawned
  🤖 security-reviewer        spawned

  ━━━ Stage 2: synthesize ━━━
  📝 Report written: ./CODE_REVIEW.md

The four reviewers run in parallel, then the coordinator synthesizes a single grouped report at CODE_REVIEW.md (Executive Summary, Critical Issues, Recommendations, full per-reviewer findings for traceability).

Deactivate when done:

❯ /crew stop
Crew deactivated.

Why activate a crew at all? You can run /code-review with no crew active — it still resolves the bundled code-review workflow. Activating code-review-crew matters when (a) the per-reviewer roles should compose specific skills (see docs/composition.md), or (b) you author a custom crew that overrides /code-review to point at a stricter pipeline (see Part 6).

---

Part 4 — Adversarial research

Have a design question you haven't decided on? Investigate before committing:

❯ /research best approach to implement caching in this codebase

This runs the adversarial-research workflow:

• Stage 1 — research (parallel): four researchers attack from different angles: primary-researcher (what exists today), counter-researcher (alternatives not chosen), context-researcher (upstream/downstream deps, history), edge-case-researcher (failure modes, boundaries).
• Stage 2 — critic: research-critic cross-references all four reports against actual source and classifies claims as ✅ Verified, ❌ Corrections, ⚠️ Unverified Assumptions, 🕳️ Gaps, ⚠️ Contradictions.

The coordinator then synthesizes a final report with explicit confidence levels. /research takes a single freeform topic string — there is no --topic flag. Pass everything after the command name as the topic.

---

Part 5 — Authoring a custom workflow

Time to build your own. We'll author a 3-stage release-prep workflow that runs before tagging a release.

Where the file lives

Project tier (committed to git, shared with your team):

.fleet/workflows/release-prep.workflow.md

User tier (personal, applies in every repo):

~/.fleet/workflows/release-prep.workflow.md

Bundled tier ships inside the CLI and is read-only at runtime.

Full file

---
name: release-prep
description: 3-stage release-readiness check (audit → verify → notes)
command: release-prep
command_aliases: [rp, ship]
command_usage: /release-prep <version>
args:
  - name: version
    required: true
    description: Semver tag to prepare, e.g. v0.22.0
stages:
  - name: audit
    agents: [security-reviewer, correctness-reviewer]
    parallel: true
    artifact: 01-audit.md
    workers_required: 2
  - name: verify
    agents: [release-verifier]
    after: [audit]
    artifact: 02-verification.md
  - name: notes
    after: [verify]
    artifact: 03-release-notes.md
version: 1
---

## Release Prep Workflow

Runs a focused pre-release sweep:

### Stage 1 — Audit (parallel, 2 agents)
Spawn `security-reviewer` and `correctness-reviewer` against the diff
between `HEAD` and the most recent tag. Each writes findings to the
shared `01-audit.md` artifact (one section per reviewer).

### Stage 2 — Verify
Spawn the `release-verifier` role. It runs `npm test`, `npm run lint`,
and `npm run build`, then asserts the audit's critical findings are
resolved. Output goes to `02-verification.md`.

### Stage 3 — Notes
The coordinator drafts a `03-release-notes.md` from the diff,
grouped by Changed / Added / Fixed / Security.

The command: field on the frontmatter is the one that matters here — the registry sees it on startup and synthesises a slash command. With this file in place you can immediately type:

> /release-prep v0.22.0

command_aliases: [rp, ship] makes /rp v0.22.0 and /ship v0.22.0 work too. The synthesised command shows up in /help with a tier suffix so operators can tell built-ins from auto-discovered:

> /help
  …
  /release-prep (rp, ship) — 3-stage release-readiness check  [workflow:user]

Security clamp. Project-tier (<cwd>/.fleet/workflows/) auto-discovery is opt-in to prevent cloned repos from injecting commands. Use --trust-project-workflows, set AGENTS_FLEET_TRUST_PROJECT_WORKFLOWS=1, or add "workflowDiscovery": { "trustProjectSources": true } to ~/.fleet/config.json. User-tier (~/.fleet/workflows/) is not gated.

Optional sibling stage prompts

Workflow-driven runners (currently /feature) load each stage's prompt template from a sibling file:

.fleet/workflows/release-prep/
├── audit.prompt.md
├── verify.prompt.md
└── notes.prompt.md

Each file is plain markdown with ${feature}, ${planDir}, and ${context} placeholders that the runner substitutes at stage launch. Unknown placeholders are left untouched so typos surface visibly.

If no sibling prompt file exists for a stage, the stage still runs but receives no template — the coordinator gets only the stage name and any context already in its session. See docs/workflows-reference.md for the full template variable list.

How artifact: and workers_required: matter

The runner uses both fields as retry hints:

• artifact: — after the stage finishes, the runner checks for the file. If missing, it re-runs the stage once with an explicit "you MUST call create to write <artifact>" instruction. If still missing, the pipeline aborts.
• workers_required: — counts new workers spawned during the stage. If > 0 and the count is zero, the runner re-runs with an explicit "you MUST call spawn_worker N times in parallel" instruction.

These are opt-in — stages without them behave normally.

How to invoke

There are three ways to invoke a custom workflow:

1. Directly via auto-discovery (recommended for new commands) — declare a command: field on the workflow's frontmatter and the registry synthesises a slash command that runs the workflow via runWorkflowStages. The Part 5 example above invokes as /release-prep v0.22.0. See docs/workflows-reference.md §Authoring auto-discovered commands for the full security model and collision rules.
2. Through one of the four workflow-driven commands (/feature, /code-review, /research, /init) — activate a crew whose workflows.<command> points at your workflow (see Part 6).
3. Through a freeform crew prompt — activate a crew with workflow: release-prep at the top level. The workflow body is injected into the coordinator's <active-workflow> block as guidance, but stage iteration isn't enforced by a runner — the coordinator follows it because the prompt tells it to.

Common pitfalls

• Sibling prompt missing. /feature prints ✗ Stage <name>: prompt file missing. Expected at: …. Author the file or simplify the workflow.
• workers_required on a single-agent stage. Don't set this if the stage is a single reviewer/synthesizer — you'll trigger spurious retries.
• artifact without filesystem access. explorer and reviewer roles cannot write files. Use general-purpose or coder for any stage with an artifact.
• Two stages with the same artifact filename. The later stage's retry sees the earlier file and falsely concludes "already produced". Use distinct numbered filenames.

---

Part 6 — Authoring a custom crew with workflow override

Part 5 showed the direct way to invoke a workflow — declare command: on the frontmatter and you get a /release-prep slash command for free. The crew-override pattern below is the secondary path: useful when you want a workflow to take over one of the four built-in workflow-driven commands (/feature, /code-review, /research, /init) only while your crew is active.

Now you'll wire the release-prep workflow into a crew and override /feature so it runs your pipeline instead of the bundled one.

Where the file lives

.fleet/crews/release-team.crew.md

Full file

---
name: release-team
description: Release-readiness crew that hijacks /feature for release prep
topology: hub
workflow: freeform
workflows:
  feature: release-prep
coordinator:
  role: default-coordinator
agents:
  - role: security-reviewer
    parallel: true
  - role: correctness-reviewer
    parallel: true
  - role: release-verifier
    after: [security-reviewer, correctness-reviewer]
version: 1
---

# Release Team

A small crew used when prepping a tag. The top-level `workflow: freeform`
keeps day-to-day operation unconstrained; the `workflows: { feature: release-prep }`
override makes `/feature` drive the release-prep pipeline from Part 5 while
this crew is active.

Key fields:

• workflow: freeform is the default workflow injected into the coordinator's <active-workflow> block. Use freeform when you want the crew available for ad-hoc prompts but not enforce stages during free conversation.
• workflows: is a map of slash-command name → workflow name. Keys must be kebab-case (feature, code-review, init, research). Values are resolved at command-invocation time (not crew-parse time), so workflows added later still resolve. Misconfiguration is loud — a typo in workflows.feature surfaces as a hard error, not a silent fallback. See docs/crews-reference.md for the full crew frontmatter spec.

Activate and verify

❯ /crew release-team
Crew release-team activated.

❯ /feature cut v1.3.0 release
  🎯 Feature Planning: cut v1.3.0 release
  Plan: .plans/cut-v1-3-0-release/
  Workflow: release-prep (3 stages, via crew "release-team")
  ⚠ Active crew "release-team" overrides /feature with workflow "release-prep"
    (default: "feature-pipeline").
  …

  ━━━ Phase 1: Audit ━━━
  🤖 security-reviewer    spawned (parallel)
  🤖 correctness-reviewer spawned (parallel)
  …

The banner explicitly states the resolved workflow and prints a yellow ⚠ warning whenever a crew is overriding the bundled default, so you always know which pipeline you're running.

Deactivate when you're done:

❯ /crew stop
Crew deactivated.

❯ /feature add user-settings page
  Workflow: feature-pipeline (7 stages, default)

Back to the bundled pipeline.

The override surface was introduced in T-148 (v0.21.0). See the CHANGELOG entry for that release for the full rationale and the resolution algorithm.

---

Part 7 — Loops and continuous execution

Sometimes you want the fleet to keep evaluating progress on its own. Two shapes of loop:

Task-driven loop (default)

❯ /loop-target 5m

Every 5 minutes the coordinator checks ready tasks and dispatches workers until all tasks are done. Wall-clock interval is a minimum delay, not a strict period (cycles fire on coordinator.idle events).

Goal-driven loop

❯ /loop "polish docs until every public type is annotated" 10m

Each cycle the coordinator decides whether to create tasks, spawn workers, or call signal_loop_complete. Use these for ongoing long-running goals (monitoring a build, batch processing, gradual cleanup) where there's no fixed task list up front.

Required flag under Claude

Under --provider claude, goal-driven loops run with bypassPermissions: true for full-trust agent types. The CLI requires you to acknowledge this with --unattended:

❯ /loop-target 10m "finish auth module"
⚠ Re-run with --unattended:
  /loop-target 10m "finish auth module" --unattended

(Restricted agent types like explorer / reviewer still go through the normal permission gate. The guard is conservative because full-trust types like coder / general-purpose / custom skip it.)

When to use loops — and when not to

Use loops for multi-hour or overnight work toward a clear goal, batch processing, or watch-and-react patterns (build status, test status).

Don't use loops for anything that requires user input mid-cycle (the loop won't pause), exploratory work where the next step depends on your review, or sessions you'll resume later — loops are not persisted across --resume (the schema persists tasks but not active loops). You'll see a one-line dim warning on resume; restart with /loop "<goal>" <interval> manually.

Stop a loop with /loops stop <id> or /loops stop-all.

Autopilots — pre-built continuous workflows

Beyond raw loops, agents-fleet ships autopilot commands that wrap a specific multi-stage workflow in a self-driving loop:

• /fixer-loop — keep the build/tests green by repeatedly diagnosing and fixing failures.
• /github-issue-worker-autopilot — pull ready GitHub issues and drive each to a PR.
• /code-review-autopilot (aliases /cr-auto, /review-loop) — continuously review open changes.
• /bug-autopilot — triage and fix incoming bug reports end-to-end.

These commands run through the workflow-runner sub-coordinator bridge: instead of being emulated by an LLM session, the dispatched workflow executes deterministically in-process via runWorkflowAsSubCoordinator(). Stage-worker reports route to that sub-coordinator (visible in /status and worker views), and each autopilot computes a per-workflow watchdog window so long phases don't trip false-positive auto-aborts. Every autopilot has a killswitch and a --legacy-workflow-dispatch per-call rollback.

See Loops & Autopilots for the full breakdown of each command, when to reach for it, the sub-coord bridge, and the killswitches.

---

Part 8 — Working with very large projects

For multi-milestone projects (a quarter-long refactor across many modules), the "plan everything up front then execute" shape of /feature gets unwieldy. There is no first-class loop/iterate primitive in the workflow YAML today — see docs/workflows-reference.md §Limitations. The pragmatic pattern is to layer loops on top of tasks:

The iterative-chunking pattern

1. Plan high-level with /feature — treat the task breakdown as milestones, not the final task list.

2. Manually break each milestone into a wave via task_create. For each milestone create a verify-milestone-N task with blockedBy: [<all milestone tasks>]; make the next milestone's first task blockedBy: [verify-milestone-N]. The verifier becomes the gate.

3. Spawn a loop that processes one milestone at a time:

   ❯ /loop "Process the next ready milestone wave. Spawn workers for ready
            tasks, wait for the milestone verifier, then move on." 10m

4. Each verify-milestone-N task either marks the milestone done (unblocking the next wave) or creates fix tasks.

A future workflow YAML extension (declarative loop: stages) is tracked in workflows-reference §Limitations — once it lands you'll express this pattern declaratively.

---

Part 9 — Intelligence & evolution

Every session emits telemetry into the intelligence pipeline. The /learn family lets you inspect and act on it.

❯ /learn overview
  Session: <session-id>
  Agent runs: 14  |  Errors: 1  |  Tokens: 248k
  Top suggestions:
    – coder agents fail 40% on src/auth/** (sample: 5)
    – security-reviewer p95 duration 8m12s (vs fleet median 2m41s)

Single-session synthesis

❯ /learn synthesize
  ✓ Steering insights captured for this session.
  ✓ 3 candidate suggestions registered.

Heads up — v0.21.1+ only. /learn synthesize for the current session was broken in v0.21.0 and earlier: worker agent_runs persisted under a fallback timestamp key while synthesize queried under the real session ID. v0.21.1 re-stamps the canonical ID right after the coordinator session is created — see the v0.21.1 CHANGELOG entry for the root cause. On ≤ v0.21.0 you'll see "no agent runs in this session" even when workers ran.

Evolution pipeline

❯ /learn evolve security-reviewer
  📊 Proposed shadow for security-reviewer:
     – tightens "high-signal only" guidance
     – adds OWASP A05/A07 reminders
     [shadow staged — run /learn eval security-reviewer to A/B test]

❯ /learn shadows
  Pending shadows:
    security-reviewer   3 runs   conf 67%   win 2/1

❯ /learn eval security-reviewer
  Running A/B eval … 5/5 complete
  Winner: shadow (4-1, conf 82%)

❯ /learn promote security-reviewer
  ✓ Promoted shadow to live.
  Lands at: .fleet/skills/security-reviewer.skill.md  (project tier)

Where evolved skills land:

• If the original was at the user tier (~/.fleet/skills/) it's promoted there.
• If the original was bundled, the promoted version lands at the project tier (.fleet/skills/) — preserving the bundled original.

This means promotion can only ever add to your project; it never mutates the shipped defaults.

---

Part 10 — Diagnostics & troubleshooting

Live state: /diagnose

❯ /diagnose
🩺 Coordinator diagnostics
  Session: active   isProcessing: true (12s)
  Send-queue in-flight: 1   last resolved: 320ms (ok)
  SDK last activity: 1.2s ago
  Watchdog: armed (60s)
  Mailboxes: coordinator backlog 0
  Active scheduler: loop-target #1 cycle 3 (next in 4m21s)

❯ /diagnose --json > diag.json

--json runs the same probe but redacts PII via PiiRedactor — safe to share verbatim in a bug report.

Common failure modes

Symptom	What it means / what to do
Session send timed out (~60 min)	Send-queue hang detector fired. Recovery should fire automatically (onSessionRecovery). If it doesn't, Ctrl+C and --resume. Threshold is 60 min in v0.27.29+ (was 10 min in v0.21.0, originally 5 min); override via AGENTS_FLEET_HANG_THRESHOLD_MS. See FLEET.md Known Issues.
Worker completed with no output	You assigned a deliverable to an explorer or reviewer — neither has write tools. Re-spawn as general-purpose or coder. Custom roles for write work must declare agent_type: coder or general-purpose.
Connection is closed mid-cycle	Transport-level disconnect. withRecovery should create a fresh session — watch for the 🔄 Session recovered chip. If absent within ~30s, /diagnose and re-launch.
coordinator working (idle 12s) in status bar	Coordinator is busy but SDK hasn't emitted activity for 12s. Usually normal (large-context bursts). Only worry past AGENTS_FLEET_HANG_THRESHOLD_MS.
Tool-call truncation (null / missing args)	Model exhausted output-token budget mid-tool-call. withArgValidation returns { error, retryable: true } so the model self-retries. If chronic, lower /effort or switch model. Use --verbose for arg diagnostics.

Filing a useful bug report

1. /diagnose --json > diag.json
2. Last 100 lines of debug.log from the repo root.
3. The exact command you ran and the partial output.
4. CLI version (/version) and provider (/model).
5. If reproducible: a minimal .fleet/crews/ or .fleet/workflows/ file that triggers it.

---

Appendix A — Decision tree: which workflow when?

If you want to …	Use	Bundled workflow
Plan a feature against a known codebase	/feature <desc>	feature-pipeline
Review code quality	/code-review	code-review
Investigate a topic without making changes	/research <topic>	adversarial-research
Populate .fleet/context/ for a new repo	/init	init-investigation
Strict DoD discipline + adversarial review	crew with workflow: planning	planning
Run a crew with no enforced stages	crew with workflow: freeform	freeform
Override /feature//code-review//init//research	crew workflows: { <cmd>: <name> }	—
Add a custom slash command without touching TS code	declare command: on a workflow file (.fleet/workflows/<name>.workflow.md)	—
Sub-second one-shot fix	/fast-do <task>	(no workflow)
Research + plan + build a task end-to-end	/do <task>	(planning conventions)
Build the same feature 3 ways and judge	/compete <task>	(built-in)
Continuous task execution toward DoD	/start or /loop-target <interval>	task-driven loop
Continuous progress toward a freeform goal	/loop "<goal>" <interval> (+ --unattended under claude)	goal-driven loop
See live coordinator/queue state	/diagnose (--json for redacted output)	—
Check what evolution proposed	/learn shadows / eval / promote	—

The four workflow-driven commands (/feature, /code-review, /init, /research) consult the active crew's workflows: map first and fall back to their bundled default. /loop, /loops, /start, /fast-do, /do, /compete, /diagnose, and /learn are not workflow-driven — they have their own command-specific logic.

---

Appendix B — Glossary

• Artifact — File a workflow stage is expected to produce (artifact: in stage frontmatter). Used by runners for the missing-artifact retry.
• Atomic skill — Reusable knowledge fragment (*.skill.md); no agent_type. Composed into roles. See composition.md.
• Composition — Worker prompt = role (persona) + N atomic skills.
• Coordinator — Long-lived LLM session that dispatches workers.
• Crew — Team definition (*.crew.md): coordinator + roster + topology + default workflow + optional workflows: per-command overrides.
• DoD — Definition of Done. Measurable items with a VERIFY: method; /start loops until each passes.
• Freeform — Workflow with stages: [] (no enforced stages).
• Gates — Optional approval checkpoints on a stage.
• Topology — silent (no inter-agent chat), hub (via coordinator), mesh (peer-to-peer).
• parallel / after — parallel: true runs stage agents simultaneously; after: [stage] or after: all waits.
• Role — Persona (*.role.md): agent_type, optional model, system prompt body. No skills by itself.
• Stage — One step in workflow.stages[]; names agents, parallelism, dependencies, and optional artifact / workers_required.
• Task DAG — Dependency graph built by task_create, consumed by get_ready_tasks. Workers spawn automatically as blockers clear.
• Tier — bundled (in CLI), user (~/.fleet/), project (<repo>/.fleet/). Later tiers override earlier for opt-in files.
• Worker — Short-lived agent session; may run in an isolated git worktree.
• Workflow — Multi-step process (*.workflow.md) — source of truth for what workflow-driven commands execute.
• workers_required — Minimum new workers a stage must spawn; triggers a spawn_worker retry if zero.
• Worktree — Separate git working directory used to isolate a worker's edits. Merges back on success.

---

Built with the bundled workflows and skills shipped in src/skills/bundled/. Once you're comfortable with the patterns above, browse that directory — every bundled artifact is a working template you can copy into your own .fleet/ tree and modify.