From hatch3r
Cuts a semantic versioned release: generates changelog from merged PRs, bumps version in package.json based on PR types, runs quality checks, creates git tag and GitHub release.
npx claudepluginhub hatch3r/hatch3r# Release — Cut a Versioned Release with Changelog
Cut a versioned release for **{owner}/{repo}** with changelog generation, quality verification, version bump, git tagging, GitHub release creation, and optional deploy verification. Follows semantic versioning (major/minor/patch) based on merged PR classification.
---
## Agent Pipeline
This command runs as a single orchestrator without sub-agent delegation. Quality verification uses direct CLI commands (lint, typecheck, test) rather than specialist agents.
## Shared Context
**Read the project's shared board context at the start of the.../release-notesEnhances GitHub release with categorized changelog notes from commits since previous tag after PR merge to main.
/releaseAutomates complete release workflow: analyzes git changes for semantic version bump, updates files/docs/changelog, commits/tags/pushes to remote, creates release on GitHub/GitLab/Bitbucket.
/setup-automated-releasesSets up GitHub Actions workflows for automated semantic releases using conventional commits, including version bumping, changelog generation, PR validation, and GitHub Releases.
/releaseCreates full release: verifies CI/CD, generates changelog, creates GitHub release with v<semver> tag, publishes packages, updates docs, notifies stakeholders.
/SKILLFinalizes git-flow release: verifies branch, runs tests, updates changelog, merges to main/develop with tag, creates GitHub release, switches to develop.
/devkit.generate-changelogGenerates and updates project CHANGELOG.md from Git history in Keep a Changelog format with Conventional Commits and auto-version detection from build files. Supports init, update, release, preview, validate actions.
Share bugs, ideas, or general feedback.
Cut a versioned release for {owner}/{repo} with changelog generation, quality verification, version bump, git tagging, GitHub release creation, and optional deploy verification. Follows semantic versioning (major/minor/patch) based on merged PR classification.
This command runs as a single orchestrator without sub-agent delegation. Quality verification uses direct CLI commands (lint, typecheck, test) rather than specialist agents.
Read the project's shared board context at the start of the run (e.g., .agents/commands/hatch3r-board-shared.md or equivalent). It contains GitHub Context, Project Reference, and tooling directives. Use GitHub MCP tools for issue/PR operations. Fallback to gh CLI for release creation (outside MCP catalog).
Default branch: Use board.defaultBranch from .agents/hatch.json (fallback: "main") for all git operations involving the base branch (e.g., git log, search_pull_requests with base, git push origin).
Consult learnings: If .agents/learnings/ exists, scan for learnings related to release processes, version bumping conventions, or prior release issues before starting.
git add, git commit, git push, and git tag when instructed.Execute these steps in order. Do not skip any step. Ask the user at every checkpoint marked with ASK.
package.json (version field).git tag -l --sort=-v:refname to get tags; git describe --tags --abbrev=0 for latest.git log {last-tag}..HEAD --merges --pretty=format:"%s %b" or list merged PRs via search_pull_requests with state:closed and base:{board.defaultBranch || "main"}, filtered by merge date after last tag.ASK: "Current version: {current}. Merged PRs since last tag: {count}. Proposed version: {proposed}. Confirm? (yes / override version / abort)"
## v{version} ({date})
### Features
- {PR title} (#{PR number}) by @{author}
### Fixes
- {PR title} (#{PR number}) by @{author}
### Refactors
- ...
### Docs
- ...
### Infra
- ...
ASK: "Changelog preview above. Confirm? (yes / edit / abort)"
Run (adapt to project):
npm run lint && npm run typecheck && npm run test
ASK: "Quality checks passed. Proceed to version bump? (yes / abort)"
version in package.json to the confirmed version.functions/package.json exists and tracks version, update it to the same version.package.json references the root version.ASK: "Version bump applied. Proceed to commit and tag? (yes / abort)"
git add package.json
If other package.json files were changed:
git add functions/package.json
# or other workspace packages
Commit:
git commit -m "chore: release v{version}"
ASK: "Commit created. Proceed to create tag? (yes / abort)"
git tag v{version}
git tag -d v{version} then git tag v{version}. Note: pushing will require --force for tags.ASK: "Tag created. Proceed to push? (yes / abort)"
Use {base} = board.defaultBranch from .agents/hatch.json (fallback: "main").
git push origin {base} && git push origin v{version}
git push origin {base}git push origin v{version}ASK: "Push complete. Proceed to create GitHub release? (yes / abort)"
GitHub releases are outside the MCP catalog. Use gh CLI:
gh release create v{version} --title "v{version}" --notes "{changelog}"
gh is unavailable: provide manual instructions for creating the release via GitHub web UI.ASK: "GitHub release created. Proceed to deploy verification? (yes / abort)"
ASK: "Deploy to production now? (yes / manual later)"
If yes:
npm run deploy or vercel --prod or similarnpm run deploy:functions or equivalentdocker build and push to registrynpm run deploy, CI/CD pipeline trigger)"If manual later:
issue_write with labels type:infra, status:in-progress, executor:human, title "Post-release monitoring: v{version}".For pre-release versions (alpha, beta, release candidate):
x.y.z-alpha.N (e.g., 1.2.0-alpha.1)x.y.z-beta.N (e.g., 1.2.0-beta.1)x.y.z-rc.N (e.g., 1.2.0-rc.1)v1.2.0-beta.1)--tag flag (npm publish --tag beta)latest — stable releases only (default install)beta — beta pre-releases (npm install package@beta)next — release candidates (npm install package@next)alpha — alpha pre-releasesWhen the user requests a pre-release, modify version determination:
ASK: "Pre-release type? (alpha / beta / rc). Current pre-release count for this version will be auto-incremented."
The proposed version becomes {base}-{type}.{N} where N is the next sequential number for that type/base combination. GitHub releases created for pre-releases use the --prerelease flag:
gh release create v{version} --title "v{version}" --notes "{changelog}" --prerelease
## [x.y.z] - YYYY-MM-DDFollow Keep a Changelog format:
### Added — new features### Changed — changes to existing functionality### Deprecated — soon-to-be removed features### Removed — removed features### Fixed — bug fixes### Security — vulnerability fixesThe changelog generated in Step 2 should also be written to CHANGELOG.md at the project root. If CHANGELOG.md exists, prepend the new entry after the file header. If it doesn't exist, create it with a standard header:
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/),
and this project adheres to [Semantic Versioning](https://semver.org/).
## [x.y.z] - YYYY-MM-DD
...
In Step 5, stage CHANGELOG.md alongside package.json:
git add package.json CHANGELOG.md
If a release introduces critical issues:
npm deprecate package@version "Critical issue — use version X instead"npm unpublish package@version (only if within npm's unpublish window)board.defaultBranch or main)Add to the post-release step:
ASK: "If critical issues are found during monitoring, do you want me to initiate rollback? (yes / no — I'll handle manually)"
If yes, execute the rollback procedure above. Always create a GitHub issue documenting the incident regardless of rollback method.
gh release create failure: Provide manual instructions. Do not skip the release.CHANGELOG.md has unexpected format, append entry at the top and warn user to verify.CHANGELOG.md must be updated.--prerelease flag on GitHub releases and --tag on npm publish.