Dev Autopilot

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.

Execution Policy

• Each phase must complete before the next begins
• Parallel execution is used within phases where possible
• 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

Phases

Phase 0 — Expansion

Turn the user's idea into a detailed spec.

• If input is vague (no file paths, function names, or concrete anchors): suggest dev-deep-interview for Socratic clarification before expanding
• Otherwise: @echo-analyst (Opus) extracts requirements, @apex-architect (Opus) creates technical specification
• Output: workspace/projects/specs/[C]autopilot-spec-{name}.md

Phase 1 — Planning

Create an implementation plan from the spec.

• @compass-planner (Opus): Create plan (direct mode, no interview)
• @raven-critic (Opus): Validate plan
• Output: workspace/projects/plans/[C]autopilot-plan-{name}.md

Phase 2 — Execution

Implement the plan.

• @bolt-executor (Sonnet): Standard tasks
• For complex tasks, escalate to @apex-architect for design before re-delegating
• Run independent tasks in parallel where safe

Phase 3 — QA

Cycle until all tests pass.

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

Phase 4 — Validation

Multi-perspective review in parallel.

• @apex-architect: Functional completeness
• @vault-security: Vulnerability check (when imported in EPIC 3)
• @lens-reviewer: Quality review
• All must approve; fix and re-validate on rejection

Phase 5 — Verification

• @oath-verifier: Final evidence-based completion check against acceptance criteria

Examples

Good:

• "autopilot a REST API for a bookstore inventory with CRUD operations using TypeScript" → Specific domain, clear features, technology constraint. Enough context to expand.
• "build me a CLI tool that tracks daily habits with streak counting" → Clear product concept with a specific feature.

Bad:

• "fix the bug in the login page" → Single focused fix, not multi-phase. Delegate to @hawk-debugger or @bolt-executor.
• "what are some good approaches for adding caching?" → Exploration. Respond conversationally or use dev-plan.

Stop Conditions

• Same QA error persists across 3 cycles → escalate
• Validation keeps failing after 3 re-validation rounds → escalate
• User says "stop", "cancel", or "abort"
• Vague spec produces unclear expansion → pause and ask for clarification

Final Checklist

• All 5 phases completed (Expansion, Planning, Execution, QA, Validation, Verification)
• All validators approved
• Tests pass (verified with fresh test run output)
• Build succeeds (verified with fresh build output)
• User informed of completion with summary of what was built

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