Release Manager

Skill: Release Manager

Orchestrate the complete release workflow from version bump through tagging and release notes.

Trigger

When the user asks to create a release, bump version, tag a release, or publish release notes.

Prerequisites

• [ ] On main or release/* branch
• [ ] All CI checks passing
• [ ] No uncommitted changes: git status --porcelain

Steps

Step 1: Determine Release Type

• [ ] Analyze commits since last tag: git log $(git describe --tags --abbrev=0)..HEAD --oneline
• [ ] Apply semver rules:

• [ ] Confirm with user before proceeding

Step 2: Update Version

• [ ] Update package.json version field (if Node.js project)
• [ ] Update any other version references (e.g., version.ts, pyproject.toml)
• [ ] Update lock file if needed: npm install --package-lock-only

Step 3: Generate Changelog

• [ ] Use the changelog-generator skill to produce the entry
• [ ] Prepend to CHANGELOG.md
• [ ] Review with user

Step 4: Create Release Commit

git add package.json package-lock.json CHANGELOG.md
git commit -m "chore(release): vX.Y.Z"

Step 5: Create Git Tag

git tag -a vX.Y.Z -m "Release vX.Y.Z"

Step 6: Generate Release Notes

Format for GitHub Release:

## What's Changed

### Highlights
- [Key feature or fix — 1 sentence each]

### Added
- feat(scope): description (#PR)

### Fixed
- fix(scope): description (#PR)

### Breaking Changes
- Description of what broke and migration steps

**Full Changelog**: https://github.com/org/repo/compare/vPREV...vX.Y.Z

Step 7: Push & Publish

• [ ] Push commits: git push origin main
• [ ] Push tag: git push origin vX.Y.Z
• [ ] Create GitHub release: gh release create vX.Y.Z --title "vX.Y.Z" --notes-file release-notes.md
• [ ] Verify release appears on GitHub

Step 8: Post-Release

• [ ] Verify CI runs on the tag
• [ ] Verify deployment triggers (if auto-deploy on tag)
• [ ] Notify team (Slack, email, or ticket update)
• [ ] Close related milestone/epic if applicable

Rules

• ALWAYS confirm version bump with user before executing
• ALWAYS run on clean working tree (no uncommitted changes)
• NEVER release from a feature branch
• NEVER skip changelog generation
• NEVER include secrets or internal URLs in release notes
• Follow semver strictly — breaking changes = major bump
• Tag format: vX.Y.Z (with v prefix)

Completion

Version bumped, changelog updated, tag created, release notes published. CI/CD triggered for deployment.

If a Step Fails

• Dirty working tree: Stash or commit changes first
• Tag already exists: Verify version, use next available
• Push fails: Check branch protection rules and permissions
• CI fails on tag: Fix forward with a patch release, don't delete the tag