ship

# 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...