ship-epiclisted

# /abc:ship-epic — Parallel multi-repo shipping coordinator Drive a Linear **parent issue** with sub-issues to all-merged by firing one `/loop 6m /abc:ship-issue <SUB-ID>` per **ready** sub-issue, gating sub-issues with unmet `blocked by` relations, and aggregating status on the parent. Each worker (`/abc:ship-issue`) is independent — they run in parallel via their own cron entries, survive session close, and use Linear as the single source of truth. This skill is the **coordinator**. It does NOT implement code, open PRs/MRs, or run tests directly — those are the workers' jobs. See [`DESIGN.md`](./DESIGN.md) for the architectural design rationale. This file is the operational procedure. ## Hard rules - **Never** spawn a worker for a sub-issue that has an unmet `blocked by` relation. Wait for the upstream to reach `merged` first. - **Never** halt the epic just because one worker hits `blocked-user`. Other workers can continue; the blocked one waits for the human. - **Never** modify worker state directly (no edits to `<!-- ship-issue:* -->` comments). Workers own their own state machines. - **Always** self-cancel the epic's cron on terminal states (all merged, any failed). `/abc:ship-issue` self-cancels its own cron per its Phase 7; this skill mirrors that contract at the epic level. - If the parent has no sub-issues → reject and point the user at `/abc:ship-issue` for single tickets. - If the dependency graph has a cycle → halt with `blocked-user` and a one-line cycle des