shiplisted

# Ship a Pacer release This skill is the **orchestration and the gate**. The deterministic plumbing — computing the next version, tagging, watching the Release workflow, verifying the published artifact — is in `bin/ship.sh`. Read `docs/releasing.md` for the pipeline and one-time setup. **There is exactly ONE human gate: a single approval right after a local install.** Everything after it is autonomous and backgrounded. The whole point is that a release costs almost no attention (and almost no expensive model tokens): the waiting and verifying happen in a backgrounded script, and the draft/review chores go to a cheap model. ## 0 · Before a release (during the work) - Branches and PRs are your judgement — stack/rename branches freely as scope grows, push for backup whenever. **Do not open the PR yet**, and never tag/merge here. - When the work is done, `make install` so the maintainer can see it live. Stop there. ## 1 · The gate — right after `make install` is live 1. `bin/ship.sh preflight` → prints the suggested bump (patch, or **minor** if a `@Model`/schema change is detected — you confirm; minor = a SwiftData reset) and the next version. 2. `bin/ship.sh notes <version>` → previews the **exact** notes CI will publish (`--generate-notes`), so what you show matches what ships. 3. Surface **bump + notes**: - **Not pre-authorized** → ask **once** with `AskUserQuestion` (it push- notifies the maintainer and blocks). Offer: ship it · hold · change the