Autopilot

---
name: autopilot
license: MIT
description: >-
  Intake-to-delivery pipeline. Processes pending items from .planning/intake/:
  briefs new ideas, executes approved work through research → plan → build → verify.
  Drop a file in .planning/intake/ and invoke this skill.
user-invocable: true
auto-trigger: false
trigger_keywords:
  - intake
  - process pending
  - pipeline
last-updated: 2026-03-20
---

# /autopilot — Intake Pipeline

## Orientation

Use Autopilot when:
- There are pending items in `.planning/intake/`
- You want to process intake items without manual orchestration
- The work is scoped and well-defined (Small or Medium complexity)

Do NOT use Autopilot for:
- Large, multi-session campaigns (use Archon)
- Parallel execution (use Fleet)
- Exploratory or open-ended work (use Marshal)

## Protocol

### Step 0: DELIVERY PREFLIGHT

When the user names a specific intake file or asks for "intake to PR", prefer
the deterministic delivery preflight before freeform build work:

```bash
node scripts/deliver.js --intake .planning/intake/{item}.md
```

If no specific intake file is named, use:

```
node scripts/deliver.js --next
```

This selects the highest-priority pending item in `.planning/intake/` and keeps
the golden path deterministic.

This creates an active campaign with claimed scope, acceptance criteria, map
context, and exit evidence rows, then marks the intake item `in-progress`.
Continue from the created campaign with `/do continue`.

After build and verification, package the delivery before marking the campaign
complete:

```bash
node scripts/package-delivery.js {campaign-slug}
```

If a PR exists, record the PR as the review target:

```bash
node scripts/package-delivery.js {campaign-slug} --pr https://github.com/{owner}/{repo}/pull/{number}
```

### Step 1: SCAN

Read all files in `.planning/intake/` and identify:
- `status: pending` → needs briefing
- `status: briefed` → ready to build
- `status: approved` → ready to build
- `status: in-progress` → check if stuck

### Step 2: BRIEF (for pending items)

For each pending item:

1. Read the intake file
2. Read related files mentioned in the description
3. Research the scope: what files exist, what patterns are established
4. Write the brief:
   - **Scope**: Small / Medium / Large
   - **Approach**: How to implement (2-3 sentences)
   - **Files**: Which files to create or modify
   - **Quality gates**: What must be true when done
   - **Risks**: What could go wrong
5. Update the item's status to `briefed`

### Step 3: BUILD (for briefed/approved items)

For each briefed item (smallest first):

1. Read the brief
2. Execute the approach:
   - Create or modify the listed files
   - Follow the project's conventions (CLAUDE.md)
   - Run typecheck after each change
3. Verify:
   - All quality gates pass
   - Typecheck clean
   - Tests pass (if applicable)
4. Update status to `completed`

### Step 4: REPORT

Output a summary of what was processed:

```
Autopilot processed {N} items:
  ✓ {item-1}: briefed → built → verified
  ✓ {item-2}: briefed
  ✗ {item-3}: blocked — {reason}
```

## Intake Item Format

```markdown
---
title: "Feature Name"
status: pending | briefed | approved | in-progress | completed
priority: normal | high
target: src/path/to/affected/area/
---

Description of what needs to be done...
```

## Fringe Cases

- **`.planning/intake/` is empty or does not exist**: Output "Nothing to process — `.planning/intake/` is empty. Drop a file there or run `/do setup` to initialize." Do not error.
- **Intake item has no clear action**: If the description is too vague to execute, ask the user one clarifying question or skip the item with a note: "Skipped — direction unclear. Update the intake file and re-run."
- **Item status is unrecognized**: Treat unknown statuses as `pending` and proceed through the brief → build flow.
- **Typecheck fails during build**: Record the failure in the item's status, move on to the next item, and report the blocker in the exit summary.
- **`.planning/` does not exist**: Output a setup hint and exit cleanly. Autopilot requires `.planning/intake/` to operate — if the directory is absent, treat as empty intake and suggest running `/do setup`.

## Contextual Gates

**Disclosure:** "Processing intake queue: N items pending. Will dispatch skills per item."
**Reversibility:** amber — processes intake items by dispatching other skills that may modify files; undo depends on dispatched skills
**Trust gates:**
- Any: review intake and briefing.
- Familiar (5+ sessions): autopilot runs autonomously on queued items; novices should review intake before running.

## Quality Gates

- Never build without reading CLAUDE.md first
- Run typecheck after every file change
- Mark items as completed only when verification passes
- If an item is blocked, record the reason and move on

## Exit Protocol

```
---HANDOFF---
- Processed {N} intake items
- Built: {list of completed items}
- Blocked: {list with reasons}
- Remaining: {count of items still pending}
---
```