Autopilot

2. Phase 1 - Planning: Create an implementation plan from the spec

   • If ralplan consensus plan exists: Skip — already done in the 3-stage pipeline
   • Architect (Opus): Create plan (direct mode, no interview)
   • Critic (Opus): Validate plan
   • Output: .omq/plans/autopilot-impl.md

3. Phase 2 - Execution: Implement the plan using Ralph + Ultrawork

   • Executor (Haiku): Simple tasks
   • Executor (Sonnet): Standard tasks
   • Executor (Opus): Complex tasks
   • Run independent tasks in parallel

4. Phase 3 - QA: Cycle until all tests pass (UltraQA mode)

   • Build, lint, test, fix failures
   • Repeat up to 5 cycles
   • Stop early if the same error repeats 3 times (indicates a fundamental issue)

5. Phase 4 - Validation: Multi-perspective review in parallel

   • Architect: Functional completeness
   • Security-reviewer: Vulnerability check
   • Code-reviewer: Quality review
   • All must approve; fix and re-validate on rejection

6. Phase 5 - Cleanup: Delete all state files on successful completion

   • Remove .omq/state/autopilot-state.json, ralph-state.json, ultrawork-state.json, ultraqa-state.json
   • Run /oh-my-qoder:cancel for clean exit

Parallel session caveats

• Multi-repo workspace anchor: drop a .omq-workspace marker at the parent directory so multiple sessions across sub-repos share one .omq/. Resolution order: OMQ_STATE_DIR > .omq-workspace > git > cwd. See docs/REFERENCE.md.
• Session id source: OMQ_SESSION_ID env var wins in CLI contexts; hook payload data.session_id wins in hook contexts.
• Plan id (when applicable): Autopilot state is session-scoped. Two autopilots in the same workspace require distinct session IDs.
• Parallel verdict: supported (session-scoped state)

Optional settings in .qoder/omq.jsonc (project) or ~/.config/qoder-omq/config.jsonc (user):

{
  "autopilot": {
    "maxIterations": 10,
    "maxQaCycles": 5,
    "maxValidationRounds": 3,
    "pauseAfterExpansion": false,
    "pauseAfterPlanning": false,
    "skipQa": false,
    "skipValidation": false
  }
}

Resume

If autopilot was cancelled or failed, run /oh-my-qoder:autopilot again to resume from where it stopped.

Best Practices for Input

1. Be specific about the domain -- "bookstore" not "store"
2. Mention key features -- "with CRUD", "with authentication"
3. Specify constraints -- "using TypeScript", "with PostgreSQL"
4. Let it run -- avoid interrupting unless truly needed

Troubleshooting

Stuck in a phase? Check TODO list for blocked tasks, review .omq/autopilot-state.json, or cancel and resume.

QA cycles exhausted? The same error 3 times indicates a fundamental issue. Review the error pattern; manual intervention may be needed.

Validation keeps failing? Review the specific issues. Requirements may have been too vague -- cancel and provide more detail.

Deep Interview Integration

When autopilot is invoked with a vague input, Phase 0 can redirect to /deep-interview for Socratic clarification:

User: "autopilot build me something cool"
Autopilot: "Your request is open-ended. Would you like to run a deep interview first?"
  [Yes, interview first (Recommended)] [No, expand directly]

If a deep-interview spec already exists at .omq/specs/deep-interview-*.md, autopilot uses it directly as Phase 0 output (the spec has already been mathematically validated for clarity).

3-Stage Pipeline: deep-interview → ralplan → autopilot

The recommended full pipeline chains three quality gates:

/deep-interview "vague idea"
  → Socratic Q&A → spec (ambiguity ≤ 20%)
  → /ralplan --direct → consensus plan (Planner/Architect/Critic approved)
  → /autopilot → skips Phase 0+1, starts at Phase 2 (Execution)

When autopilot detects a ralplan consensus plan (.omq/plans/ralplan-*.md or .omq/plans/consensus-*.md), it skips both Phase 0 (Expansion) and Phase 1 (Planning) because the plan has already been:

• Requirements-validated (deep-interview ambiguity gate)
• Architecture-reviewed (ralplan Architect agent)
• Quality-checked (ralplan Critic agent)

Autopilot starts directly at Phase 2 (Execution via Ralph + Ultrawork).