autopilot

Autopilot does NOT do the work itself. It is a conductor: it sequences sibling skills (ralplan, ralph or team) and agent passes (analyst for Phase 1 intake, then test-engineer, executor, verifier, plus the Phase 5 panel), reads each phase's artifact, gates on the next phase's success criterion, and stops at "ready for commit". Commit and PR creation remain the user's call.

<Use_When>

• User invokes "/autopilot", says "autopilot", "build me X", "create me X", "make me X", "I want a/an X".
• The task is large enough to need full lifecycle management (spec + plan + impl + test + validate).
• The user wants hands-off execution: describe WHAT, not HOW.
• An existing .dt-handoff/<slug>/spec.md or plan.md is present and the user wants to resume. </Use_When>

<Do_Not_Use_When>

• The user wants to brainstorm only — answer directly.
• The user wants a single bug fix or a quick edit — delegate to executor, or work directly.
• The user wants only requirements capture with no planning or execution — that is now a standalone concern; run /interview to capture the spec first, then run autopilot.
• The user wants planning without execution — use ralplan.
• The user wants automatic commit/PR — refuse; autopilot stops at "ready for commit".
• The user has not specified scope at all ("just improve everything") — refuse and ask for a concrete target; Phase 1 intake needs a real idea to analyze. </Do_Not_Use_When>

<Why_This_Exists> Most "build me X" tasks fail not because any single phase was hard, but because phase boundaries leak: requirements drift during planning, plans drift during execution, tests get skipped when execution gets noisy, and validation collapses to "looks fine to me." A conductor that owns the boundaries — reading the previous phase's artifact and refusing to advance until each phase's success criterion is met — closes those leaks.

The five phases mirror how a careful team works: discover, decide, implement, test, validate. Each is a named step with a checkable artifact. Resumption is the common case, so an existing spec/plan short-circuits the early phases.

Two anti-patterns are designed out: (1) self-approval — the verifier agent, not the executor that greened a test, judges whether tests actually pass, on fresh evidence; (2) prose-keyword routing — judgment agents return a machine-readable verdict the conductor routes on deterministically.

The conductor stays thin on purpose. The handoff mechanics (@handoff-in/@handoff-out, descriptors, events.jsonl) are defined once in the handoff protocol; this skill references them rather than re-spelling them per phase. </Why_This_Exists>

<Execution_Policy> Output language: phase status reports and the final summary use $LANGUAGE. Section headers stay English. Artifact contents follow each sub-skill's own language rules.

Phase sequencing: phases run STRICTLY sequentially. Never start Phase N+1 until Phase N reports success. Never parallelize phases (the one intra-phase parallel pass is the Phase 5 panel).

Resume / skip (default --resume=auto):

• spec.md present → skip Phase 1.
• plan.md present with Status pending approval or approved → skip Phases 1–2.
• prd.json present with progress → offer resume vs restart.
• Confirm the detected resumption point with one AskUserQuestion (suppressed by --no-prompt). --resume=fresh ignores existing artifacts and restarts at Phase 1.

Validation model (Phase 5) — gates decide, advisors annotate:

• Gates (a failing gate triggers the gate-failure routing below): reviewer (verdict REVISE/REJECT), security-auditor (CRITICAL @ HIGH confidence), architect (CRITICAL @ HIGH confidence). With --full-validation, critic (verdict REJECT) and the end-to-end verifier (verdict REVISE/REJECT) join the gates.
• Advisors (recorded in autopilot-validation.md, never block): performance-analyst and doc-writer findings, and critic ACCEPT_WITH_RESERVATIONS. Advisors run only under --full-validation. The provenance-deferred test-engineer coverage audit (see Phase 4) joins as a read-only panel member when applicable.
• Gate-failure routing: failing findings ≤ 3 AND none architectural → targeted path: executor applies targeted fixes → verifier re-verifies with note: scope=<impacted checks> (always include BUILD,ERROR_FREE alongside the impacted checks so a targeted fix cannot silently break the build) → re-fire ONLY the failed gate(s). Otherwise (critic REJECT, a design-invalidating verdict, or > 3 findings) → full Phase 3 re-entry with the findings.
• Both paths share one cap: max 2 re-entries; on the third failure stop PHASE5_REJECTED.