1. Find the index:

   Glob

   for

   **/fleet/FLEET-INDEX.md

   (or look in the same parent dir as this skill)
2. Read

   FLEET-INDEX.md

   — it has a table of all fleet types with one-liner hints on when to use each
3. Based on the hints, pick the best fleet type for the user's task
4. Then read ONLY the chosen fleet's

   SKILL.md

   for the full schema:

   Glob

   for

   **/<chosen-fleet>/SKILL.md

Where should I place the fleet root? (Press enter for default)

• If the user provides a path → use it
• If the user ignores, says "default", or doesn't respond → use:

  fleet-{YYYYMMDD-HHMMSS}-{fleet-name}/

  in the current working directory

{
  "fleet_name": "<descriptive-kebab-case-name>",
  "type": "<worktree|dag|iterative>",
  "config": {
    "max_concurrent": 3,
    "model": "sonnet",
    "fallback_model": "haiku",
    "provider": "claude",
    "reasoning_effort": ""
  },
  "workers": [...]
}

• config.provider

  —

  "claude"

  (default) or

  "codex"

  . Per-worker override:

  worker.provider

  .

• config.reasoning_effort

  —

  "low"

  ,

  "medium"

  , or

  "high"

  (codex only). Per-worker override:

  worker.reasoning_effort

  .
• When

  provider: "codex"

  , the

  fallback_model

  field is ignored (codex has no fallback).
• When

  provider: "codex"

  ,

  max_budget_usd

  is NOT enforced per-worker (codex has no budget flag). Fleet-level cost tracking still works via token estimation.

• Every worker MUST have

  target_files

  (array of file globs) and

  branch

  (unique branch name)
• No two workers can have overlapping target_files
• Default worker type:

  code-run

  (worktree workers need Bash for git commit)

• Exactly one worker with

  type: "reviewer"

  (use

  depends_on

  to ensure it runs after builders)
• Must include

  stop_when

  block with at least

  max_iterations

  and

  reviewer_lgtm_count

• Workers have

  max_budget_per_iter

  instead of

  max_budget_usd

• Use

  depends_on: ["worker-id"]

  for dependency ordering
• Workers without dependencies run in parallel

$FLEET_ROOT/workers/{id}/prompt.md

1. Clear task description — what to do, in specific terms
2. Scope boundaries — what files to touch, what NOT to touch

• Do NOT include a "Save ALL output to output/" line. The worker edits files in its worktree at the real repo paths.
• MUST include at the end:

  When you are done, commit your changes on the current branch with a descriptive message.

• Workers that produce artifacts (research, summaries, matrices) → include:

  Save ALL output files to $FLEET_ROOT/workers/{id}/output/ — use absolute paths.

• Workers that edit repo files (code changes, creating docs at specific paths) → tell them the exact target path. Do NOT also mention output/. One destination only.

• Same as dag-fleet: if the deliverable is a specific file, give the exact path. Do not also mention output/.
• Reviewer prompt MUST include verdict-writing instructions. Without these, the reviewer won't write a verdict file and the orchestrator defaults to

  iterate

  , wasting an iteration. Every reviewer prompt.md must end with:

  ## Writing your verdict
  
  1. Determine the current iteration number: list the `iterations/` directory and find the
     highest-numbered subdirectory that does NOT yet contain a `review.md`.
  2. Write your verdict to `iterations/<N>/review.md` (relative to your working directory).
     **Never use absolute paths.**
  3. The file MUST contain a line exactly like one of:
     - `verdict: lgtm`
     - `verdict: iterate`
     - `verdict: escalate`
  4. Below the verdict line, list **actionable fix instructions** per worker — not just
     what's wrong, but exactly where and how to fix it (file path, function name, what
     to change). 2-3 precise points per worker. The builder sees this on next iteration,
     so vague feedback wastes a cycle.

  This is non-negotiable. Fleet 02 burned an iteration because the reviewer prompt didn't specify where/how to write the verdict.

1. Plan summary — what each worker does (a table)
2. Fleet type chosen and why
3. Launch command:

   bash <path-to-fleet-skill>/scripts/launch.sh <fleet-root>

   For worktree-fleet, suggest

   --dry-run

   first.
4. Status command:

   bash <path-to-fleet-skill>/scripts/status.sh <fleet-root>