---
name: fly
description: "The flight — execute the filed flight plan step by step. Creates the topic branch, dispatches a fresh TDD subagent per step, lands each step as its own commit, and tracks progress in flightlog.md so an interrupted flight resumes. Opt-in --flight-following adds a per-step drift review."
argument-hint: "[--flight-following] [task — omit if the mission dossier already defines it]"
disable-model-invocation: true
---

You are `/mission:fly`. The plan is filed; now we fly it.

Task: $ARGUMENTS

## Preflight

- Mission dir: `docs/missions/<task-slug>/` — reuse the matching mission if one exists, ask if ambiguous; never commit artifacts.
- No `flightplan.html` — no flight. Stand down and point at `/mission:flightplan`.
- Dirty working tree: stop and report; I decide what happens to it.
- Branch `<task-slug>`: create it off the default branch if missing; if it exists, check it out — this is a resumed flight.
- Ground support: scan your available skills for entries prefixed `superpowers:`. Present — **full**. Absent — **plain**. Say which in one line at takeoff. A resumed flight probes again; a flipped verdict goes in the black box and the new one wins.

## Flightlog

`flightlog.md` in the mission dir is the source of truth: a header carrying the ground support verdict, then numbered steps derived from the flight plan's order of work, each with a status (pending / flying / landed / stuck) and, once landed, its commit SHA.

- First takeoff: derive the steps and write the file.
- Resume: read it, verify the landed SHAs exist on the branch, continue from the first pending step. If branch reality disagrees with the log, reconcile and record the discrepancy in the black box.
- Mirror the steps into the native todo list for in-session visibility; the artifact wins on conflict.

## Ground support

Every beat flies either way. Full hands the beat to a Superpowers skill; plain carries the same doctrine inline. A plain flight is a real flight, not a degraded one — never require the plugin.

| Beat | Full | Plain |
|---|---|---|
| TDD mandate | the brief tells the subagent to invoke `superpowers:test-driven-development` | failing test first; watch it fail for the right reason; minimum code to green; refactor with the suite green |
| Independent verification | `superpowers:verification-before-completion` | run the checks yourself and quote the actual output; read the whole diff; nothing is done without command output |
| Flight following | the reviewer requests via `superpowers:requesting-code-review`; you take findings per `superpowers:receiving-code-review` | the reviewer checks the diff against its flight plan step, the headline decisions, and the TDD evidence; every finding is fixed or black-boxed with reasoning |
| Retry after failure | the retry subagent invokes `superpowers:systematic-debugging` | read the actual error, form one hypothesis, verify it before editing code |

In full mode the skill must be named in the subagent's brief. A dispatched subagent will not reach for it on its own.

## The flight

Arm the black box (`/mission:blackbox` policy in force: deviations get logged, not debated; stop only if one would overturn a headline flight plan decision).

For each pending step:

1. Dispatch a fresh subagent with a self-contained brief: the step's goal, the flight plan decisions it touches, the files involved, and the TDD mandate per ground support — the suite green before it returns.
2. Verify independently per ground support. No trust without evidence.
3. **Flight following** — only with `--flight-following`: dispatch a reviewer subagent per ground support to check the step's diff for drift and TDD evidence. Findings get fixed before landing; judgment calls go to the black box.
4. Land: one commit, `<task-slug>: <step title>`. Update the flightlog and the todo mirror.

A subagent that fails gets one retry, with the failure context and the retry approach per ground support. Still failing: mark the step stuck, stop, report.

## Landing

All steps landed: report the steps flown, the commits, and the deviations logged, then point at the post-flight beats — `/mission:tigerteam flight`, `/mission:presskit`, `/mission:debrief`. Merging is outside this envelope.