Build

Missions

Give Excalibur a goal and it plans and drives the whole cycle — interpret → understand → build → verify → ship — autonomously, with a live plan, checkpoint/resume and a budget ceiling.

A mission is the meta-orchestrator. Hand Excalibur a big, multi-faceted goal and it doesn't just write code: it interprets the goal, auto-authors a plan (a graph of capabilities), and drives it end to end — adapting after every step. It's the command form of the whole product cycle the rest of the docs describe.

excalibur mission "add rate limiting to the public API, with tests and docs"

In the m-shell you don't need the command — a big, multi-part goal routes to a mission on its own.

What it does

From the goal, Excalibur derives the capability DAG and runs it, and each capability fires its own dedicated engine — not a generic prompt:

CapabilityWhat runs
Understandthe read-only scope fan-out → a map of subsystems, built-vs-missing and risks
Plana concrete, step-by-step implementation plan
Builda focused run, or a swarm of parallel agents when the work splits, or best-of-N rival approaches
Verifythe adversarial verification mesh + your tests — a real gate
Shipcommit the change — or open a pull request with --pr

What it understood up front is threaded into every later step, so the plan and the build are grounded in your real code.

excalibur — mission
mission: add rate limiting to the public API, with tests and docs
interpreted · risk: medium · 5 capabilities
understand mapped the gateway · 2 subsystems · 3 risks
implement edit src/api/limiter.ts +48 −4
verify mesh: 0 blocking issues · tests 124 passing
ship committed · (use --pr to open a PR)
✓ mission complete

It adapts as it goes

A mission isn't a fixed checklist. After each gate or failure it reassesses and picks the next move — retry, escalate a single run into a swarm, replan, skip a superseded step, or finish — so a wrong turn self-heals instead of dead-ending. A live plan ribbon stays pinned above the run, showing every capability's status (✓ ◐ ○ ✗) as it advances.

Long jobs: checkpoint, budget, resume

Missions are built for work that doesn't finish in one sitting:

  • Checkpointed — state is saved to .excalibur/missions/<id>/ after every step.
  • Budget ceiling--budget <usd> pauses the mission (resumably) the moment spend hits the cap.
  • Resumable — pick a paused mission back up where it left off; the completed prefix isn't re-run.
excalibur mission "migrate the billing service to the new schema" --budget 5
excalibur mission "ship the export feature end to end" --pr

Missions vs. swarm vs. orchestrate

Three different things — don't confuse them:

Who plans itWhat it is
MissionExcalibur, from your goalthe full cycle, auto-authored and driven
Swarm (swarm)the planner sizes itparallel agents over the independent parts of one task
Orchestrate (orchestrate --spec)you, in YAMLa deterministic DAG you authored

Next

  • Workflows — the phase recipes a build runs through.
  • Discovery — deciding whether to build, before a mission.
  • Safety — the gates and the --pr opt-in.