Release Skill

You are a release management expert. When this skill is invoked, prepare a new release for the project.

What This Skill Does

Bumps the version number, updates changelog, creates a git tag, and prepares release artifacts.

Step-by-Step Instructions

1. Determine the version bump. Analyze commits since the last release:

   • Major (breaking changes): Any commit with BREAKING CHANGE or ! after the type
   • Minor (new features): Any feat: commit
   • Patch (bug fixes): Only fix:, perf:, or refactor: commits
   • If the user specifies a version, use that instead
   • Follow semantic versioning (semver.org)

2. Find the current version. Check:

   • package.json version field
   • Cargo.toml version field
   • pyproject.toml version field
   • Git tags (git describe --tags --abbrev=0)
   • Any other version file in the project

3. Update version numbers. Bump the version in all relevant files:

   • package.json (and package-lock.json via npm version)
   • Any other files that contain the version string
   • Do not miss hardcoded version strings

4. Update the changelog. Generate a changelog entry for this release:

   • Follow the project’s existing changelog format
   • Include the date and new version number
   • Categorize changes (see the changelog skill for format)

5. Run the full test suite. All tests must pass before releasing:

   • npm test or equivalent
   • npm run build to verify the build works
   • npm run lint for good measure

6. Create the release commit and tag:

   • Commit all version changes: git commit -m "chore: release vX.Y.Z"
   • Create an annotated tag: git tag -a vX.Y.Z -m "Release vX.Y.Z"
   • Do NOT push yet. Let the user review first.

7. Prepare the release summary:

## Release vX.Y.Z Ready

### Version Bump
- Previous: vA.B.C
- New: vX.Y.Z (patch/minor/major)

### Changes Included
- Summary of changes

### Files Modified
- List of files where version was updated

### Next Steps
1. Review the changes: `git log --oneline vA.B.C..HEAD`
2. Push: `git push && git push --tags`
3. Create GitHub release: `gh release create vX.Y.Z`

Guidelines

• Never push tags or publish without explicit user confirmation.
• If the project uses a monorepo, handle versioning per package.
• If there is a publish step (npm publish, cargo publish), prepare but do not execute it.
• Check for pre-release dependencies before releasing. Do not release with 0.0.0-beta deps.
• If a CI/CD pipeline handles releases, note that and adjust the workflow accordingly.
• Ensure the git working directory is clean before starting.
• Use annotated tags, not lightweight tags.
• If the project has a RELEASING.md or similar guide, follow it.