epic-shiplisted

# Epic Ship Runs a multi-phase epic (a markdown plan doc with a phase list, e.g. `docs/epics/epic-<n>.md`) phase by phase, calling the `ship-pr` skill once per phase for the actual worktree/implement/verify/PR/merge/cleanup mechanics, until every phase is shipped or you hit an explicit review checkpoint. This is the sequential composition operator of the ship stack: `parallel-ship` fans out when changes are independent; this skill loops when phase N+1 builds on phase N's code. The default failure mode this skill exists to fix is **stalling after a routine merge waiting to be told to continue**. `ship-pr` ships one PR and stops - epic-ship is what decides to call it again immediately. ## Step 0: Reconcile against reality first Before touching anything: 1. `git status` and `git branch --show-current` at the repo root - confirm it's on the default branch and clean. If not clean and the changes aren't yours, stop and tell the user. 2. `git worktree list` - confirm no stray worktree already covers this epic's phases. 3. Read the epic doc fully: phase list, current status column, and any explicit checkpoint markers (see Step 3). 4. `gh pr list --search "<epic keyword>" --state all` and `git log --oneline -20` - confirm what's _actually_ already merged before trusting the epic doc's status table. Epic docs drift; git and GitHub are the source of truth. This step exists because past sessions have reported phases as unshipped when they'd already landed, or vice versa - always rec