Skill606 repo starsupdated today
autopilot
Autopilot processes pending work items from a project's intake pipeline by reading intake files, writing implementation briefs that scope the work and identify risks, then executing the build with verification steps. Use Autopilot for well-defined Small or Medium complexity tasks that are scoped and ready to move through intake to completion without parallel execution or exploratory work.
Install in Claude Code
Copygit clone --depth 1 https://github.com/SethGammon/Citadel /tmp/autopilot && cp -r /tmp/autopilot/skills/autopilot ~/.claude/skills/autopilotThen start a new Claude Code session; the skill loads automatically.
Definition
SKILL.md
# /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}
---
```