cockpit: Skill for Claude Code

Publish a cockpit release

A release is a short sequence where the ordering carries all the risk. The tarball is built from the working tree at publish time, so the only thing that guarantees the published package matches the tag is that the tree, the branch, the tag and the remote all agree first. make publish-check enforces that; this skill's job is to get everything into the state that check demands, in the right order, and to stop the moment something does not line up.

Never work around a failing check. Every refusal in publish-check is there because a published release once went wrong in exactly that way. If it fails, fix the cause or stop and report — do not retag, do not force, do not bump the version to dodge a conflict, do not publish from a branch that is not main.

An npm publish cannot be undone. A version number is spent the moment it is published, even if unpublished afterwards. Treat step 5 as the point of no return and be sure of everything before it.

Input

A version, or none. With no version, read package.json and propose it, then confirm with the user before touching anything. Never invent a version bump on your own: whether a release is a patch or a minor is the user's call.

Step 0: Establish the state

Run these and read them before doing anything:

git branch --show-current
git status --porcelain
node -p "require('./package.json').version"
gh pr list --json number,title,headRefName,baseRefName --limit 10
npm view @alexjbarnes/cockpit dist-tags
git log --oneline main..next | wc -l

Stop and report if: the tree is dirty, the version is already on npm, or there is an open PR from next to main you did not expect (someone else may be mid-release).

Step 1: Confirm the version and the changelog agree

package.json holds the version being released. CHANGELOG.md must have a ## [<version>] - <date> section at the top whose date is today, describing what is actually in main..next.

Check the changelog covers the commits: git log --oneline main..next. A commit that changed behaviour a user can see and is not represented in the changelog is a gap — add it (see the docs: bring the changelog up to date commits for the voice: what changed for the user, and why it was wrong before). Internal-only work goes under Internal, briefly.