Menu
generate release notes for changes since a given tag
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | gen-release-notes |
| description | generate release notes for changes since a given tag |
| disable-model-invocation | true |
Generate professional release notes following the Keep a Changelog standard.
Input: Previous tag (e.g., v0.0.1)
$ARGUMENTS
Use extended thinking to analyze the changes thoroughly before generating release notes.
Run these commands to collect information about changes since the provided tag:
# Store the previous tag
PREV_TAG="$ARGUMENTS"
# Verify the tag exists
git tag -l "$PREV_TAG"
# Get the repo URL for PR links
git remote get-url origin
# List commits since last tag
git log ${PREV_TAG}..HEAD --pretty=format:"%h %s" --no-merges
# Get detailed diff stats
git diff ${PREV_TAG}..HEAD --stat
# List changed files by directory
git diff ${PREV_TAG}..HEAD --name-only | sort | uniq
Also gather PR information:
# Get merged PRs since the tag (requires gh CLI)
gh pr list --state merged --search "merged:>=$(git log -1 --format=%ci $PREV_TAG | cut -d' ' -f1)" --json number,title,author,labels
Categorize each change into exactly one of these groups (in this order):
| Category | Include | Exclude |
|---|---|---|
| Added | New features, new public APIs, new CLI commands | Internal utilities not exposed to users |
| Changed | Modified behavior, performance improvements, updated dependencies with user impact | Refactors with no behavior change |
| Deprecated | Features marked for future removal | - |
| Removed | Deleted features, removed public APIs | Removed internal code |
| Fixed | Bug fixes, error handling improvements | Test-only fixes |
| Security | Vulnerability patches, security hardening | - |
Exclude entirely:
Based on the changes, suggest the next version following Semantic Versioning:
Detect the tag format from existing tags (with or without v prefix).
Generate a CHANGELOG.md entry using this exact format:
## [VERSION] - YYYY-MM-DD
### Added
- **scope:** Add new feature description ([#54](REPO_URL/pull/54))
### Changed
- **Breaking:** Rename `oldName()` to `newName()` for consistency ([#145](REPO_URL/pull/145))
**Migration:** Replace all calls to `oldName()` with `newName()`.
### Deprecated
- **scope:** Deprecate `legacy_function()` in favor of `new_function()` ([#143](REPO_URL/pull/143))
### Removed
- **Breaking:** Remove deprecated `old_function()` ([#141](REPO_URL/pull/141))
### Fixed
- **scope:** Fix race condition when multiple workers access shared state ([#139](REPO_URL/pull/139))
### Security
- **deps:** Update vulnerable package to patched version ([#49](REPO_URL/pull/49))
Format requirements:
**server:**, **cli:**, **api:**Breaking changes:
**Breaking:****Migration:** block on the next line explaining exactly what users must changeTone:
Bad examples to avoid:
# BAD - Too vague
- Fixed bugs
- Performance improvements
- Updated dependencies
# BAD - Implementation-focused
- Refactored the internal state machine to use async/await
# BAD - Missing context
- Fixed #234
Good examples to follow:
# GOOD - Specific and user-focused
- **server:** Fix timeout errors when processing files larger than 100MB ([#234](URL))
- **cli:** Add `--dry-run` flag to preview changes before execution ([#235](URL))
- **api:** Improve cold-start latency from 2.3s to 0.8s by lazy-loading plugins ([#236](URL))
If CHANGELOG.md exists:
## [Unreleased] section (or at top if no Unreleased)If CHANGELOG.md doesn't exist, create it with this 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/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
Update the footer reference links at the bottom of the file. This step is mandatory — CodeRabbit and other reviewers will flag the changelog as incomplete if these are missing. Two edits are required:
a. Advance [Unreleased] so it compares against the new version instead of the previous one.
b. Insert a new [NEW_VERSION] line right below [Unreleased], comparing the previous tag to the new one.
Example diff (releasing 3.2.0 after 3.1.0):
-[Unreleased]: https://github.com/OWNER/REPO/compare/v3.1.0...HEAD
+[Unreleased]: https://github.com/OWNER/REPO/compare/v3.2.0...HEAD
+[3.2.0]: https://github.com/OWNER/REPO/compare/v3.1.0...v3.2.0
[3.1.0]: https://github.com/OWNER/REPO/compare/v3.0.0...v3.1.0
After editing, verify with: grep -E '^\[(Unreleased|NEW_VERSION)\]:' CHANGELOG.md — both lines must be present and [Unreleased] must point at the new tag, not the old one.
After updating the changelog, provide:
Map commit prefixes to changelog categories:
| Commit Prefix | Changelog Category |
|---|---|
feat(scope): | Added |
feat!(scope): | Added (with Breaking prefix) |
fix(scope): | Fixed |
perf(scope): | Changed |
security(scope): | Security |
docs:, chore:, ci:, test:, style: | Exclude |
Create Claude Code skills with best practices, structure, validation, and testing. Use when designing or refining skills, prompts, references, or supporting files.
Use when the user wants a cited, structured read of local documents and project knowledge. Triggers on: "analyze these docs", "scan my project for context", "read the docs folder", "summarize what's in .beagle/concepts/", "extract context from docs/", "what's in this folder", "go read everything in X and tell me what's there". Also invoked programmatically by other beagle skills (prfaq-beagle Ignition, brainstorm-beagle reference points, strategy-interview context grounding) via the companion contract. Does NOT trigger on codebase lookups ("find this function", "search the repo"), web research (use web-research), LLM-as-judge evaluation (use llm-judge), or document editing (use humanize-beagle). Produces a written scan plan, parallel-subagent findings, and a cited synthesis report on disk — never inline prose, never unsourced claims.
Use when the user has a fuzzy idea and wants to shape it into a concrete project spec before planning or building. Triggers on: "brainstorm this", "I have an idea for...", "help me think through this project", "what should I build", "spec this out". Also catches vague feature descriptions needing structured questioning to clarify scope. Does NOT write code, plan implementation, review strategy docs, or run strategy interviews — produces a WHAT/WHY spec through dialogue, not a HOW plan.
Use when the user wants to pressure-test a product, internal-tool, or OSS concept against Amazon's Working Backwards PRFAQ gauntlet before committing to a spec. Triggers on: "work backwards", "write a PRFAQ", "press release first", "is this idea worth building", "pressure-test this concept", "filter this before brainstorm", "is this a real product". Also catches solution-first pitches ("I want to build X that does Y") and technology-first pitches ("use AI to...") that need customer-first filtering. Produces a binary pass/fail verdict, not a polished doc. Hardcore coaching — direct, skeptical, concrete. On pass, hands off to brainstorm-beagle with a concept brief. Does NOT write code, plan implementation, scaffold projects, or draft specs.
Use when the user wants web research: gathering cited, multi-angle evidence on a specific question. Triggers on: "research X for me", "do web research on", "look up sources for", "find citations for", "gather evidence on", "what does the web say about X". Also invoked programmatically by other beagle skills (prfaq-beagle Ignition, brainstorm-beagle reference points, strategy-interview context grounding) via the companion contract. Does NOT trigger on codebase lookups ("find this function", "search the repo"), local file search, LLM-as-judge evaluation, or paywalled/auth-gated scraping. Produces a written plan, parallel-subagent findings, and a cited synthesis report on disk — never inline prose, never unsourced claims.
Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or implementation can begin. Triggers on: "resolve the open questions", "close the gaps in this spec", "research the open items", "finalize my spec", "make this spec implementation-ready", "answer the TBDs". Also triggers whenever the user points at a brainstorm-beagle spec and asks for research, proposals, or answers to unresolved items. Orchestrates parallel research subagents when available (falls back to inline sequential research otherwise), proposes answers one at a time for user approval, then rewrites the spec in place so it arrives at planning with no known gaps. Does NOT write code, design implementation, or create plans — it only produces a complete spec.