fleet

Orchestration layer above /implement, split by when it runs:

• dispatch <label>: start of a wave. Read dispatch.md.
• land <label>: once the user has marked the good PRs ready. Read land.md.
• reconcile <label>: after the wave's PRs have merged. Read reconcile.md.

All subcommands require a feature label as the argument after the subcommand (for example /fleet dispatch cv-tailoring). If it is missing, ask for it; never run across all issues. Read the file for the subcommand in the first argument. With no subcommand, use reconcile if the user says the wave has merged, otherwise dispatch. If it is still unclear, ask.

Shared conventions

An issue whose changes are all under skills/ is still dispatched through /implement, which hands it to skill-updater.

Both halves rely on these, so they are defined once here.

• Scratchpad. <scratchpad>/fleet/ holds brief.md, one <N>.md report per ticket, and state.md. It is scratch, not truth: the board and PR state on GitHub win over it.
• Status labels. ticket-tracker's status:backlog → ready → in-progress → in-review → done. Move a ticket with gh issue edit <N> --remove-label "status:<from>" --add-label "status:<to>". Moving to done also needs gh issue close <N>. A ticket with no status:* label is backlog.
• Blockers. A ticket's ## Blocked by section lists - Blocked by #<N> lines, or "None". This is the only record of dependencies; both subcommands read it.
• Feature label. The label to-plan creates and to-tickets applies to every ticket of a feature, project:<slug>. It scopes every gh issue list in both subcommands with --label "<label>". The argument may be <slug> or project:<slug>: if it matches an existing label exactly (gh label list), use it as is, so sweep-YYYY-MM-DD and older bare labels keep working; otherwise strip any leading project: and the label is project:<slug>.
• Feature branch. feat/<slug>, where <slug> is the label without its project: prefix (a label with no prefix, like sweep-YYYY-MM-DD, is its own slug), since git forbids : in ref names. Every ticket PR targets it, never main, so several features can run in parallel without touching each other. When the feature's tickets are all done, reconcile opens one PR merging feat/<slug> into main.
• Fleet section. A repo's CLAUDE.md may carry a Fleet section listing its generated, committed paths (minified CSS, goldens) and the command that rebuilds them. Those files conflict by construction, so fleet regenerates them mechanically instead of resolving them.
• Ticket branch. issue-<N>/<short-title>: <N> is the issue number, <short-title> a kebab-case slug of the issue title, a few words (issue-142/stuck-scrape-run). Dispatch creates it, /implement works on it, reconcile removes it.
• Bundle branch. issue-<N>/tiny-bundle, <N> the lowest issue number in the bundle. One PR whose body has a Closes #<N> line per bundled ticket, which is how reconcile matches it to each of them.
• state.md. fleet reconcile writes it, dispatch reads it. It opens with the feature label, then has one section per unblocked ticket with its number, base branch, and the merged PR to use as the worked example.