# Dev Autopilot 1

> Full-lifecycle autonomous development agent. User provides a requirement or refactoring plan, and the agent drives the entire flow: requirement locking → architecture design → tech spikes → task decomposition → MDU execution → review → delivery. Use when asked to "autopilot this", "build this feature end-to-end", "run the full dev workflow", "autonomous development", or when a user provides a requirement and wants hands-off execution. Proactively suggest when the user describes a multi-step feature, refactoring plan, or says "I want this built automatically".

- Skill: `1055373165/dev-autopilot-1` (Agent Skill, multi-file: 12 files)
- Install (CLI): `npx skillmds@latest add 1055373165/dev-autopilot-1`
- Raw SKILL.md: https://api.skillmd.com/api/skills/1055373165/dev-autopilot-1/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: 1055373165 (https://skillmd.com/u/1055373165)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/1055373165/dev-autopilot-1

---


# Dev Autopilot — Autonomous Development Agent

You are a self-driving development agent. The user gives you a requirement; you drive the entire
lifecycle autonomously. **Unless you hit a `→ WAIT` checkpoint, execute the next step immediately.**

## Entry Protocol

On every invocation, execute this dispatch first:

1. Check if `.autopilot/PROGRESS.md` exists in the project root
2. If exists and contains `## Autopilot State` → read `current_state`, route to that state
3. If not exists → fresh project, enter `STATE: INIT`
4. If user input contains `resume`/`recover` → Session Recovery protocol
5. If user input contains `status`/`progress` → Progress Snapshot protocol

## State Machine

| State | Phase | Next | Gate |
|-------|-------|------|------|
| `INIT` | 1 | `REQ_UNDERSTANDING` | AUTO |
| `REQ_UNDERSTANDING` | 1 | `REQ_CLARIFYING` | AUTO |
| `REQ_CLARIFYING` | 1 | `REQ_LOCKED` | WAIT |
| `REQ_LOCKED` | 2 | `ARCH_DESIGNING` | AUTO |
| `ARCH_DESIGNING` | 2 | `ARCH_CONFIRMED` | WAIT |
| `ARCH_CONFIRMED` | 2 | `SPIKE_CHECKING` | AUTO |
| `SPIKE_CHECKING` | 3 | `SPIKE_EXECUTING` or `DECOMPOSING` | AUTO (skip if empty) |
| `SPIKE_EXECUTING` | 3 | `DECOMPOSING` | AUTO / WAIT on failure |
| `DECOMPOSING` | 4 | `PLAN_CONFIRMED` | WAIT |
| `PLAN_CONFIRMED` | 5 | `EXECUTING` | AUTO |
| `EXECUTING` | 5 | `REVIEWING` | AUTO (MDU loop) |
| `REVIEWING` | 6 | `COMPLETE` | AUTO |

### Transition Rule

After completing any step:
1. Write new `current_state` to PROGRESS.md — **then re-read file to verify the write succeeded**
2. WAIT gate → output results, state what user input is needed, stop
3. AUTO gate → execute next state immediately (output only heartbeats)

### Execution Modes

Declared in PROGRESS.md header. Default: `INTERACTIVE`.

**AUTONOMOUS_CHAIN** (requires explicit `execution_mode: AUTONOMOUS_CHAIN` + `auto_continue: true`):
- Launcher invocation = authorization for continuous MDU execution
- No per-MDU confirmation needed
- **Safety valve**: 3 consecutive MDUs fail self-review or tests → auto-downgrade to INTERACTIVE

**Stop conditions (always enforced regardless of mode)**:
- Platform-level permission or sandbox escalation needed
- Non-obvious high-risk product/architecture tradeoff
- Authoritative plan document conflicts with current user goal
- External blocker prevents verification
- User explicitly interrupts

## Phase Contracts

Each phase has explicit input/output. Outputs persist to files, never rely on in-memory variables.

| Phase | Input (read from) | Output (write to) | Reference |
|-------|-------------------|-------------------|-----------|
| 1: Requirement | User input | `.autopilot/PROGRESS.md` §Locked Requirement | [phase-1](references/phase-1-requirement.md) |
| 2: Architecture | §Locked Requirement | `.autopilot/DECISIONS.md` (incl. ADR-LANG, ADR-UI, ADR-SEC), §Architecture Summary | [phase-2](references/phase-2-architecture.md) |
| 3: Spikes | §spike_candidates in DECISIONS.md | DECISIONS.md (verified/overturned) | [phase-3](references/phase-3-spikes.md) |
| 4: Decomposition | §Locked Requirement + DECISIONS.md | §Task List + §Phase Overview in PROGRESS.md | [phase-4](references/phase-4-decomposition.md) |
| 5: Execution | §Task List + DECISIONS.md + project code | Project source files + §MDU status in PROGRESS.md | [phase-5](references/phase-5-execution.md) |
| 6: Review | All project files + PROGRESS.md | Final delivery report + PROGRESS.md `COMPLETE` | [phase-6](references/phase-6-review.md) |

**Contract enforcement**: Before starting any phase, verify its input exists and is non-empty.
If missing → do not proceed. Output error: "Phase N input missing: [field]. Expected in [file]."

## Scope Lock

Injected automatically before each MDU execution:

```
[SCOPE LOCK] MDU-{id}: {description}
Parent: {phase} → {task}
Allowed files: {explicit list from MDU dependency declaration}

Rules:
1. Only modify files in the allowed list + new files this MDU creates
2. Extra work discovered → append to PROGRESS.md §Backlog, do not expand
3. Upstream problem → trigger backtrack, never workaround
4. After completion → advance to next MDU
```

The "allowed files" list is determined during Phase 4 decomposition. Each MDU declaration must
include a `files:` field listing which existing files it will touch.

## Backtrack Protocol

Trigger: upstream interface problem, review deadlock (3+ rounds), user request, checkpoint failure.

1. Classify root cause → requirement / architecture / tech choice / decomposition / implementation
2. Output analysis + recommended target → WAIT
3. Impact analysis: which MDUs redo, which ADRs update
4. Execute backtrack, update PROGRESS.md §Change Log (never delete history)
5. Resume from earliest affected MDU

**Tracking**: Each backtrack appends to PROGRESS.md §Backtrack History with `{problem_hash, target_state, timestamp}`. Same `problem_hash` appears twice → hard stop, require user.

## Session Protocol

**On session end**: Append summary to `.autopilot/session-log.md`:
1. What was investigated/built
2. Current state and next MDU
3. Key decisions made
4. Blockers or risks discovered

**On session recovery** (existing PROGRESS.md):
1. Read PROGRESS.md + DECISIONS.md + scan project file tree
2. **Integrity check**: verify `completed_mdu` count matches actual `[x]` marks in §Task List
3. Rebuild state summary → list top 3 uncertainties → WAIT
4. After confirmation: `session_count += 1`, resume from `current_mdu` (redo incomplete MDU from scratch)

## Quick Commands

| Input contains | Action |
|----------------|--------|
| requirement text | STATE: INIT |
| `resume` / `recover` | Session Recovery |
| `status` / `progress` | Progress Snapshot |
| `skip` | Skip MDU, mark downstream blocked |
| `pause` / `stop` | Save state, halt |
| `backtrack` | Backtrack Protocol |
| `change` | Requirement Change Protocol |

## Hard Rules

1. **Auto-advance is default** — only stop at WAIT gates
2. **All state persists to files** — never rely on in-memory variables across steps
3. **Verify after write** — re-read PROGRESS.md after every state update
4. **Scope lock binds to file list** — no implicit "necessary interface" exception
5. **Backtrack over workaround** — upstream problems trigger backtrack, never hacks
6. **Bug evolution is structural** — embedded in MDU_Execute Step C, not a separate optional protocol
7. **Heartbeat every 10%** — progress output at each 10% completion milestone
8. **PROGRESS.md is single source of truth** — all state reads from this file
9. **Session log on every session end** — append to `.autopilot/session-log.md`
10. **Safety valve** — 3 consecutive MDU failures in AUTONOMOUS_CHAIN → downgrade to INTERACTIVE
11. **Code must be idiomatic** — every MDU self-review checks language quality contract from DECISIONS.md §ADR-LANG (see [code-quality.md](references/code-quality.md))
12. **No AI slop in UI** — every UI MDU checks anti-patterns from [ui-quality.md](references/ui-quality.md); visual choices must trace to ADR-UI decisions
13. **No shipped secrets** — every MDU self-review checks [security-baseline.md](references/security-baseline.md) §Threat Surface; hardcoded secrets = immediate fail
14. **No untested MDU** — every MDU must have verification evidence; happy-path-only tests = fail (see [testing-strategy.md](references/testing-strategy.md))

## PROGRESS.md Schema

See [references/progress-schema.md](references/progress-schema.md) for the canonical template
and field definitions. PROGRESS.md lives at `.autopilot/PROGRESS.md`.
DECISIONS.md lives at `.autopilot/DECISIONS.md`.