autopilot

<Use_When>

• User wants end-to-end autonomous execution from an idea to working code
• User says "autopilot", "auto pilot", "autonomous", "build me", "create me", "make me", "full auto", "handle it all", or "I want a/an..."
• Task requires multiple phases: planning, coding, testing, and validation
• User wants hands-off execution and is willing to let the system run to completion </Use_When>

<Do_Not_Use_When>

• User wants to explore options or brainstorm -- use plan skill instead
• User says "just explain", "draft only", or "what would you suggest" -- respond conversationally
• User wants a single focused code change -- use ralph or delegate to an executor agent
• User wants to review or critique an existing plan -- use plan --review
• Task is a quick fix or small bug -- use direct executor delegation </Do_Not_Use_When>

<Why_This_Exists> Most non-trivial software tasks require coordinated phases: understanding requirements, designing a solution, implementing in parallel, testing, and validating quality. Autopilot orchestrates all of these phases automatically so the user can describe what they want and receive working code without managing each step. </Why_This_Exists>

<Non_Negotiables>

• User instructions, repository instructions, and existing uncommitted work are binding context. Never overwrite unrelated user changes.
• Do not commit, push, merge, publish, deploy, delete, reset, or modify external systems unless the user explicitly authorizes that exact action.
• Inspect repository entrypoints and compact project memory before making assumptions. Prefer evidence from files and commands over remembered conventions.
• A claim of completion requires fresh evidence. A worker's self-report, a planned command, or code that merely looks right is not verification.
• Use only tools and skills available in the current runtime. If an optional tool is unavailable, use the closest local path and record the limitation.
• Every non-trivial automatic decision must be recorded with its evidence, rejected alternative, and cost if wrong. </Non_Negotiables>

<Execution_Policy>

• Each phase must complete before the next begins
• Default to the lightest mode that can finish the task; do not expand into a heavy workflow unless the task truly needs multiple phases
• Parallel execution is used only for independent workstreams with clear ownership (Phase 2 and Phase 4)
• QA cycles repeat up to 5 times; if the same error persists 3 times, stop and report the fundamental issue
• Validation requires approval from all reviewers; rejected items get fixed and re-validated
• Cancel with /cancel at any time; progress is preserved for resume
• If a deep-interview spec exists, use it as high-clarity phase input instead of re-expanding from scratch
• If input is too vague for reliable expansion, offer/trigger $deep-interview first
• Do not enter expansion/planning/execution-heavy phases until pre-context grounding exists; if fast execution is forced, proceed only with explicit risk notes
• Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail
• Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints
• If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the workflow is grounded
• Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent
• After compaction or resume, continue from the latest checkpoint and newest user message; do not restart discovery unless the checkpoint is missing or contradicted
• If the same diagnosis appears twice, make the next smallest safe fix or report the exact blocker; do not repeat the same investigation loop
• State MCP tools are helpful but optional; if an OMX MCP call fails, write a local checkpoint and continue instead of blocking
• Before changing code, define boundaries: files/behaviors that must not break, destructive commands that are forbidden, and the rollback point
• Every phase must have a gate: required artifact, owner, next action, and verification command; do not advance on vague outputs
• Prefer task-by-task execution with fresh context from checkpoint artifacts instead of relying on the full conversation history
• Treat autopilot as a bounded state machine: intake -> expansion -> planning -> execution -> qa -> validation -> handoff.
• A new user message is a local override. Preserve earlier non-conflicting requirements, invalidate affected downstream artifacts, and resume from the earliest invalid phase.
• Do not claim that unavailable reviewers approved anything. If review tools are missing, perform an adversarial single-agent review and disclose the limitation. </Execution_Policy>