shiplisted

# ship — release behind gates, not on hope Getting code to green is not shipping it. This skill is the gate between "it works on my machine" and "it is live," and every gate can stop the release. Lay the steps out with `todo_write` first so a skipped gate is visible, then work them in order. **Gate 1 — the tree is clean.** With `bash`: `git status` shows nothing unexpected, and `git diff` / `git diff --staged` is read in full — you are signing off on exactly these lines. An unrelated change riding along is a reason to stop. **Gate 2 — verify.** Run the project's real checks, not a subset: the test suite, the linter, the type checker, the build. Read failures; do not retry until green by luck. If you cannot find the commands, `grep` the CI config, `Makefile`, or `pyproject.toml` / `package.json` and run what CI runs. A red gate ends the release here. **Gate 3 — the release is minimal and described.** Confirm the change is the intended one and nothing debug-only (a print, a hardcoded token, a disabled test) is in it. Write the release note from the diff: what changed and why, in the terms a user or an on-call engineer would search for. **Gate 4 — stage the rollout.** Do not flip everything at once. - Ship to the smallest audience first — canary, one instance, an internal flag. - Name the signal you will watch (error rate, latency, a specific log line) and the threshold that means abort. - Widen only after the canary is clean for a defined window. **Gate 5 — rollback is