shiplisted

# Ship Every ship is the same ritual: verify → docs → marketing site → sync surfaces → knowledge → version → secrets → de-vibe spot-check → self-check → 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 every doc the change touches, in this commit and not a later sweep: README run steps, changelog, and internal docs (`docs/`, ADRs, runbooks, architecture notes, the repo's own `CLAUDE.md` if a convention changed). New env vars → `.env.example` + docs. New scripts and APIs get request/response examples. 4. **Marketing site.** If a public surface exists — a `site/`, `web/`, `www/`, or `landing/` dir here, a separate site repo, or a URL in the README — open the pages this change affects and fix drift: feature lists, screenshots, pricing, version numbers, docs pages, changelog/release page. Rendered proof, not a grep of the source: `curl -s <url> | grep -c <version|feature>` against the live URL, and `declick web tree <url> --selector <css> --limit 20` for its links and buttons, cost