ship-epic-ghlisted

# /abc:ship-epic-gh — Parallel multi-repo shipping coordinator (GitHub) Drive a GitHub **parent issue** whose body holds a managed `## Sub-issues` task-list to all-merged by firing one `/loop 6m /abc:ship-issue-gh <owner>/<repo>#<n>` per **ready** child, gating children with unmet `blocked-by:*` labels, and aggregating status on the parent. Each worker (`/abc:ship-issue-gh`) is independent — they run in parallel via their own cron entries, survive session close, and use GitHub Issues as the single source of truth. This skill is the **coordinator**. It does NOT implement code, open PRs, or run tests directly — those are the workers' jobs. This is the GitHub-Issues sibling of [`/abc:ship-epic`](../ship-epic/SKILL.md). The two are deliberately parallel skills — pick by tracker, not auto-detect. The label scheme, task-list fence, and marker comments it depends on are documented in [`../scaffold-sub-issues-gh/github-conventions.md`](../scaffold-sub-issues-gh/github-conventions.md). See [`DESIGN.md`](./DESIGN.md) for the architectural rationale + locked decisions specific to the GitHub case. This file is the operational procedure. ## Hard rules - **Never** spawn a worker for a child that has an unmet `blocked-by:*` label. 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:* --