← ClaudeAtlas

releaselisted

Cut a manual prerelease for jenkins-cli-ts: bump package version (unless the user specifies one), tag vX.Y.Z, push to trigger .github/workflows/release.yml, then write GitHub release notes in the project's cumulative prerelease style. Use when the user asks to release, ship, cut a version, publish a prerelease, bump and tag, or runs /release.
jatinbansal1998/jenkins-cli-ts · ★ 3 · AI & Automation · score 69
Install: claude install-skill jatinbansal1998/jenkins-cli-ts
# Release (manual prerelease) Ship a new **GitHub prerelease** for this repo. Releases are intentional and manual — post-merge CI only tests; it does not bump versions or open PRs. ## Hard rules 1. **Always prerelease.** Never mark a release as latest/stable unless the user explicitly asks to promote a stable release (out of scope for default flow). 2. **Version:** patch-bump `package.json` version unless the user names the next version (e.g. `0.8.0`). Tag is always `v` + that version (`v0.7.27`). 3. **Changelog:** write notes in the style of recent prereleases (see `references/release-notes-format.md`). Cumulative since the **latest stable** release, plus a "New Since previous prerelease" section and compare links. 4. **Publishing path:** commit version → tag → push → wait for Release workflow → set custom release body with `gh`. Do not invent alternate publish paths. 5. **Confirm before push** if anything is unexpected (dirty tree, wrong branch, tag already exists). Default branch is `main`. ## Preconditions Run from repo root. Abort with a clear message if any check fails. ```bash git status git branch --show-current # expect main git fetch --tags origin git pull --ff-only origin main ``` - Working tree must be clean (or only contain the version bump you are about to make). - `package.json` version and latest git tag should already match (or explain drift). - Require `gh` authenticated for this repo. Inspect current state: ```bash jq -r .versio