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>

<Execution_Policy>

• Each phase must complete before the next begins
• Parallel execution is used within phases where possible (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 /oh-my-claudecode:cancel at any time; progress is preserved for resume </Execution_Policy>

<Workflow_Profiles>

Named stage profiles (v1)

Select a configured profile only with /autopilot --workflow <name> <task>. A profile is an autopilot-owned stage schedule, not a command, mode, plugin, filename, or separate state identity. Without --workflow, autopilot retains its legacy lifecycle and behavior.

Named workflow profiles require Linux with the flock utility in v1 because their transcript evidence boundary uses Linux no-follow file-descriptor traversal and their recoverable mutation lock uses kernel advisory locking. Unsupported environments reject explicit --workflow activation before state mutation; use legacy autopilot instead.

Profiles are configured in project or user JSONC as autopilot.workflows.<slug>. Every v1 profile has exactly version: 1 and stages; no other profile keys are accepted. The only admitted stage sequences are:

{
  "autopilot": {
    "workflows": {
      "plan-build-qa": {
        "version": 1,
        "stages": ["ralplan", "execution", "qa"]
      }
    }
  }
}

[ralplan, execution]
[ralplan, execution, ralph]
[ralplan, execution, qa]
[ralplan, execution, ralph, qa]

ralplan creates the plan consumed by execution; execution creates the implemented workspace required by ralph and qa. Thus omitted or reordered prerequisites, duplicate stages, and non-built-in stages are invalid. Profile names use ^[a-z][a-z0-9-]{0,62}$, are validated metadata only, and cannot collide with built-in stages, autopilot/mode names, or deprecated aliases.

User and project configuration sources are each validated before composition. Different names coexist; a project profile with the same name replaces the complete user profile rather than deep-merging it. Environment configuration cannot define or replace profiles.

On successful selection, autopilot atomically creates its existing session-scoped state with an immutable normalized descriptor and selected-only pipeline tracking. The descriptor contains the workflow name, profile version, canonical stages, and a deterministic SHA-256 profile hash; it excludes task text and mutable progress. Resume and Stop verify that hash and refuse a mismatch without reloading configuration or emitting a stage prompt. Cancel, resume, cleanup, state inspection, HUD, and Stop continuation remain owned by autopilot.