bhauman source-command-release
Use this skill when the user asks to run the migrated source command release.
Command Template
When the user invokes this command, create a new release by following these steps:
Step 1: Verify Branch
Ensure you are on the main branch. If not, warn the user and stop — releases should only be cut from main.
git branch --show-current
Step 2: Get Current Version
Determine the current version from git tags:
git describe --tags --abbrev=0
Parse the version number (e.g., v0.1.13 -> 0.1.13).
Step 3: Ask User for Bump Type
Use the AskUserQuestion tool to ask the user which version component to bump:
- patch: Increment patch version (e.g., 0.1.13 -> 0.1.14)
- minor: Increment minor version and reset patch (e.g., 0.1.13 -> 0.2.0)
- major: Increment major version and reset minor/patch (e.g., 0.1.13 -> 1.0.0)
Calculate the new version (e.g., v0.1.14).
Step 4: Collect Commits Since Last Tag
Get all commits since the last tag:
git log --oneline $(git describe --tags --abbrev=0)..HEAD
Parse the commit messages to understand what changed.
Step 5: Update CHANGELOG.md
Read the existing CHANGELOG.md file and:
- Add a new version section after
## [Unreleased]and before the previous version - Use the format:
## [X.X.X] - YYYY-MM-DD(use today's date) - Include a summary paragraph highlighting 2-3 most significant changes from a user's perspective (not developer perspective)
- Categorize commits into sections as appropriate:
- Major Changes - for significant new features or breaking changes (with subheadings if needed)
- Added - for new features
- Changed - for changes in existing functionality
- Fixed - for bug fixes
- Removed - for removed features
- Documentation - for documentation updates
- Internal - for internal refactoring (de-emphasize unless user-visible)
Focus on user-facing changes. Internal refactoring should be de-emphasized unless it has user-visible benefits.
Step 6: Commit Documentation Changes
Stage and commit the changelog update:
git add CHANGELOG.md
git commit -m "Release vX.X.X"
Replace X.X.X with the actual new version number.
Step 7: Create Version Tag
Create a new annotated tag for the release:
git tag -a vX.X.X -m "Release vX.X.X"
Step 8: Push Changes and Tags
Push the commit and tags to the remote repository:
# Push the commit
git push
# Push tags
git push --tags
Step 9: Create GitHub Release
Use gh release create to publish the release on GitHub. Use the same release notes from the CHANGELOG entry as the body:
gh release create vX.X.X --title "vX.X.X" --notes "RELEASE_NOTES_HERE"
Step 10: Report to User
Display a summary to the user:
- The new version number
- Number of commits included in this release
- Confirmation that CHANGELOG.md was updated
- Confirmation that tags were created and pushed
- Link to the GitHub release
Example Output to User
Release v0.1.14 created successfully!
Changes:
- 8 commits since v0.1.13
- CHANGELOG.md updated with release notes
Tags:
- Created tag: v0.1.14
Pushed to remote: origin
GitHub release: https://github.com/bhauman/clojure-mcp/releases/tag/v0.1.14
Error Handling
- If there are uncommitted changes, warn the user and ask if they want to continue
- If no commits exist since the last tag, warn the user that there's nothing to release
- If git push fails, show the error and suggest the user check their remote access
- If CHANGELOG.md is missing, report the error clearly