autopilot

name	autopilot
description	Full autonomous execution from idea to working code. Handles the full lifecycle - requirements, planning, parallel implementation, QA cycling, and multi-perspective validation.

Autopilot takes a brief product idea and autonomously handles the full lifecycle: requirements analysis, technical design, planning, parallel implementation, QA cycling, and multi-perspective validation. It produces working, verified code from a short description.

<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"
• 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 or brainstorm -- respond conversationally or use prometheus droid
• User says "just explain", "draft only", "what would you suggest" -- respond conversationally
• User wants a single focused code change -- use ralph skill or delegate to executor-med directly
• User wants to review or critique an existing plan -- use momus droid
• Task is a quick fix or small bug -- use direct executor delegation </Do_Not_Use_When>

<What_You_MUST_Do>

1. COMPLETE ALL PHASES - Expansion, Planning, Execution, QA, Validation
2. USE Task TOOL CORRECTLY - All three params: subagent_type, description, prompt
3. FIRE PARALLEL TASKS - Launch ALL independent tasks BEFORE checking ANY results
4. VERIFY WITH FRESH EVIDENCE - Run tests/build, show output, do NOT assume
5. GET APPROVAL FROM ALL VALIDATORS - code-reviewer, security-auditor, verifier
6. CLEAN UP STATE FILES - Delete .omd/state/autopilot-state.json on success </What_You_MUST_Do>

<What_You_MUST_NOT_Do>

1. DO NOT skip phases
2. DO NOT claim completion without fresh verification output
3. DO NOT serialize independent tasks - run in parallel
4. DO NOT use "should", "probably", "seems to" - show evidence
5. DO NOT proceed with invalid droid names in Task tool
6. DO NOT loop on failed edits more than 2 times - report to user </What_You_MUST_NOT_Do>

<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
• State is tracked in .omd/state/autopilot-state.json </Execution_Policy>

<Parallel_Execution> Factory Droid does NOT support native background execution (run_in_background: true). For TRUE parallel execution of independent tasks, use background-manager.py:

# Launch multiple droids in TRUE parallel (fire ALL before checking ANY)
python3 hooks/background-manager.py launch "Fix auth" "Fix auth module errors" executor-med "main"
python3 hooks/background-manager.py launch "Fix API" "Fix API route errors" executor-med "main"
python3 hooks/background-manager.py launch "Fix UI" "Fix frontend type errors" executor-med "main"

# Monitor all running tasks
python3 hooks/background-manager.py list

# Check specific task output when done
python3 hooks/background-manager.py output <task_id>

CRITICAL: Launch ALL independent tasks BEFORE checking any results. Do NOT launch-wait-launch sequentially. </Parallel_Execution>

<Task_Tool_Usage> CRITICAL: When spawning droids, you MUST use the Task tool with these EXACT parameters:

• subagent_type: The droid name exactly as listed below (e.g., "prometheus", "verifier")
• description: A short 3-5 word label
• prompt: The full task instructions

Example:

Task(subagent_type="prometheus", description="Create implementation plan", prompt="Create a detailed implementation plan for: ...")
Task(subagent_type="momus", description="Validate the plan", prompt="Review this plan for gaps and risks: ...")
Task(subagent_type="executor-med", description="Implement user auth", prompt="Implement user authentication: ...")
Task(subagent_type="verifier", description="Verify implementation", prompt="Verify that the implementation meets these criteria: ...")
Task(subagent_type="code-reviewer", description="Review code quality", prompt="Review the following changes for quality: ...")
Task(subagent_type="security-auditor", description="Security review", prompt="Check for security vulnerabilities: ...")

ALL THREE parameters (subagent_type, description, prompt) are REQUIRED for every Task call. </Task_Tool_Usage>

1. **Phase 0 - Expansion**: Turn the user's idea into a detailed spec ``` Task(subagent_type="prometheus", description="Extract requirements", prompt="Analyze this idea and create a detailed technical spec: ") ``` - Output: `.omd/autopilot/spec.md`

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

   Task(subagent_type="prometheus", description="Create impl plan", prompt="Create a detailed implementation plan from this spec: <spec content>")
   

   Then validate:

   Task(subagent_type="momus", description="Validate the plan", prompt="Review this implementation plan for gaps, risks, and feasibility: <plan content>")
   

   • Output: .omd/plans/autopilot-impl.md

3. Phase 2 - Execution: Implement using appropriate droids

   • Simple tasks: Task(subagent_type="executor-low", description="...", prompt="...")
   • Standard tasks: Task(subagent_type="executor-med", description="...", prompt="...")
   • Complex tasks: Task(subagent_type="executor-high", description="...", prompt="...")
   • Architecture: Task(subagent_type="hephaestus", description="...", prompt="...")
   • Run independent tasks in parallel (multiple Task calls at once)

4. Phase 3 - QA: Cycle until all checks pass

   • Build, lint, typecheck, run tests
   • Fix failures and retry
   • Max 5 cycles; stop early if the same error repeats 3 times

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

   Task(subagent_type="code-reviewer", description="Code quality review", prompt="Review these changes for quality: <changes>")
   Task(subagent_type="security-auditor", description="Security review", prompt="Check for security vulnerabilities: <changes>")
   Task(subagent_type="verifier", description="Verify implementation", prompt="Verify this implementation meets acceptance criteria: <criteria>")
   

   • All must approve; fix and re-validate on rejection

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

   • Remove .omd/state/autopilot-state.json and related state files

<Droid_Selection_Guide>

Task Type	subagent_type	When to Use
Requirements, planning	prometheus	Phase 0, Phase 1
Plan validation	momus	Phase 1
Simple tasks	executor-low	Config changes, small file edits
Standard tasks	executor-med	Implementation, bug fixes, features (default)
Complex tasks	executor-high	Multi-file changes, refactoring
Architecture	hephaestus	System design, complex architecture
Code review	code-reviewer	Phase 4 quality review
Security review	security-auditor	Phase 4 vulnerability check
Verification	verifier	Phase 4 functional correctness
</Droid_Selection_Guide>

User: "autopilot build a REST API for bookstore inventory with CRUD using TypeScript" Why: Specific domain, clear features, technology constraint. Enough context to expand into a full spec. Correct Task tool usage: ``` Task(subagent_type="prometheus", description="Create API spec", prompt="Analyze and create detailed spec for: REST API for bookstore inventory with CRUD using TypeScript") Task(subagent_type="momus", description="Validate API plan", prompt="Review this plan for gaps: ...") Task(subagent_type="executor-med", description="Create user endpoints", prompt="Implement the /api/users CRUD endpoints: ...") Task(subagent_type="executor-med", description="Create book endpoints", prompt="Implement the /api/books CRUD endpoints: ...") Task(subagent_type="verifier", description="Verify API works", prompt="Run tests and verify all CRUD endpoints work: ...") ``` Why: All three required params present, correct subagent_type names, independent tasks fired in parallel. Task(subagent_type="verify", description="Check it", prompt="...") Why: "verify" is not a valid droid name. Use "verifier". Task(subagent_type="verifier", prompt="Verify the changes") Why: Missing required `description` parameter.

<Error_Handling> Before Any Edit:

1. MUST Read the exact file content first (full file, not offset/limit)
2. MUST verify the old_str exists EXACTLY as you plan to use it
3. If Grep finds no matches, DO NOT attempt Edit - the issue may not exist

Edit Failures:

• If Edit fails with "content matches exactly": STOP, Read full file again, find exact old_str, then retry once
• If Edit fails 2 times on same file: STOP and report to user - do not retry more
• NEVER guess old_str - always copy exact content from Read output

Stuck Detection:

• If you attempt the same operation 2+ times, you are STUCK
• When stuck: STOP immediately, report to user what you're stuck on
• NEVER loop on failed operations

Phantom Issues:

• Before fixing an "error" from console/logs, VERIFY the error actually exists in the code
• If Grep returns 0 matches: the issue does NOT exist in code - STOP and report false positive
• NEVER attempt to fix something you cannot find in the code </Error_Handling>

<Escalation_And_Stop_Conditions>

• Stop and report when the same QA error persists across 3 cycles (fundamental issue requiring human input)
• Stop and report when validation keeps failing after 3 re-validation rounds
• Stop when the user says "stop", "cancel", or "abort"
• If requirements are too vague, pause and ask the user for clarification before proceeding
• Stop and ask user when stuck on the same edit/fix after 3 attempts </Escalation_And_Stop_Conditions>

<Final_Checklist>

• All phases completed (Expansion, Planning, Execution, QA, Validation)
• All validators approved in Phase 4
• Tests pass (verified with fresh test run output)
• Build succeeds (verified with fresh build output)
• State files cleaned up
• User informed of completion with summary of what was built </Final_Checklist>