Your First Fleet

A guided tour of the things worth trying first, roughly in order. Each builds on the last. Assumes you've installed agents-fleet and skimmed the Core Concepts.

Every command below is documented in full in the Commands Manual. Type / + Tab in the REPL for the interactive picker.

1. /init — let the fleet understand your codebase

❯ /init

Spawns seven explorers + one adversarial critic. Each explorer investigates a different domain (architecture, build, patterns, decisions, dependencies, APIs, security); the critic challenges every finding. Results land in .fleet/context/ and auto-load in every future session. Run this first on any new project.

2. /research — deep adversarial investigation

❯ /research "best approach to add caching in this codebase"

Spawns four researchers (primary, counter-argument, context, edge-cases) plus a critic that verifies every claim against actual source. Use this before committing to a design.

3. /feature — plan and build a feature

❯ /feature "Add rate limiting to the API endpoints"

Runs the multi-phase planning pipeline: brainstorm → requirements → research → design (parallel proposals, one critic picks the best) → validation → definition-of-done → task breakdown. Since v0.25.0 the brainstorm phase treats your description as authoritative and deepens it rather than re-asking from scratch.

4. /start — watch the fleet execute

❯ /start

After planning, this kicks off autonomous execution: workers spawn for all ready tasks (up to 12 in parallel), blocked tasks auto-unblock as dependencies complete, coder workers get isolated worktrees, and the loop runs until every Definition-of-Done item passes. Monitor with /tasks, /workers, /dod, /tokens.

5. /code-review — four reviewers in parallel

❯ /code-review

Spawns four specialized reviewers at once — 🔒 security, 🐛 correctness, 🏗️ architecture, ⚡ performance — and synthesizes their findings into one actionable report.

6. Autopilots — end-to-end, hands-off loops

Autopilots chain investigate → fix → test → review → PR into a single self-driving run. They're ideal for unattended work:

❯ /bug-autopilot "users get a 500 when the cart is empty"
❯ /github-issue-worker-autopilot          # triage open GitHub issues → fix → ship draft PRs
❯ /code-review-autopilot --scope=diff     # iterative review-and-fix loop on your diff

/bug-autopilot reproduces the bug, fixes it, adds a regression test, runs a review loop, opens a PR, waits for your approval, and merges. These run deterministically in-process and report progress back through the coordinator — watch them with /status. (Pair with Telegram steering to approve PRs from your phone.)

7. Goal-driven loops

When you want the fleet to keep working toward a free-form goal — even with no tasks tracked yet — use a loop:

❯ /loop "polish the docs until they're release-ready" 30m
❯ /loop-target 30m "finish the auth module" --unattended   # --unattended required under --provider claude

Each cycle the coordinator decides whether to create tasks, spawn workers, or signal completion. Ticks fire on coordinator idle, so the interval is a minimum delay, not a strict period.

8. /compete — build it three ways, pick the best

❯ /compete "implement the search feature"

Three workers build the same feature independently in separate worktrees, then a judge scores correctness, performance, and quality. You merge the winner.

9. /crew — activate a specialized team

❯ /crews                  # browse available crews
❯ /crew code-review-crew  # activate
❯ /crew stop              # deactivate

When a crew is active, workers use crew-specific prompts (not generic defaults) and the intelligence system tracks per-skill performance. Author your own by dropping a file in .fleet/crews/ — see Crews — Getting Started.

10. /learn — see what the fleet has learned

❯ /learn overview          # session insights + pending suggestions
❯ /learn evolve <crew>     # propose skill-prompt improvements from telemetry
❯ /learn dashboard <crew>  # before/after evolution metrics
❯ /learn shadows           # shadow proposals with win/loss stats
❯ /learn promote <skill>   # promote a winning shadow to live

The intelligence pipeline tracks every session — success rates, error patterns, duration trends — and proposes data-driven improvements to agent prompts, which you can validate with A/B eval before committing. See Fleet Intelligence.

Bonus: tune the engine

❯ /models    # interactive model picker
❯ /effort    # reasoning depth: low → medium → high → xhigh
❯ /doctor    # environment + provider-auth health check

What to do next

1. Run /init on your project if you haven't — it pays for itself immediately.
2. Try /research on a design question you've been mulling.
3. Use /feature for your next real feature and go through the full pipeline.
4. Activate a crew and run /code-review to feel the difference specialized prompts make.
5. Check /learn overview after a few sessions and watch the system spot patterns.

For the full mental model, revisit Core Concepts; for an end-to-end walkthrough, see the Orchestration Tutorial.