Ship Check

---
name: ship-check
description: "One keystroke for the whole closing-time gauntlet before opening a PR. Runs, in order, /ship-check:sweep (remove leftover scaffolding) → /ship-check:loose-ends (wire up everything the feature should touch) → /ship-check:polish (fix copy & tone, strip AI tells) → /ship-check:but-for-real (actually run it and verify) → /ship-check:blast-radius (hunt regressions in existing features) → /ship-check:adversarial-code-review (final bug pass) — each as an isolated subagent so the heavy lifting never floods your context. Safe, reversible cleanups land automatically; anything that's a judgment call is held for a single confirmation at the end. Hands back ONE consolidated report. Use as the final step before a PR, or when the user says 'ship-check', 'ship check', 'pre-PR', 'final pass before the PR', 'run the gauntlet', or 'is this ready to ship'. It does NOT open the PR or merge; those are separate deliberate steps."
---

# Ship-check

The closing-time gauntlet. After a long worktree session the code works, but the branch is carrying the debris and gaps of getting there — debug probes, half-wired surfaces, AI-flavored copy, and whatever regressions the change quietly introduced. This runs the whole pre-PR pipeline in one shot and hands back a single report.

Two things make it safe to fire blind:

- **Each pass runs as its own subagent.** The heavy lifting — sweep's debris hunt, blast-radius's consumer greps, the full test run — happens in an isolated context and returns only a summary. Your main thread stays lean, you see one progress line per pass, and the back-end review passes don't drown in the front-end passes' noise.
- **Safe cleanups land automatically; judgment calls wait.** Mechanical, reversible changes (debug removal, config/locale sync, unambiguous AI tells) just get done. Anything with a real decision — a deletion, a behavior change, a deliberate-looking rewrite, new wiring — is held, with a ready diff, for **one confirmation gate at the end.** One keystroke to run, one review to confirm.

## The passes — order matters

1. **`/ship-check:sweep`** — strip the leftover scaffolding *first*, so every later pass reviews the real code instead of your debug noise.
2. **`/ship-check:loose-ends`** — wire up every surface the feature should reach now that the code is clean.
3. **`/ship-check:polish`** — fix copy and tone on what's now the final, complete surface.
4. **`/ship-check:but-for-real`** — *now* actually run it: build, full test suite, **and a real browser drive of the exact flow you changed** for any UI change (launched the way the project really launches, watched render and behave, zero console/network errors). Verifies the *new feature* genuinely works — not just that the suite is green.
5. **`/ship-check:blast-radius`** — work outward from what the diff modified and hunt for *existing* features the change might have quietly broken. Verifies the *old* stuff still works.
6. **`/ship-check:adversarial-code-review`** — the final bug pass, on a clean, complete, verified diff.

Clean before complete before polish before verify-new before protect-old before review. You never bug-review debug noise; you want the run-it step to validate the edits the earlier passes made; and you want the regression hunt and bug hunt running against the final state, not one three passes have since changed. The two verify/review passes split a real distinction — `but-for-real` proves the new feature works, `blast-radius` proves the change didn't break a feature that already did.

## How it runs

**Snapshot first.** Capture the starting point so the whole run is one undo away — record `git rev-parse HEAD` and whether the tree was clean. Auto-applied changes land as unstaged edits; the report tells the user how to revert any pass or the whole run.