/dashclaw-ship

name: dashclaw-ship
description: >-
  The single command that gets a DashClaw change ON MAIN AND LIVE — it resolves
  everything blocking production, never defers, and never hands back a checklist.
  Lands feature branches on main (rebase, gate, merge, push so Vercel deploys),
  bumps the unified platform+SDK version, and realigns every *description* of the
  system with the live code: README, PROJECT_DETAILS, SDK READMEs, /docs,
  generated artifacts (API inventory, OpenAPI, download bundles),
  plugins/skills/hooks/MCP, marketing/landing pages, the drift-prone hardcoded
  counts (routes, SDK methods, MCP tools/resources, guard policies) and stale
  freshness date-stamps. The one step it can't finish itself is the
  credential-gated SDK publish (`npm run release:sdks`). Use whenever the user
  wants to ship, land, or finish a change — get it on main, make it live, cut a
  release, bump the version, refresh all the docs, make everything accurate, fix
  wrong counts or old dates. Not for building or debugging the feature itself.

dashclaw-ship — full accuracy sweep

After a feature lands in DashClaw, many *descriptions* of the system go stale: generated artifacts, hand-authored docs, SDK READMEs, plugin/skill reference narratives, and the marketing site. This skill brings all of them back in line with the live code in one disciplined pass.

The mission: GET TO MAIN AND LIVE — never defer

dashclaw-ship is the single command that resolves **everything** that could keep a change off production, and then **lands it on main and ships it live**. It does not stop at "the docs are accurate," it does not hand back a checklist, and it never says "leave it for you to land." If something blocks main — a failing gate, a stale count, an unbumped version, or a feature stranded on a branch — the job is to *resolve that blocker and drive the code to main*, then confirm the deploy. The accuracy sweep below is the *means*, not the end; stale docs are just one blocker. The end state is: **our code is on main and the deploy is live.**

Registry publishing is automated: pushing the version tag fires `release.yml`, which publishes the SDKs **and `@dashclaw/cli`** via OIDC trusted publishing (each job skips versions already on the registry). `npm run release:sdks` is the local fallback (needs the owner's `npm login` + a PyPI token) and the Actions "Run workflow" button on release.yml is the manual re-trigger. **If `cli/**` source changed this ship, bump `cli/package.json` in the same commit** — npm serves stale content forever under an unbumped version. Everything else — gates, version bump, doc accuracy, **merging a feature branch into main, and pushing** so Vercel deploys — the skill does end to end.

**If the work is on a feature branch (not `main`), landing it is part of the job** — rebase the branch onto the latest main, resolve any conflict (generated files won't conflict once living-merge is installed), run the gates, then fast-forward/merge into main and push. "I committed it to a branch" is *not done*; "it's on main and the deploy is live" is done. (The only exception is an explicit, still-in-force user instruction this session to hold a specific branch back — honor that, but say so out loud; absent that, ship it.)

The whole job rests on one distinction:

• **Derived artifacts** are produced from the code by a generator. You **regenerate** them, never hand-edit. They usually self-heal via the pre-commit hook — your job is mostly to *verify* they're current.
• **Hand-authored surfaces** are prose, copy, and curated narratives a generator can't write. You **edit** these to add the new feature and fix stale facts.

Getting these backwards is the classic mistake (hand-editing a generated file that the next refresh overwrites, or expecting a generator to write marketing copy). The map below and `references/surfaces.md` keep them straight.

First: what shipped, and what is true now

Before touching anything, pin down two things:

1. **What changed** — the feature(s) to propagate. Ask the user, or read recent `git log`/diffs. The sweep closes the gap between that code and its descriptions. 2. **The canonical facts** — every number *and date* you write into docs must come from its single source of truth, *read live this run*. Counts and freshness stamps rot, and **nothing in CI catches them** (`docs:check` validates only links + the Next.js version; `version:check` only the unified version literal). So the audit below is the *only* guard — **never hardcode a count, never trust a number this skill or your memory quotes, derive each one fresh**:

• Route count + stable/beta/experimental breakdown → the summary header of `docs/api-inventory.md` (the generated truth).
• SDK method counts (Node / Python) → `npm run sdk:count`.
• MCP tool count + group count → `mcp-server/lib/tools.js` (count the `name: 'dashclaw_*'` entries and the distinct groups; they are hand-curated, so adding routes adds none).
• MCP resource count → `mcp-server/lib/resources.js`.
• Pre-built guard policies (the "N safety switches") → count the entries in `app/policies/lib/shields.js` (this one drifts silently — verify, don't copy the prose).
• Unified platform+SDK version → the manifests (`package.json`, `sdk/package.json`, `sdk-python/pyproject.toml` share one number); `npm run version:check` confirms no drift.
• **Today's date** (for the freshness stamps in Phase 3) → `Get-Date -Format yyyy-MM-dd` (PowerShell), or take it from the session's current-date context. You need a *real* current date so stamps advance to today, never to a guessed or remembered one.

The workflow

Phase 1 — Verify the generated pipeline (regenerate only if stale)

Most derived artifacts self-heal: the pre-commit hook runs `npm run bundles:refresh` (step id `bundles-refresh`) whenever `hooks/`, `plugins/dashclaw/`, or `public/downloads/dashclaw-governance/` change, and `openapi`/`api-inventory` regenerate alongside. So afte