release

name

release

description

Cut a new release of `@sdw3/lab` end-to-end. Picks the right semver bump from the commits since the last `Bump version to X.Y.Z`, asks for approval, then lands the `Bump version to X.Y.Z` commit on a non-default branch, opens/reuses its PR, waits for checks, rebase-merges, and finally tags the merged commit on `main` so the JSR publish workflow fires. Use when the user invokes `/release`, asks to release, cut a release, or ship a new version.

Release skill

End-to-end release of @sdw3/lab. The version bump lands via PR so it goes through CI; the tag is created after the merge, pinned to the SHA on main. The tag push triggers .github/workflows/publish.yml, which publishes the package to JSR via OIDC.

Preconditions

Stop if any fail:

• Working tree is clean (git status --porcelain).
• There are commits above the last Bump version to X.Y.Z (otherwise nothing to release).
• gh auth status succeeds.

1. Pick the bump

Find the last Bump version to <version> with git log --format='%h %s' -n 50. The release range is <that-commit>..HEAD.

Inspect commits (git show --stat <sha>, git show <sha> when needed) and classify each by its subject:

• Major signal — breaking changes to the public surface: Remove X, Rename X to Y, an exported signature changing in a way consumers must adapt to (Make text required in runAsyncFunction, Make text optional in runAsyncFunction), or explicit BREAKING: / BREAKING CHANGE markers.
• Minor signal — additive changes: Add X, Allow X, Support X, Use X instead of Y, new options, new exports, new sub-paths.
• Patch signal — internal or non-breaking polish: Fix, Format, Sort, Reorder, Simplify, Improve (when it does not change the surface), Auto: / Autogenerated:, doc-only changes, internal refactors, dependency bumps that do not break consumers.

Ignore Bump version to … commits — they are not signals.

The highest signal wins. One major signal → major bump; otherwise one minor signal → minor bump; otherwise patch.

Pre-1.0 collapse: the package is in 0.x.y, so a major signal collapses to a minor bump. The skill never crosses the 1.0.0 boundary on its own — stabilisation is a hand-driven decision outside this skill.

Compute the new version from the current one in deno.json:

• major: X.Y.Z → (X+1).0.0
• minor: X.Y.Z → X.(Y+1).0
• patch: X.Y.Z → X.Y.(Z+1)

Show the plan in exactly this shape and stop, wait for explicit approval before continuing:

**Plan: release `vX.Y.Z` (`<level>` bump from `vA.B.C`).**

Commits since `<last-bump-sha>`:

- `abc1234` Add util to fetch document from url → minor
- `def5678` Fix runCommand spawn error handling → patch
- `9876fed` Auto: deno.lock → patch

Picked **`<level>`** because <reason — highest-signal commit, or pre-1.0 collapse>.

If the user disagrees with the inferred level, recompute with the suggested level, re-print the plan, and ask again.

2. Bump and ship

If on the default branch, create release/vX.Y.Z. Otherwise stay on the current branch.

Edit deno.json so "version": "X.Y.Z", then run the project's format command (npm run format, per CLAUDE.md):

git add -- deno.json
git commit -m "Bump version to X.Y.Z"

Run the merge-branch skill (push → PR → checks → rebase-merge → refresh main). PR title is Bump version to X.Y.Z when this skill created the branch; otherwise synthesize per merge-branch. PR body stays empty.

3. Tag

After the merge, HEAD should be the rebased bump commit on main. Verify before tagging:

SHA=$(git rev-parse HEAD)
SUBJECT=$(git log -1 --format='%s' "$SHA")

If $SUBJECT is not exactly Bump version to X.Y.Z, abort. Otherwise:

git tag "vX.Y.Z" "$SHA"
git push origin "vX.Y.Z"

Tags are lightweight (no -a), matching the project's history. The push triggers the JSR publish workflow. Confirm with one short line including the new version and the publish run URL (look up via gh run list --workflow=publish.yml -L 1).