/ship

name: ship
description: Use when finished work needs to go out — the user says "ship it", "update docs commit and push", "commit and push", or asks "anything else we need to update?" before a release or at the end of a work session.

Ship

Every ship is the same ritual: verify → docs → sync surfaces → version → secrets → de-vibe spot-check → quiz → commit → push. Work through the checklist in order; report what shipped and what was skipped.

**If the repo has its own ship skill (e.g. `/dashclaw-ship`), use that instead.**

Checklist

1. **Scope check.** `git status`. If other agents are working in this repo or a scope lock is active, stage only files you changed this session — never `git add -A` blindly. 2. **Verify.** Run the repo's test/lint/build (discover from package.json / pyproject / CI config). Read the output. Failures block the ship — fix first, don't push red. 3. **Docs.** Update README, changelog, and docs affected by the change. New env vars → `.env.example` + docs. New scripts and APIs documented. 4. **Sync surfaces.** If this repo publishes beyond the code, check each surface for drift: SDK/CLI version references, marketing site claims, skills/plugins/MCP manifests, generated docs. List each surface as checked or n/a. 5. **Version bump.** If a publishable package changed behavior, bump the version and changelog. Print the publish command for the user to run — never publish without explicit approval. 6. **Secrets scan.** Review the staged diff for secrets, tokens, private paths, `.env` files. Anything sensitive → unstage and flag. 7. **De-vibe spot-check.** Run the CRITICAL security greps and repo/git-tell checks from the de-vibe skill (`~/.claude/skills/de-vibe/references/code-tells.md` §1 and §5) against the staged diff and tracked files — committed `.env`, wildcard CORS, hardcoded keys, tracked AI artifacts (`.claude/`, `CLAUDE.md`, `.cursorrules`), attribution trailers not disabled, default title/favicon on web apps. Hits block the ship like a failed test. This is the spot-check only — for a project's first ship, or when the diff touches UI/marketing copy, suggest a full `/de-vibe` instead (audit + identity pass) and let the user decide. 8. **Merge quiz.** Before committing, quiz the user with 3–5 questions on what the diff assumes — invariants relied on, rollback path, surfaces affected, behavior changes a reviewer would probe. Each question cites `file:line` in the staged diff. A wrong or unsure answer means investigate before pushing, not push anyway. Skip (and say so) for trivial mechanical diffs. 9. **Commit and push.** Message follows repo convention. Push, then confirm CI kicked off (and passes, if it's fast). 10. **Report.** State what shipped, surfaces synced, version state, quiz outcome, and anything intentionally skipped.

Common mistakes

• Claiming shipped while tests were never run — verify means reading the output, not launching the command.
• Committing another agent's in-flight changes.
• Forgetting non-code surfaces (marketing site, SDK version references) — step 4 exists because these drifted repeatedly.