autopilot

$ralplan -> $ralph -> $code-review

If $code-review is not clean, Autopilot returns to $ralplan with the review findings as the next planning input, then continues again through $ralph and $code-review until the review is clean or a hard blocker is reported.

<Use_When>

• User wants hands-off execution from a concrete idea, issue, PRD, or requirements artifact to reviewed code
• User says $autopilot, "autopilot", "auto pilot", "autonomous", "build me", "create me", "make me", "full auto", "handle it all", or "I want a/an..."
• Task needs planning, implementation, verification, and code review with automatic follow-up when review is not clean </Use_When>

<Do_Not_Use_When>

• User wants to explore options or brainstorm -- use $plan / $ralplan
• User says "just explain", "draft only", or "what would you suggest" -- respond conversationally
• User wants a single focused code change -- use $ralph or direct executor work
• User wants only review/critique of existing code -- use $code-review </Do_Not_Use_When>

<Strict_Loop_Contract> Autopilot must not run a separate broad expansion/planning/execution/QA/validation lifecycle as its primary behavior. It delegates those concerns to the three canonical workflow phases below:

1. Phase ralplan — consensus planning gate

   • Ground the task with pre-context intake.
   • Run or resume $ralplan to produce/update PRD and test-spec artifacts.
   • When returning from a non-clean review, include return_to_ralplan_reason and the review findings as first-class planning input.
   • Required handoff artifact: an approved plan/test spec suitable for $ralph.

2. Phase ralph — implementation + verification loop

   • Run $ralph from the approved ralplan artifacts.
   • Ralph owns implementation, tests, build/lint/typecheck evidence, deslop where applicable, and architect verification.
   • Required handoff artifact: implementation evidence and changed-file summary suitable for $code-review.

3. Phase code-review — merge-readiness gate

   • Run $code-review on the diff/artifacts produced by $ralph.
   • A clean review means final recommendation APPROVE with architectural status CLEAR.
   • COMMENT, REQUEST CHANGES, any architectural WATCH/BLOCK, or any unresolved finding is not clean.
   • If not clean, increment the review cycle, persist review_verdict, set return_to_ralplan_reason, and transition back to Phase ralplan.

The only normal terminal state is complete after a clean code review. Cancellation, blocked credentials, unrecoverable repeated failures, or explicit user stop may terminate earlier with preserved state. </Strict_Loop_Contract>

<Execution_Policy>

• Always execute phases in order: ralplan, then ralph, then code-review.
• Never skip directly from vague/freeform expansion to implementation; unclear input must be clarified or planned through $ralplan.
• A non-clean $code-review always returns to $ralplan; do not patch findings ad hoc outside the loop.
• Each phase must write/update Autopilot state before handing off.
• Use existing hooks, .omx/state, $ralplan, $ralph, $code-review, and pipeline primitives; do not invent a separate execution framework.
• Continue automatically through safe reversible phase transitions. Ask only for destructive, credential-gated, or materially preference-dependent branches.
• Apply the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step execution, local overrides for the active workflow branch, validation proportional to risk, explicit stop rules, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches. </Execution_Policy>