New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Dashclaw Ship

by ucsandman in ucsandman/DashClaw

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.

MITAuto-check passedDevelopment

Install Dashclaw Ship

skills CLI
$ npx skills add ucsandman/DashClaw --skill dashclaw-ship -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install ucsandman/DashClaw dashclaw-ship --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/ucsandman/DashClaw.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/dashclaw-ship .claude/skills/dashclaw-ship && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
dashclaw-ship
GitHub stars
310
Token cost
~7.2k tokens
SKILL.md length
3,855 words
Files
2 (incl. references)
Skills in repo
13
Repo updated
First seen
Licence
MIT

At a glance

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.

  • Works in 6 steps: Verify the generated pipeline… → Audit hand-authored surfaces for gaps → Update the hand-authored surfaces → …
  • The user wants to ship
  • SKILL.md covers The mission: GET TO MAIN AND…, First: what shipped, and what…, The workflow and Running it at scale…, plus 1 more section
  • Calls npm, git and node

What it does

Dashclaw Ship is an agent skill from ucsandman/DashClaw. 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, PROJECTDETAILS, SDK READMEs, /docs, generated artifacts (API inventory, OpenAPI, download bundles), plugins/skills/hooks/MCP, marketing/landing pages, the drift-prone…

Its SKILL.md is about 7.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/surfaces.md`).

It sits in Development, covering Technical documentation, MCP servers and Landing pages. It works with Model Context Protocol, npm, Vercel and OpenAPI. The repository describes itself as: Remote approvals, policy checks, and execution evidence for unattended AI agents. The licence is MIT.

When your agent uses it

  • The user wants to ship
  • Finish a change — get it on main
  • Bump the version
  • Refresh all the docs

Example prompts

  • “/dashclaw-ship”

Requirements

  • Python 3

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Verify the generated pipeline (regenerate only if stale)
  2. Audit hand-authored surfaces for gaps
  3. Update the hand-authored surfaces
  4. Mirror + rebuild bundles
  5. Bump the unified version (check first, then do it)
  6. Gate, land on main + live, then hand off the SDK publish

What it can do on your machine

Read from SKILL.md and the folder at commit 704824d. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npm
    • git
    • node
    • npx
    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npm, git, npx and gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Dashclaw Ship loads about 7.2k tokens when it runs, and up to ~11k if it reads all its reference files. Until then it costs about 249 tokens; SKILL.md has 3,855 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~249
When it runs · the whole SKILL.md, loaded when a task matches
~7.2k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~11k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from ucsandman/DashClaw at commit 704824d, republished under its MIT licence (© ucsandman). 3,855 words, ~7,218 tokens.

Download SKILL.mdSave it as .claude/skills/dashclaw-ship/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
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 after a normal feature merge they're usually already current. Verify with the read-only checks; regenerate only what fails:

Check (read-only)If it fails, regenerate with
npm run openapi:checknpm run openapi:generate
npm run api:inventory:checknpm run api:inventory:generate
npm run version:checkfix the hardcoded version (don't regenerate)
bundle currencynpm run bundles:refresh, then git status — staged generated diffs = it needed it; "unchanged" = already current

Generated set — never hand-edit (regenerate instead): the Python hook mirror under plugins/dashclaw/hooks/, the plugin skill mirror under plugins/dashclaw/skills/dashclaw-governance/, and the .zip/.manifest bundles under public/downloads/.

Phase 2 — Audit hand-authored surfaces for gaps

Generated artifacts cover the route/tool shape; they don't write prose, SDK READMEs, curated reference narratives, or marketing copy. Every hand-authored surface (references/surfaces.md has the full list) can drift in three ways — check all three, because none of them is machine-checked:

  1. Missing feature — the shipped thing isn't described where it should be. Grep each surface for the feature; absent = a gap.
  2. Stale count — a hardcoded number no longer matches its source of truth (Phase-1 "canonical facts").
  3. Old date — a freshness stamp that should say "today" still says a past date.

For a large sweep, fan out subagents — one per surface domain — to map gaps in parallel and return a concrete work-list. Partition by non-overlapping file groups so parallel edits never collide.

Sweep the counts repo-wide (the #1 source of "I had to fix it by hand")

The same number is duplicated across README, both SDK READMEs, both reference narratives, PROJECT_DETAILS.md, and the landing/downloads pages — so a single feature can stale a dozen strings. After you read each fresh count in Phase 1, grep the OLD number repo-wide and reconcile every hit; assume you missed one until the grep comes back clean.

Shortcut (if present): node scripts/check-doc-counts.mjs reconciles the high-traffic counts (routes, SDK methods, MCP tools/resources, pre-built policies) and flags freshness stamps that predate their file's last commit — run it to catch the gated subset fast, then still hand-sweep the surfaces it lists as UNCOVERED (MCP "N groups", skill section counts, landing-page prose). CI runs it with --strict.

The counts that recur (and where they hide) live in references/surfaces.md; the dense offender is README.md, which alone hardcodes:

  • route total + stable/beta/experimental (the "REST API" path),
  • MCP tool count + group count + resource count (the "MCP server" path),
  • Node + Python SDK method counts (the SDK path),
  • the pre-built guard-policy / "N safety switches" count (the safety-model section),
  • the governance-skill section count ("six new sections …").
UI discoverability gate — no feature ships invisible OR inoperable (an explicit step, every run)

The full contract is HUMAN-EXPERIENCE.md at the repo root — this gate enforces it. The known agent failure mode: the schema, route, repository, and tests all ship, but no human-facing surface renders the feature — it lands and disappears — or the human's role in it is a copy-paste command instead of a button (the v4.33.0 calibration-mine incident: proposal review lived in a GitHub Actions summary with copy-paste terminal commands; the operator rejected it). Docs mentioning it do not count; a deep URL nobody links to does not count. For each capability being shipped this run, answer four questions and treat a missing answer as a blocker to resolve (add the surface/link/control), not a note:

  1. Render surface — which page shows it? If the feature enriches an API response, name the component that renders the new data. "The API returns it" is not a surface.
  2. Click path — how does a human get there from somewhere they already are (nav, sidebar, an existing detail view, a dashboard card)? If the answer starts with "paste this URL", add the link.
  3. Zero-terminal test — walk the human's entire role for the feature end to end. Wherever their part is judgment (review/approve/ratify/tune/dismiss), it must be a button, toggle, or form in the product. Terminal commands + GitHub visits required of the human: zero, or the ship is incomplete. (CLI/API/MCP stay legitimate as secondary interfaces for agents and automation.)
  4. Rendered proof — drive the page headless (frontend-verify) and confirm the new element actually appears with real data and its controls work. Unit/API tests prove data exists, not that anyone can see or use it.

An API/SDK-only capability is legitimate only as an explicit recorded decision ("no UI surface because X" in the spec or ship summary) — never as a silent default, and even then the capability's existence must still be visible to humans somewhere (docs page, marketing, /setup). The root CLAUDE.md carries the build-time twin of this rule ("Definition of done includes a human-visible, human-operable surface"); this gate is the last net when that was missed.

Sweep the marketing site — an explicit step, every run (it's the one that gets skipped)

The marketing site is in-app (no separate repo) and it is part of every ship, not an optional extra. It drifts in a way the count checker can't see: a shipped feature simply absent from pages that claim completeness. Run this check explicitly:

  1. Grep the feature name across every marketing surface — app/page.tsx (landing), app/self-host/page.tsx, app/downloads/page.tsx, app/connect/page.tsx, app/guides/* — and judge each zero-hit: a page that enumerates capabilities and omits a shipped major subsystem is a gap; a page where the feature is genuinely out of scope (e.g. a framework guide) is fine.
  2. The dead-array trap (burned us once; arrays removed in v2.6d): app/landingData.js now exports ONLY the two rendered arrays (frameworkQuickstarts via app/components/StackQuickstarts.tsx, signals via app/page.tsx; corePrimitives was removed in the v4.57.1 landing redesign). All other landing feature lists are inline arrays inside app/page.tsx itself (e.g. the OPERATE_SURFACES control-room index) — put new capability copy there, never in a new landingData export. After any landing edit, verify with a grep that the feature name now appears in app/page.tsx.
  3. /self-host is NOT optional: its "What you just deployed" grid says "the full governance API surface — every feature works out of the box," so a missing category card there is a false completeness claim. Add a card for any major new subsystem.
  4. Accuracy of every actionable string (the operator's standing requirement — install paths and integration methods must be 100% right): each install command, package name + version pin, env var name, SDK method, MCP tool, and endpoint shown on these pages must match the code on this branch. Never write "(currently X)" published-registry version pins into prose — they stale at every publish.
Audit the dates — advance the living ones, never touch the historical ones

The user's standing rule is no old dates anywhere — but that means the dates that are supposed to track now, not the ones that anchor history. Get this backwards and you corrupt the record.

  • Advance to today (only if you actually touched the doc this sweep): freshness stamps that assert "current as of." These are last-verified: front-matter (PROJECT_DETAILS.md, docs/sdk-reference.md, docs/sdk-parity.md) and any "Last updated …" footer on a living doc (.impeccable.md, brand files). Pull the date from Phase 1 — a real current date, not a remembered one.
  • Never touch — these are historical anchors: CHANGELOG.md release dates (## [x.y.z] — <date>), "shipped/landed on <date>" notes, git-history references, dates inside .supergoal/, .organism/, docs/archive/AUDIT_FINDINGS.md, memory, and other scratch/working files. A past date here is correct; rewriting it is the bug.
  • Code-level frozen clocks are a real bug, not a doc stamp: a hardcoded new Date('2026-..') in app code (instead of new Date()) freezes countdowns/filters to that day. If your feature touched such a file, flag it — but it's a code fix, not part of the doc sweep.

When in doubt, ask: does this date claim to describe the present, or to record the past? Present → advance it. Past → leave it.

Two boundary gotchas to check explicitly
  • MCP tools are hand-curated (mcp-server/lib/tools.js / resources.js), not route-derived — adding routes adds zero MCP tools. Verify rather than assume a new tool is needed.
  • Some "spend"/cost endpoints are repository functions, not SDK methods (e.g. FinOps /api/finops/spend → getFleetSpend/getClaudeCodeSpend). They don't change SDK counts and must not be listed as SDK methods.
Phase 3 — Update the hand-authored surfaces

Edit the gaps from Phase 2. references/surfaces.md is the file-by-file checklist. Three things that bite if missed:

  • Reference narratives are SOURCES, not generated. public/downloads/dashclaw-governance/references/governance-patterns.md is hand-authored. Edit this — bundles:refresh mirrors it into the plugin / .claude / ~/.claude skill trees and rebuilds the zips. Editing the mirror copies is pointless (they get overwritten).
  • Marketing/landing copy obeys .impeccable.md (read it first): direct, declarative voice; lucide-react icons; CSS tokens, never hardcoded hex; and the four anti-references. In particular, frame x402 / payments as governed capability spend, never crypto / web3 / wallet.
  • Keep counts sourced. Write the numbers you read in "First", not numbers you remember.
  • Advance the stamp when you touch the doc. If you edit a surface that carries a last-verified: / "verified <date>" / "Last updated" stamp (PROJECT_DETAILS.md, docs/sdk-reference.md, docs/sdk-parity.md), bump that date to today's date from Phase 1 in the same edit — an unchanged stamp on a changed doc is itself a stale-date bug. Leave historical/CHANGELOG dates alone.
Phase 4 — Mirror + rebuild bundles

After editing any reference source (or any generated-source path), run npm run bundles:refresh to mirror the references into the plugin/project/global skill trees and rebuild the .zip/.manifest bundles. Then git status to see exactly what propagated.

Show full SKILL.md (1,618 more words)Show less
Phase 5 — Bump the unified version (check first, then do it)

DashClaw ships one version across the platform and both SDKs: package.json, sdk/package.json, and sdk-python/pyproject.toml must share the same number, enforced by npm run version:sync:check (CI + pre-commit) — and contracts/sdk/release-plan.json must carry that same number too (npm run contracts:check fails on drift, lines node_release_plan_version_mismatch / python_release_plan_version_mismatch). So the version number itself still advances on every ship, even a platform-only fix: you cannot bump the platform and leave the SDK manifests (or the release plan) behind. A bump is the norm.

What is conditional is the publish, not the number. Republishing both SDKs to npm + PyPI at every version — even when no SDK code changed — just burns a version number with no code delta. So an SDK release is only cut when the SDK source actually changed this run. Decide that here; you act on it in Phase 6.

Run this before the bump below, so the version-string churn from this run doesn't pollute the diff:

bash
# Feature branch — diff the SDK source for the work being shipped:
git diff --name-only origin/main...HEAD -- sdk sdk-python
# Shipping accumulated commits straight on main — diff since the previous release
# commit (find it in `git log --oneline`: the last `release:` / version-stamped commit):
git diff --name-only <last-release-commit>..HEAD -- sdk sdk-python

(Tags are not a reliable anchor here — release tagging stopped at v2.1.0 while the repo is on 4.x, so diff against the branch base / last release commit, not a tag.)

  • Real SDK source changed (anything under sdk/ or sdk-python/ beyond the version line in the two manifests) → this release republishes the SDKs; the Phase 6 reminder applies.
  • Only platform / docs / generated artifacts changed → the version advances but the SDKs are not republished. npm + PyPI stay at the last SDK release (non-contiguous versions are fine; the root self-dep ^4.x still resolves to the last published 4.x). Record this in release-plan.json (below).

Then check whether a bump is actually owed, so you don't double-bump: the feature you just swept for may already have bumped the version in its own commit. Compare the working tree against what's published:

bash
node -p "require('./package.json').version"   # current unified version (the three manifests)
npm view dashclaw version                       # last version published to npm
  • Manifest === published → the new work is unreleased at the already-published number, so it owes its own bump. Do it.
  • Manifest > published → a bump is already staged for this release; just confirm contracts/sdk/release-plan.json and the CHANGELOG agree with it, then skip to the release reminder in Phase 6.

When a bump is owed, pick the increment from what shipped, and say which you chose and why:

What shippedIncrement
Breaking SDK API change (renamed/removed method, changed signature)major x+1.0.0
New SDK method / route / subsystem (additive)minor x.y+1.0
Platform-only fix, hardening, or a docs/accuracy sweep with no new public surfacepatch x.y.z+1

Apply it across all three manifests at once — never hand-edit one — then re-lock:

bash
npm run version:set -- <x.y.z>   # rewrites the three manifests together
npm install                       # re-syncs package-lock.json at the new number

Then bring the two hand-authored version carriers in line:

  • contracts/sdk/release-plan.json — set current_version for both node and python to the new number (this is required even when the SDK didn't change — contracts:check fails if it ever drifts from the manifests), leave next_bump: "none", and write a one-line reason that states whether the SDK actually changed: for a platform-only ship say so explicitly (e.g. "no Node/Python SDK source change — version advances per the unified model but the SDKs are NOT republished; registry stays at <last published>"), and set domains: ["platform"]. When SDK code did ship, describe it and include the SDK domains. (A recurring "bump SDK release plan to match manifests" commit exists precisely because the version field here is easy to forget.)
  • CHANGELOG.md — rename the ## [Unreleased] block to ## [<x.y.z>] — <date> (with ### Added/Fixed/Security as fit), and open a fresh empty ## [Unreleased] above it.

Verify the bump is clean and read the output — both gate the build:

bash
npm run version:sync:check   # the three manifests agree
npm run version:check        # no version hardcoded into docs/CLAUDE.md (UI strings derive from the manifests via next.config.js)

Major-bump trap: the repo root depends on its own published SDK ("dashclaw": "^4.0.0"). A patch/minor stays inside that caret range, so npm install is enough. For a major bump the new SDK isn't on npm yet — leave the self-dep pointing at the OLD major until release:sdks has actually published, or npm ci in CI fails on a lockfile it can't resolve. Grep the repo for any removed methods before raising the self-dep across a major.

The plugin bundle and CLI version independently (plugins/dashclaw/.claude-plugin/plugin.json and the CLI manifest) and are deliberately outside the sync check — bump those only if the plugin or CLI itself changed.

Phase 6 — Gate, land on main + live, then hand off the SDK publish

A push is its own step — run and read the output, don't assert success:

  • npm run lint
  • npx vitest run — the full suite (targeted runs miss regressions in unrelated files; a transient flake in the approval-flow CLI test is known — re-run to confirm)
  • npx next build — for any change under app/**
  • npm run route-sql:check — if any route changed

Then commit + push to main with an explicit pathspec — never git add -A. Include the bumped manifests, package-lock.json, contracts/sdk/release-plan.json, and CHANGELOG.md in the same commit as the doc updates. Long-standing other-session files live uncommitted in the working tree (.impeccable.md, DESIGN.md, PRODUCT.md, stray docs/ specs); sweeping them in is a hygiene violation. The pre-commit hook will re-run bundles:refresh and stage generated artifacts — that's expected; let it ride.

Then land it on main — this is the point, not a follow-up. If the commit went onto a feature branch, get it to main now: rebase the branch onto the latest origin/main (generated files won't conflict once living-merge is installed; resolve any authored conflict), re-run the gates if the rebase pulled in new commits, then fast-forward/merge the branch into main and git push origin main. A push to main is what fires the Vercel production build (vercel.json buildCommand), so confirm the deploy goes green rather than assuming — watch it, or ask the user to — and only then is it live. Never end with a "here's how to land it" checklist; stopping at the branch is the exact failure mode this skill exists to kill.

Then cut the GitHub Release — every ship, no exceptions (v6.1 rule, 2026-07-05). Releases silently stopped between v4.20.1 and v4.59.0 and the public repo looked dormant through the project's fastest era; this step exists so that can't recur. After the push lands: git tag -a v<x.y.z> <release-commit-sha> -m "v<x.y.z> — <title>", git push origin v<x.y.z>, then gh release create v<x.y.z> --title "v<x.y.z> — <title>" --notes-file <notes> --latest. Notes come from the CHANGELOG entry for the version (plus links to the maintainer log / spec when the ship warrants), and per the charter's outward-acts clause they identify the AI maintainer honestly. Use the real SHA from git rev-parse — never reconstruct one from a short hash.

Finally, the SDK publish — conditional on the Phase 5 diff. npm run release:sdks builds and uploads both packages to npm + PyPI and needs the owner's npm login + a PyPI token, so it's outside this skill's reach either way. Whether you prompt it depends on whether the SDK source changed this release:

  • SDK source changed → after the push lands, surface a clear one-liner so the owner publishes:

    Bumped to <x.y.z> and pushed. The SDK changed this release — run npm run release:sdks to publish the Node + Python SDKs to npm + PyPI (owner-only — needs npm login + a PyPI token). It's idempotent: any version already on the registry is skipped, so a re-run is safe.

  • No SDK source change (platform / docs only) → do not nudge a publish. Say so instead, because holding the SDKs at their last release is the correct outcome — republishing identical code at a new number is exactly the churn this avoids:

    Bumped to <x.y.z> and pushed (platform/docs only — no SDK source change, so the Node + Python SDKs are intentionally not republished; npm + PyPI stay at <last published>).

This conditional also governs the case where Phase 5 found the bump was already staged: surface the publish reminder only if that staged release actually carried SDK source changes. (release:sdks is idempotent, so running it when nothing changed is harmless — but don't reflexively prompt it; the point is to stop cutting empty SDK releases.)

Drive Phases 2–3 with parallel subagents, the way the reference sweep did:

  1. Audit workflow — N read-only agents, one per surface domain (generated-pipeline, plugin/MCP/hooks, docs/SDK, marketing/landing), each returning a structured {auto_generated[], hand_authored_gaps[]} work-list.
  2. Update workflow — one implementer per non-overlapping file group, each handed the canonical facts + the .impeccable framing + its exact file list, followed by an adversarial reviewer that re-checks the facts (counts, no-crypto framing, no hardcoded hex) and that nothing unrelated changed.
  3. Then Phases 4–6 in the main session — mirror the bundles, decide and apply the version bump, read the gate output yourself before pushing, and surface the release:sdks reminder.

What "all of it" maps to

User saysReality
plugins / skills / hooks / MCP serverMostly generated — verify current (Phase 1); the only hand-authored pieces are the references/*.md sources (Phase 3) and the curated MCP tool/resource list (rarely changes)
connectorsPlugin manifests / .mcp.json / hooks.json enumerate no per-feature routes — usually no change; verify
docsHand-authored: PROJECT_DETAILS.md, README.md, app/docs/page.js, docs/sdk-reference.md, docs/sdk-parity.md, sdk/README.md, sdk-python/README.md. README.md is the densest — it hardcodes route, MCP-tool/group/resource, SDK-method, and guard-policy counts; sweep all of them
"no old dates" / "nothing stale" / "make everything accurate"The two classes CI doesn't catch (Phase 2): every hardcoded count (grep the old number repo-wide, reconcile every hit) and every freshness date-stamp (advance the living ones to today, never touch CHANGELOG / history dates)
marketing siteIn-app, no separate repo: app/page.tsx, app/landingData.js, app/downloads/page.tsx, app/self-host/page.tsx, app/connect/page.tsx, app/guides/* — an explicit Phase-2 step every run (see "Sweep the marketing site"), checking feature presence, the landingData dead-array trap, the /self-host completeness grid, and install-path accuracy
API inventory / OpenAPIGenerated — verify with the *:check commands
cut a release / bump the versionUnified platform+SDK number via npm run version:set + contracts/sdk/release-plan.json + CHANGELOG.md (Phase 5). The version number always advances; the SDK publish (npm run release:sdks, Phase 6) is reminded only when the SDK source actually changed this release — a platform-only ship bumps the number but does not republish the SDKs

Full per-file detail, the SDK-doc checklist, and the canonical-fact sources are in references/surfaces.md — read it during Phase 2/3.

© ucsandman, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (references) in .claude/skills/dashclaw-ship of ucsandman/DashClaw.

  • SKILL.md
  • references/surfaces.md

Open the folder on GitHubat commit 704824d

Compare with similar skills

Dashclaw Ship next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Dashclaw Ship compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Dashclaw Ship this skillucsandman/DashClaw310—~7.2kAutomated safety check: PassMIT
API Endpoint Contracttrycompai/comp2k—~2.7kAutomated safety check: PassAGPL-3.0
PR Reviewconfluentinc/mcp-confluent167—~4.6kAutomated safety check: NotesMIT
OpenAPI to MCP Servermcp-use/mcp-use11k—~5.2kAutomated safety check: PassApache-2.0
Zodjasonjgardner/blockbench-mcp-plugin4953 repos~1.4kAutomated safety check: PassGPL-3.0
SpikardGoldziher/spikard123—~799Automated safety check: PassMIT

Similar skills

  • API Endpoint Contract

    trycompai/comp

    The contract every new or modified API endpoint must follow so it is correct for the public OpenAPI spec, the MCP server (npm @trycompai/mcp-server), the ValidationPipe, and the docs.

    2k GitHub stars~2.7k tokensUpdated yesterday
    Backend & APIsAuto-check passed

  • PR Review

    confluentinc/mcp-confluent

    Reviews pull requests for the Confluent MCP server. An agent skill from confluentinc/mcp-confluent.

    167 GitHub stars~4.6k tokensUpdated today
    DevelopmentAuto-check: notes

  • OpenAPI to MCP Server

    mcp-use/mcp-use

    Turns an OpenAPI or Swagger spec into an MCP server with the mcp-use TypeScript SDK, mapping each operation to a tool, wiring auth, testing and deploying.

    11k GitHub stars~5.2k tokensUpdated today
    Backend & APIsAuto-check passed

  • Zod

    jasonjgardner/blockbench-mcp-plugin

    Zod schema validation best practices for type safety, parsing, and error handling.

    495 GitHub starsUsed in 3 repos~1.4k tokens
    DevelopmentAuto-check passed

  • Spikard

    Goldziher/spikard

    Scaffold Spikard projects and generate code from OpenAPI, AsyncAPI, OpenRPC, GraphQL, and Protobuf schemas using the Spikard CLI or its MCP server.

    123 GitHub stars~799 tokensUpdated 5 days ago
    Backend & APIsAuto-check passed

  • Kingdee MCP Dev

    WaHaiLong/KingdeeMCP

    Knowledge base for the Kingdee MCP Dev Squad. An agent skill from WaHaiLong/KingdeeMCP.

    105 GitHub stars~853 tokensUpdated 1 mo ago
    Backend & APIsAuto-check passed

More from ucsandman/DashClaw

All 13 skills in this repo

  • Dashclaw Governance

    ucsandman/DashClaw

    Governance behavior for AI agents governed by DashClaw. An agent skill from ucsandman/DashClaw.

    310 GitHub stars~2.7k tokensUpdated 3 days ago
    Auto-check passed

  • Repro

    ucsandman/DashClaw

    Turn a bug symptom into a structured, reproducible bug report — summary, environment, exact repro steps, actual vs expected, and evidence (logs, error text, failing route/test) — and then optionally…

    310 GitHub stars~1.5k tokensUpdated 3 days ago
    Auto-check passed

  • Muse Governance

    ucsandman/DashClaw

    Governance behavior for Muse agents governed by DashClaw. An agent skill from ucsandman/DashClaw.

    310 GitHub stars~1.7k tokensUpdated 3 days ago
    Auto-check passed

  • Build Dashclaw

    ucsandman/DashClaw

    Contribute to the DashClaw codebase — architecture, scaffolding, tests, CI

    310 GitHub stars~1.3k tokensUpdated 3 days ago
    Auto-check passed

  • Compliance Drift Evals

    ucsandman/DashClaw

    Set up compliance exports, drift detection, evaluations, scoring, and learning analytics

    310 GitHub stars~1.8k tokensUpdated 3 days ago
    Auto-check passed

  • Create Policies

    ucsandman/DashClaw

    Create and test DashClaw guard policies for agent governance

    310 GitHub stars~1.3k tokensUpdated 3 days ago
    Auto-check passed

Works with

Categories

Questions about Dashclaw Ship

What does Dashclaw Ship do?

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. Dashclaw Ship is an agent skill from ucsandman/DashClaw. 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.

When should I use Dashclaw Ship?

Dashclaw Ship fits situations like: the user wants to ship; finish a change — get it on main; bump the version; refresh all the docs.

How do I install Dashclaw Ship in Claude Code?

Run `npx skills add ucsandman/DashClaw --skill dashclaw-ship -a claude-code`. Or copy the skill folder (.claude/skills/dashclaw-ship in ucsandman/DashClaw) into .claude/skills/dashclaw-ship in your project. Claude Code loads it when a task matches its description.

How do I install Dashclaw Ship in Codex?

Run `npx skills add ucsandman/DashClaw --skill dashclaw-ship -a codex`. Or copy the skill folder (.claude/skills/dashclaw-ship in ucsandman/DashClaw) into .agents/skills/dashclaw-ship in your project. Codex loads it when a task matches its description.

Can I use Dashclaw Ship in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ucsandman/DashClaw --skill dashclaw-ship -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/dashclaw-ship, .gemini/skills/dashclaw-ship, .github/skills/dashclaw-ship and .opencode/skills/dashclaw-ship in your project.

What does Dashclaw Ship need to run?

Going by SKILL.md and its folder, Dashclaw Ship needs the command-line tools its instructions call (npm, git, node, npx and gh). Our summary lists: Python 3.

Does Dashclaw Ship access the network?

SKILL.md contains no URLs. Its commands use npm, git, npx and gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Dashclaw Ship safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Dashclaw Ship use?

Dashclaw Ship is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Dashclaw Ship use?

About 7.2k tokens (SKILL.md is roughly 29k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 3.3k tokens, read only when the agent opens those files.

What are the alternatives to Dashclaw Ship?

Skills that share tags, products or a category with Dashclaw Ship: API Endpoint Contract (trycompai/comp, 2k stars), PR Review (confluentinc/mcp-confluent, 167 stars), OpenAPI to MCP Server (mcp-use/mcp-use, 11k stars) and Zod (jasonjgardner/blockbench-mcp-plugin, 495 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Dashclaw Ship?

ucsandman (a GitHub user) maintains it in ucsandman/DashClaw, which has 310 GitHub stars. The repository holds 13 skills in this directory. The repository was last updated on October 6, 2026.

Source: ucsandman/DashClaw on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.