autopilot

/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:

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:

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

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

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

---
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}
---