agentsclimarketplace

Ship

Skill mtthsnc/tempest/plugins/tempest/skills/ship

Tempest — a cross-harness software factory: opinionated build & QA workflows as portable Agent Skills for Claude Code and pi.

Install
npx -y skills add mtthsnc/tempest --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

  • 0 stars0 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.

What its author says it does

Copied from the file, not written here

Use when a change has been reviewed and you are ready to land it — merge the PR, cut the release, or push to production. Drives the change out the door: tests in place, changelog updated, a tight PR description, CI green, and the deploy verified end-to-end. Skip while still building or before review; this is the last mile, not the work itself.

SKILL.md

3.2 KB, 669 tokens by cl100k_base, as published. Nobody here has run it

ship — land a reviewed change cleanly

Overview

The loading dock. Take a change that has already been reviewed and get it out the door without surprises: tests in place, changelog updated, an honest PR description, CI green, and the deploy actually verified — not just assumed. Shipping is outward-facing and often irreversible, so the bar is "proven in the world," not "merged."

This is a STARTER skill — a generic spine. Rewrite the procedure below to encode your own release process: your CI provider, your changelog format, your deploy and rollback commands.

You do not build or re-review here. The change is done; your job is to land it safely.

Procedure

1. Confirm it's ready to ship

  • Verify the change has been reviewed and the working tree is clean — no stray edits, no debug code.
  • Confirm the diff is one coherent change. If unrelated work has crept in, split it out; ship one thing at a time.

2. Tests and changelog

  • Ensure tests cover the change and the full suite passes locally. A green local run is the floor.
  • Add a changelog entry for any user-facing change — what changed, in the user's words.

3. Write a tight PR description

  • What changed, in one or two sentences.
  • Why — the problem it solves or the reason it's worth shipping.
  • How verified — the exact tests run and behavior observed. Name the risk honestly; don't bury it.

4. Open the PR (or land) and wait for CI

  • Push and open the PR (or land, per your flow). Watch CI to completion.
  • If CI is red or skipped, stop and fix the cause — never override or merge around it.

5. Verify the deploy end-to-end

  • After merge/release, confirm the deploy itself works: hit the running service, check the version, observe the new behavior in the real environment. CI passing is not the deploy working.
  • If it's broken, roll back first, diagnose second.

6. Record what shipped

  • Note the version/PR/commit and what it delivered. Close the loop with whoever was waiting on it.

Common mistakes

  • Shipping on red or skipped CI. A merge that bypasses a failing gate is a future incident.
  • No changelog entry. User-facing changes that aren't recorded are changes nobody can find later.
  • A vague PR body. "Misc fixes" hides the risk. Say what changed and how you know it works.
  • Declaring done at green CI. CI passed ≠ deploy works. Verify the running thing.
  • Bundling unrelated changes. One release, one concern — so a rollback is surgical, not total.

Guardrails

  • Never land on red CI. Fix the gate, don't bypass it.
  • Require a changelog entry for every user-facing change.
  • Verify the deploy in the real environment before calling it shipped.
  • For anything irreversible or outward-facing — a release, a production push — confirm with the human before the point of no return.

Gives 1 of the 12 instructions most ship operate skills give in 669 tokens

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-06

  • document a rollback plan before deploymentin 40 of 779, across 21 files
  • create an annotated git tagin 21 of 779, across 20 files
  • Run the test suitein 20 of 779
  • update the changelogin 20 of 779, across 18 files
  • verify deployment health after launchin 19 of 779, across 10 files
  • clean up feature flags after full rolloutin 18 of 779, across 10 files
  • verify the working tree is cleanhere, and in 18 of 779
  • test both feature flag statesin 17 of 779, across 9 files
  • Make database migrations backward-compatiblein 16 of 779, across 8 files
  • set up error monitoring before launchin 15 of 779, across 7 files
  • monitor metrics at each rollout stagein 14 of 779, across 5 files
  • create a github releasein 14 of 779

Said here and by no other author read

  • split out unrelated work before shipping
  • write what changed and why in the PR
  • describe exactly how the change was verified
  • push the change and watch CI to completion
  • stop and fix the cause if CI is red or skipped
  • roll back first if the deploy is broken

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.