| name | gh-release |
|---|---|
| description | Create a GitHub release for a given tag by gathering commits and PRs since the previous release and organizing them into a structured release notes template. |
| disable-model-invocation | true |
| argument-hint | <tag> |
| allowed-tools | Bash(git *), Bash(gh *) |
Create a GitHub release for tag $ARGUMENTS.
Run these commands in parallel to understand the release scope:
- Find the previous release tag:
gh release list --limit 5 - Verify the tag exists locally (fetch if needed):
git fetch --tags && git tag -l $ARGUMENTS - Get all commits between the previous release and this tag:
git log <previous-tag>..$ARGUMENTS --oneline - View the two most recent releases for style reference:
gh release view <latest-tag> gh release view <second-latest-tag>
For each commit that references a PR number, fetch author, title, and body:
gh pr view <number> --json author,title,number,body
Read the PR body to extract richer context: feature descriptions, sub-bullets, and implementation details. Use this to write more informative release notes than the commit title alone provides. A single PR may warrant multiple bullet points if it covers distinct user-facing changes.
First, exclude changes that are not relevant to library users:
- CI/CD infrastructure updates (e.g., GitHub Actions version bumps)
- Test-only dependencies (dependencies that only affect the test suite, not consumers)
- Internal dependencies not exposed to consumers (e.g., build-time tools, embedded submodules)
Map remaining changes to the appropriate section using conventional commit prefixes and labels as signals:
| Section | Signals |
|---|---|
| 📢 Breaking Changes | BREAKING CHANGE, ! suffix in scope, major API removal |
| 🛡️ Security Fixes | security, CVE references |
| 🚀 New Features | feat |
| 🐞 Bug Fixes | fix |
| 🔧 Maintenance | chore, refactor, perf, non-dep build changes |
| 🧪 Testing & CI/CD | test, ci commits that affect test logic (not infra) |
| 📖 Docs Updates | docs |
| 📦 Dependency Updates | build(deps) for user-facing runtime dependencies only |
Omit sections with no entries.
Use this template (omit empty sections):
## 📢 Breaking Changes
* <description> by @<author> in #<number>
## 🛡️ Security Fixes
* <description> by @<author> in #<number>
## 🚀 New Features
* <description> by @<author> in #<number>
## 🐞 Bug Fixes
* <description> by @<author> in #<number>
## 🔧 Maintenance
* <description> by @<author> in #<number>
## 🧪 Testing & CI/CD
* <description> by @<author> in #<number>
## 📖 Docs Updates
* <description> by @<author> in #<number>
## 📦 Dependency Updates
* Update `<package>` to <version> in #<number>
**Full Changelog**: https://github.com/<owner>/<repo>/compare/<previous-tag>...$ARGUMENTSGuidelines:
- For human-authored PRs include
by @<author>; omit for bots (Renovate, Dependabot) - Rephrase commit messages into user-facing English (drop the conventional commit prefix)
- For dependency updates: if the same package was bumped multiple times, keep only the entry for the final version and link to the latest PR; skip intermediate updates
- For dependency updates group them concisely; no need for author attribution
Show the complete release body to the user and ask for confirmation before publishing.
Once confirmed:
gh release create $ARGUMENTS --title "$ARGUMENTS" --notes "<body>"
Return the release URL.