OpenShell: Skill for Claude Code

Release OpenShell

For the intended release version and branch, inspect the latest passing prerelease and changes since the previous stable release. Present the candidate to the maintainer. Once approved, dispatch Release from that branch:

gh workflow run release.yml --ref main

Without tag, Release detects the highest prerelease version reachable from the selected branch, then selects its highest-numbered passing candidate. It stops if that version has no qualified candidate or already has a stable tag. Supply -f tag=vX.Y.Z to select a version explicitly or retry a stable release.

Use the support branch instead of main for a previous minor version. That branch must contain the updated release workflows. Release selects the highest-numbered vX.Y.Z-pre.N reachable from that branch with a successful Pre-release run triggered by that tag or dispatched on the same branch, and matching passing release-tag-v1 qualification evidence. Missing or expired evidence blocks promotion. Inspect the selected candidate in the promotion job summary. The entire Pre-release run must succeed, including publication. If qualification passed but publication failed, rerun the failed jobs before promoting the candidate.

Release creates vX.Y.Z at that exact commit, then rebuilds and publishes all stable artifacts without rerunning qualification. Embedded versions change, so stable artifacts are not byte-identical to the qualified prerelease. An existing stable tag may be retried only if it already points to the selected commit. A retry publishes only missing artifacts; published images, charts, release assets, npm, and PyPI versions are kept, while the snap is uploaded again. Stable images are saved as OCI archives during the build and pushed under the stable version tags during publication. Their SBOMs are verified before updating latest; the qualified prerelease's commit-SHA image tags remain unchanged.

If no prerelease exists, agree on the version and source commit, then create and push vX.Y.Z-pre.1. Prerelease tag pushes start Pre-release. If the tag was created using GITHUB_TOKEN, dispatch Pre-release explicitly on the intended branch:

gh workflow run release-prerelease.yml --ref main -f tag=vX.Y.Z-pre.1

Once the first tag seeds a series, omit tag to create the next candidate at the selected branch's dispatch commit:

gh workflow run release-prerelease.yml --ref main

This selects the highest release series reachable from that branch and requires its -pre.1 seed there. It stops if that version is already stable. New version series always need an explicit seed. Manual runs create a new candidate even without new commits; pass an existing tag explicitly to retry that candidate. Candidate creation is serialized with Release Auto-Tag, which still skips unchanged commits and inactive series on main.

For example, start a support patch series by tagging its intended branch commit as v0.4.4-pre.1. Subsequent candidates and promotion use the support branch:

gh workflow run release-prerelease.yml --ref release/0.4
gh workflow run release.yml --ref release/0.4

Replace release/0.4 with the actual support branch. Use explicit tag inputs if its history also contains a higher version series.

Wait for the entire Pre-release run to pass before promoting it. Stable tag pushes do not start Release. Release Auto-Tag creates and dispatches prereleases on main.

Stable releases serialize across branches. A release older than the highest stable Git tag publishes versioned artifacts without moving GHCR latest, the GitHub latest release, npm latest, or snap latest/stable. Its npm package uses release-X.Y; snap files remain available in its GitHub Release rather than updating a Snap Store support track. Docs retain an immutable version and advance latest only for a newer version.

Watch the stable release run and report its result.