shiplisted

# Ship ## Core Rule Block deployment when CHANGELOG, tests, or coverage gates fail. Preserve rollback capability at every step. Never ship from a dirty working tree. ## When to Use Invoke with `/ship` when: - Feature is complete and ready for merge - All local verification has passed - You want an automated ship pipeline instead of manual steps - Preparing a clean, bisectable PR from a feature branch ## Process ### Phase 1: Pre-flight Checks Before anything else, verify readiness: 1. **Working tree clean** — no uncommitted changes (stash or commit first) 2. **On a feature branch** — never ship directly from main/master 3. **Base branch up to date** — rebase or merge latest main 4. **Run full verification suite** in order. If `.claude/commands.json` exists, use the **declared** commands (`typecheck`, `lint`, `test`, `build`) verbatim — that file is the project's single source of truth, the same commands the quality gate runs. Only fall back to guessing when a key is absent: - Typecheck — declared `typecheck`, else `tsc` / `mypy` / `go vet` / `cargo check` - Lint — declared `lint`, else the project's configured linter - Tests — declared `test` (full suite, not just changed files) - Build — declared `build`, else the project's production build If any check fails, stop and report. Do not proceed with a failing pipeline. ### Phase 2: Coverage Audit Trace new/changed code paths and verify test coverage: 1. **Identify changed files** — `git diff main...HEAD