--- 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. - 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 - 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 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 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 - 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` Factory Droid does NOT support native background execution (`run_in_background: true`). For TRUE parallel execution of independent tasks, use `background-manager.py`: ```bash # 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 ``` CRITICAL: Launch ALL independent tasks BEFORE checking any results. Do NOT launch-wait-launch sequentially. 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. 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: ") ``` Then validate: ``` Task(subagent_type="momus", description="Validate the plan", prompt="Review this implementation plan for gaps, risks, and feasibility: ") ``` - 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: ") Task(subagent_type="security-auditor", description="Security review", prompt="Check for security vulnerabilities: ") Task(subagent_type="verifier", description="Verify implementation", prompt="Verify this implementation meets acceptance 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 | 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 | 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. **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 - 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 - [ ] 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

autopilot

Install this skill

Comments