--- name: autopilot description: | Auto-chaining orchestrator that drives the full BUILD-SHIP workflow from problem gathering through deployment. Detects current project state from _docs/ folder, resumes from where it left off, and flows through problem → research → plan → decompose → implement → deploy without manual skill invocation. Maximizes work per conversation by auto-transitioning between skills. Trigger phrases: - "autopilot", "auto", "start", "continue" - "what's next", "where am I", "project status" category: meta tags: [orchestrator, workflow, auto-chain, state-machine, meta-skill] disable-model-invocation: true --- # Autopilot Orchestrator Auto-chaining execution engine that drives the full BUILD → SHIP workflow. Detects project state from `_docs/`, resumes from where work stopped, and flows through skills automatically. The user invokes `/autopilot` once — the engine handles sequencing, transitions, and re-entry. ## Core Principles - **Auto-chain**: when a skill completes, immediately start the next one — no pause between skills - **Only pause at decision points**: BLOCKING gates inside sub-skills are the natural pause points; do not add artificial stops between steps - **State from disk**: all progress is persisted to `_docs/_autopilot_state.md` and cross-checked against `_docs/` folder structure - **Rich re-entry**: on every invocation, read the state file for full context before continuing - **Delegate, don't duplicate**: read and execute each sub-skill's SKILL.md; never inline their logic here ## State File: `_docs/_autopilot_state.md` The autopilot persists its state to `_docs/_autopilot_state.md`. This file is the primary source of truth for re-entry. Folder scanning is the fallback when the state file doesn't exist. ### Format ```markdown # Autopilot State ## Current Step step: [0-5 or "done"] name: [Problem / Research / Plan / Decompose / Implement / Deploy / Done] status: [not_started / in_progress / completed] sub_step: [optional — sub-skill phase if interrupted mid-step, e.g. "Plan Step 3: Component Decomposition"] ## Completed Steps | Step | Name | Completed | Key Outcome | |------|------|-----------|-------------| | 0 | Problem | [date] | [one-line summary] | | 1 | Research | [date] | [N drafts, final approach summary] | | 2 | Plan | [date] | [N components, architecture summary] | | 3 | Decompose | [date] | [N tasks, total complexity points] | | 4 | Implement | [date] | [N batches, pass/fail summary] | | 5 | Deploy | [date] | [artifacts produced] | ## Key Decisions - [decision 1: e.g. "Tech stack: Python + Rust for perf-critical, Postgres DB"] - [decision 2: e.g. "6 research rounds, final draft: solution_draft06.md"] - [decision N] ## Last Session date: [date] ended_at: [step name and phase] reason: [completed step / session boundary / user paused / context limit] notes: [any context for next session, e.g. "User asked to revisit risk assessment"] ## Blockers - [blocker 1, if any] - [none] ``` ### State File Rules 1. **Create** the state file on the very first autopilot invocation (after state detection determines Step 0) 2. **Update** the state file after every step completion, every session boundary, and every BLOCKING gate confirmation 3. **Read** the state file as the first action on every invocation — before folder scanning 4. **Cross-check**: after reading the state file, verify against actual `_docs/` folder contents. If they disagree (e.g., state file says Step 2 but `_docs/02_plans/architecture.md` already exists), trust the folder structure and update the state file to match 5. **Never delete** the state file. It accumulates history across the entire project lifecycle ## Execution Entry Point Every invocation of this skill follows the same sequence: ``` 1. Read _docs/_autopilot_state.md (if exists) 2. Cross-check state file against _docs/ folder structure 3. Resolve current step (state file + folder scan) 4. Present Status Summary (from state file context) 5. Enter Execution Loop: a. Read and execute the current skill's SKILL.md b. When skill completes → update state file c. Re-detect next step d. If next skill is ready → auto-chain (go to 5a with next skill) e. If session boundary reached → update state file with session notes → suggest new conversation f. If all steps done → update state file → report completion ``` ## State Detection Read `_docs/_autopilot_state.md` first. If it exists and is consistent with the folder structure, use the `Current Step` from the state file. If the state file doesn't exist or is inconsistent, fall back to folder scanning. ### Folder Scan Rules (fallback) Scan `_docs/` to determine the current workflow position. Check rules in order — first match wins. ### Detection Rules **Step 0 — Problem Gathering** Condition: `_docs/00_problem/` does not exist, OR any of these are missing/empty: - `problem.md` - `restrictions.md` - `acceptance_criteria.md` - `input_data/` (must contain at least one file) Action: Read and execute `.cursor/skills/problem/SKILL.md` --- **Step 1 — Research (Initial)** Condition: `_docs/00_problem/` is complete AND `_docs/01_solution/` has no `solution_draft*.md` files Action: Read and execute `.cursor/skills/research/SKILL.md` (will auto-detect Mode A) --- **Step 1b — Research Decision** Condition: `_docs/01_solution/` contains `solution_draft*.md` files AND `_docs/01_solution/solution.md` does not exist AND `_docs/02_plans/architecture.md` does not exist Action: Present the current research state to the user: - How many solution drafts exist - Whether tech_stack.md and security_analysis.md exist - One-line summary from the latest draft Then ask: **"Run another research round (Mode B assessment), or proceed to planning?"** - If user wants another round → Read and execute `.cursor/skills/research/SKILL.md` (will auto-detect Mode B) - If user wants to proceed → auto-chain to Step 2 (Plan) --- **Step 2 — Plan** Condition: `_docs/01_solution/` has `solution_draft*.md` files AND `_docs/02_plans/architecture.md` does not exist Action: 1. The plan skill's Prereq 2 will rename the latest draft to `solution.md` — this is handled by the plan skill itself 2. Read and execute `.cursor/skills/plan/SKILL.md` If `_docs/02_plans/` exists but is incomplete (has some artifacts but no `FINAL_report.md`), the plan skill's built-in resumability handles it. --- **Step 3 — Decompose** Condition: `_docs/02_plans/` contains `architecture.md` AND `_docs/02_plans/components/` has at least one component AND `_docs/02_tasks/` does not exist or has no task files (excluding `_dependencies_table.md`) Action: Read and execute `.cursor/skills/decompose/SKILL.md` If `_docs/02_tasks/` has some task files already, the decompose skill's resumability handles it. --- **Step 4 — Implement** Condition: `_docs/02_tasks/` contains task files AND `_dependencies_table.md` exists AND `_docs/03_implementation/FINAL_implementation_report.md` does not exist Action: Read and execute `.cursor/skills/implement/SKILL.md` If `_docs/03_implementation/` has batch reports, the implement skill detects completed tasks and continues. --- **Step 5 — Deploy** Condition: `_docs/03_implementation/FINAL_implementation_report.md` exists AND `_docs/04_deploy/` does not exist or is incomplete Action: Read and execute `.cursor/skills/deploy/SKILL.md` --- **Done** Condition: `_docs/04_deploy/` contains all expected artifacts (containerization.md, ci_cd_pipeline.md, environment_strategy.md, observability.md, deployment_procedures.md) Action: Report project completion with summary. ## Status Summary On every invocation, before executing any skill, present a status summary built from the state file (with folder scan fallback). Format: ``` ═══════════════════════════════════════════════════ AUTOPILOT STATUS ═══════════════════════════════════════════════════ Step 0 Problem [DONE / IN PROGRESS / NOT STARTED] Step 1 Research [DONE (N drafts) / IN PROGRESS / NOT STARTED] Step 2 Plan [DONE / IN PROGRESS / NOT STARTED] Step 3 Decompose [DONE (N tasks) / IN PROGRESS / NOT STARTED] Step 4 Implement [DONE / IN PROGRESS (batch M of ~N) / NOT STARTED] Step 5 Deploy [DONE / IN PROGRESS / NOT STARTED] ═══════════════════════════════════════════════════ Current step: [Step N — Name] Action: [what will happen next] ═══════════════════════════════════════════════════ ``` For re-entry (state file exists), also include: - Key decisions from the state file's `Key Decisions` section - Last session context from the `Last Session` section - Any blockers from the `Blockers` section ## Auto-Chain Rules After a skill completes, apply these rules: | Completed Step | Next Action | |---------------|-------------| | Problem Gathering | Auto-chain → Research (Mode A) | | Research (any round) | Auto-chain → Research Decision (ask user: another round or proceed?) | | Research Decision → proceed | Auto-chain → Plan | | Plan | Auto-chain → Decompose | | Decompose | **Session boundary** — suggest new conversation before Implement | | Implement | Auto-chain → Deploy | | Deploy | Report completion | ### Session Boundary: Decompose → Implement After decompose completes, **do not auto-chain to implement**. Instead: 1. Update state file: mark Decompose as completed, set current step to 4 (Implement) with status `not_started` 2. Write `Last Session` section: `reason: session boundary`, `notes: Decompose complete, implementation ready` 3. Present a summary: number of tasks, estimated batches, total complexity points 4. Suggest: "Implementation is the longest phase and benefits from a fresh conversation context. Start a new conversation and type `/autopilot` to begin implementation." 5. If the user insists on continuing in the same conversation, proceed. This is the only hard session boundary. All other transitions auto-chain. ## Skill Delegation For each step, the delegation pattern is: 1. Update state file: set current step to `in_progress`, record `sub_step` if applicable 2. Announce: "Starting [Skill Name]..." 3. Read the skill file: `.cursor/skills/[name]/SKILL.md` 4. Execute the skill's workflow exactly as written, including: - All BLOCKING gates (present to user, wait for confirmation) - All self-verification checklists - All save actions - All escalation rules 5. When the skill's workflow is fully complete: - Update state file: mark step as `completed`, record date, write one-line key outcome - Add any key decisions made during this step to the `Key Decisions` section - Return to the auto-chain rules Do NOT modify, skip, or abbreviate any part of the sub-skill's workflow. The autopilot is a sequencer, not an optimizer. ## Re-Entry Protocol When the user invokes `/autopilot` and work already exists: 1. Read `_docs/_autopilot_state.md` 2. Cross-check against `_docs/` folder structure 3. Present Status Summary with context from state file (key decisions, last session, blockers) 4. If the detected step has a sub-skill with built-in resumability (plan, decompose, implement, deploy all do), the sub-skill handles mid-step recovery 5. Continue execution from detected state ## Error Handling | Situation | Action | |-----------|--------| | State detection is ambiguous (artifacts suggest two different steps) | Present findings to user, ask which step to execute | | Sub-skill fails or hits an unrecoverable blocker | Report the error, suggest the user fix it manually, then re-invoke `/autopilot` | | User wants to skip a step | Warn about downstream dependencies, proceed if user confirms | | User wants to go back to a previous step | Warn that re-running may overwrite artifacts, proceed if user confirms | | User asks "where am I?" without wanting to continue | Show Status Summary only, do not start execution | ## Trigger Conditions This skill activates when the user wants to: - Start a new project from scratch - Continue an in-progress project - Check project status - Let the AI guide them through the full workflow **Keywords**: "autopilot", "auto", "start", "continue", "what's next", "where am I", "project status" **Differentiation**: - User wants only research → use `/research` directly - User wants only planning → use `/plan` directly - User wants the full guided workflow → use `/autopilot` ## Methodology Quick Reference ``` ┌────────────────────────────────────────────────────────────────┐ │ Autopilot (Auto-Chain Orchestrator) │ ├────────────────────────────────────────────────────────────────┤ │ EVERY INVOCATION: │ │ 1. State Detection (scan _docs/) │ │ 2. Status Summary (show progress) │ │ 3. Execute current skill │ │ 4. Auto-chain to next skill (loop) │ │ │ │ WORKFLOW: │ │ Step 0 Problem → .cursor/skills/problem/SKILL.md │ │ ↓ auto-chain │ │ Step 1 Research → .cursor/skills/research/SKILL.md │ │ ↓ auto-chain (ask: another round?) │ │ Step 2 Plan → .cursor/skills/plan/SKILL.md │ │ ↓ auto-chain │ │ Step 3 Decompose → .cursor/skills/decompose/SKILL.md │ │ ↓ SESSION BOUNDARY (suggest new conversation) │ │ Step 4 Implement → .cursor/skills/implement/SKILL.md │ │ ↓ auto-chain │ │ Step 5 Deploy → .cursor/skills/deploy/SKILL.md │ │ ↓ │ │ DONE │ │ │ │ STATE FILE: _docs/_autopilot_state.md │ │ FALLBACK: _docs/ folder structure scan │ │ PAUSE POINTS: sub-skill BLOCKING gates only │ │ SESSION BREAK: after Decompose (before Implement) │ ├────────────────────────────────────────────────────────────────┤ │ Principles: Auto-chain · State to file · Rich re-entry │ │ Delegate don't duplicate · Pause at decisions only │ └────────────────────────────────────────────────────────────────┘ ```