parallel-shiplisted

# Parallel Ship Coordinate several PR-sized changes at once by launching background agents from the session that did the analysis, keeping high-risk changes (payments, auth, anything that shouldn't self-merge) in the main session. This is the chairperson pattern in its parallel form: the session that did the analysis is the only one holding the verified facts, so it stays in charge - writing complete briefs for disposable worker agents, judging their reports against context only it holds - rather than handing off a lossy summary to fresh sessions. ## When to use - One analysis/design context has produced 3+ shippable changes. - The changes touch **disjoint files** (check before launching; two agents on the same file = merge conflicts). - The spec for each change is concrete enough to write down (file paths, exact behavior, verification commands). If you cannot write the spec, the analysis is not finished - do not launch. When NOT to use: sequential phases where PR N+1 builds on PR N's code (use `epic-ship`), or a single change (use `ship-pr`). ## Workflow 1. **Carve the work into PRs by file/module boundary.** One worktree per PR, all forked from the same base via `bash ~/.claude/skills/ship-pr/scripts/worktree-new.sh <branch>` (never stacked - each agent starts from the remote default branch, not from another agent's branch). 2. **Split by risk, not by size.** - Mechanical/well-specified changes (new components, sweeps, copy, config) -> background agents, cheaper m