Ship

Skill travelhawk/forgeshift/.claude/skills/ship

Release gate and deploy - prepares the release commit (CHANGELOG, version bump), runs the automated release-gate workflow, walks the manual checklist, then tags and deploys per the project playbook.From its SKILL.md

Install

npx -y skills add travelhawk/forgeshift --skill ship

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.7 KB, as published. Nobody here has run it

/forge:ship — Prepare, gate, release

Ship "$ARGUMENTS" (or infer the next semver from the changes if not given).

0. Locate

Ensure the shell working directory is the PRODUCT root (the directory with the manifest/package.json) — normally the folder you launched claude in; the gates run real commands there. Ambiguous which product? Ask.

Harness assets (templates, playbooks) and the workflow scripts ship with the plugin, not the product. Resolve their home once and reuse it this session: FORGE_HOME="${CLAUDE_PLUGIN_ROOT:-$(forge-home)}" — then read e.g. $FORGE_HOME/templates/RELEASE-CHECKLIST.md.

1. Prepare the release commit (before any gate — the gate checks these)

CHANGELOG entry for this version: user-visible effects, not implementation notes (forge-etcher if it's more than a few lines). No CHANGELOG file yet (first release)? Create it now.
Bump the version consistently across all manifests.
Commit: release: <version>.

2. Automated gate

Run the release-gate workflow — Workflow tool with scriptPath: "$FORGE_HOME/.claude/workflows/release-gate.js" (resolve $FORGE_HOME as above and pass the absolute path), args: {dir: "<absolute product root>", context: "<version + change summary>"}. It runs static/security/docs checks in parallel, then tests → build → runtime smoke sequentially, each returning evidence, and fails closed (a gate that doesn't report blocks). The dir arg is required — workflows do NOT follow the shell cd; their agents run against dir.

NO-SHIP verdict blocks the release. Fix the blockers and re-run; never override. If a gate was skipped because the project lacks the tooling (no linter configured), decide with the user: add the tooling now, or accept and record the gap in PROGRESS.md. A skipped TESTS gate is never acceptable — that means wrong directory or a broken test setup; fix it.

3. Manual gate

Walk the user through the manual half of $FORGE_HOME/templates/RELEASE-CHECKLIST.md — core journey walked by a human, ugly paths, migrations reversible, rollback command known. These need human eyes; don't self-certify them.

Env vars in the deploy target: compare key names only — read the committed .env.example for the expected list and ask the user to confirm those keys exist in the deploy target. Never read actual .env values (denied by permissions, and rightly so). Copy the filled checklist to docs/releases/<version>.md.

3b. Release kit (user-facing products — apps, SaaS, sites)

Store/listing assets into docs/release-kit/<version>/ per $FORGE_HOME/templates/RELEASE-KIT.md. Libraries/CLIs/APIs: skip, say so. Unchanged since last release → copy forward, refresh "What's new" + changed screens only. Run both in parallel:

Texts — forge-etcher from docs/SPEC.md + CHANGELOG: name, subtitle/short description, long description, keywords, what's-new — within store char limits, one set per shipped language. Web: OG title/description + landing copy.
Images — forge-proof from the RUNNING app (reuse the walkthrough machinery from /forge:build §5b where present): screenshots at store sizes, feature graphic / OG image. Real data on screen, never lorem.

Store-distributed products (mobile/desktop stores): an incomplete kit blocks the release — the submission literally requires it. Web products: kit is default-on, gaps are report notes, not blockers.

4. Release

Tag v<version>.
Deploy per the deploy section of the matching playbook ($FORGE_HOME/docs/playbooks/<type>.md) or the project CLAUDE.md deploy command. First deploy ever → follow the playbook's first-deploy setup and record every manual step in the project docs.
Post-deploy smoke test against the LIVE deployment (the release-gate smoke was local): primary route/command responds, no error storm in logs.

5. Close

Report: version, gate evidence summary, release-kit location (or why skipped), deploy URL/artifact, post-deploy check result. Add the release to PROGRESS.md session log. If anything was skipped or accepted as a gap, it's in the report — plainly, not in a footnote.

Next → /forge:status to record the release and set the next handoff; /forge:next when the following version's scope is ready. On a NO-SHIP that was overridden into a partial release, name the gap-closing /forge:fix instead.