Drive Fleet

A two-phase workflow for driving a fleet of MRs/PRs to done in parallel with a manager that never touches a working tree. Platform-neutral: all VCS/CI mechanics delegate to /mr and /ci.

When to use

why-not-mechanizable: skill workflow guidance; each step requires understanding the surrounding context (repo, task shape, prior state).

• 2+ independent lanes / multiple MRs, often across sibling repos (review-time: see section note)
• You want a hands-off MANAGER that delegates every edit and only stops when the whole fleet is done (review-time: see section note)
• Not for single-MR work - use /build + /mr directly (review-time: see section note)

The goal condition

The built-in /goal command keeps the session working across turns until the condition holds, then auto-clears. Set it once, in the MANAGER session - it is session-scoped and resets on resume, so a re-planned session re-sets it.

Template (fill the {knobs}):

Every open MR/PR from {plan} is CI-green, reviewed ({review_depth} applied via review-pr), and rebased on {target_branch}. {post_completion_action}

Phase 1 - Plan via grills

1. Run /grill-with-docs (add grill-me if you have it installed) to pressure-test the approach against the existing domain model, sharpen terminology, and emit CONTEXT.md + ADRs inline. (review-time: see section note)
2. Output: an execution plan in .claude/state/plans/ that defines the lanes / MRs and proves they are file-isolated - no two lanes touch the same file. (review-time: see section note)

The plan is the contract. Approving it and setting the /goal is your batched authorization for the fleet (see orchestration.md).

Phase 2 - Drive with /goal (manager-only)

Phase 2 is started by you, the operator - the agent cannot open its own session or set its own goal:

1. Open a fresh Claude Code session. The plan on disk is the whole handoff; nothing from the grill carries over. This boundary is also a deliberate gate - a long autonomous run should not start as a side effect of planning. (review-time: see section note)
2. Type /goal <condition> (built into Claude Code). With auto mode on, /goal is what keeps the one manager session working turn after turn until the fleet meets the condition, then auto-clears. (review-time: see section note)
3. Invoke this skill and run the manager loop (see orchestration.md). (review-time: see section note)

This stays a single, thin manager session the whole time - it never spawns nested sessions. Its context stays small because all editing / review / rebase / conflict work goes to subagents (each with its own context window) and worktrees; the harness compacts the manager's context as it grows. The main loop manages and nothing else - it never edits, reviews, rebases, or resolves conflicts.

If this skill is invoked with no /goal set, stop and ask the operator to set one (ideally in a fresh session) before running the loop.

Example - a fleet spanning three repos

Phase 1 (planning session) - describe the work; the agent grills and plans:

/drive-fleet
Add a feature-flag system end-to-end: the evaluation service in the api repo,
the React hook + toggle UI in the web repo, and the shared flag schema in the
shared-types repo. Plan file-isolated lanes across the three repos.

The agent runs /grill-with-docs, proves the lanes share no files, writes the plan to .claude/state/plans/, and hands back the /goal line to use next.

Phase 2 (fresh session) - set the goal, turn on auto mode, start the loop:

/goal Every open MR/PR from the feature-flags plan is CI-green, reviewed
(blockers + majors + one-line fixes via review-pr), and rebased on main.

/drive-fleet
Execute the plan at .claude/state/plans/2026-06-02-feature-flags.md

The manager builds the three lanes in parallel worktrees, opens the MRs (you approve the batch once), then drives CI-fix / review / rebase per repo until the goal clears. Your only inputs after that are the batch approval and any escalation.

Details

Manager orchestration loop, authorization model, guardrails, and the per-repo block: see orchestration.md.

Delegates to

/grill-with-docs, /mr, /ci, /review-pr, /worktree; agent personas Frontend Staff Engineer, Backend Staff Engineer, and PR Reviewer (via Agent subagent_type).