releasenotes
Automatically generates categorized changelogs from git commit history since the last tag.
Install
mkdir -p .claude/skills/releasenotes && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/3021" && unzip -o skill.zip -d .claude/skills/releasenotes && rm skill.zipInstalls to .claude/skills/releasenotes
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Generate formatted changelogs from git history since the last release tag. Use when preparing release notes that categorize changes into breaking changes, features, fixes, and other sections.Key capabilities
- →Identify most recent release tag
- →Retrieve commits and merged PRs
- →Categorize changes into sections
- →Include PR links and contributor attribution
- →Format output as markdown
How it works
The skill identifies the latest tag, extracts commits since that point, and organizes them into standard changelog categories based on repository history.
Inputs & outputs
When to use releasenotes
- →Generate release notes
- →Create changelog for new version
- →Categorize recent bug fixes
About this skill
Generate a changelog for all changes from the most recent release until now.
Steps
- Find the most recent release tag using
git tag --sort=-creatordate - Get commits and merged PRs since that tag
- Look at previous releases in this repo to match their format and style
- Evaluate every change and classify the highest semantic-version impact in the range:
- Patch: Bug fixes, maintenance, internal refactors, documentation, minor UI polish, and small improvements that do not add a meaningful new user-facing capability.
- Minor: Any substantive user-facing feature or meaningful new capability. Small improvements may remain patch-level when they do not materially expand what users can do.
- Major: Breaking changes, deliberately incompatible behavior, or unusually large features that materially redefine the product or its public contracts.
- Use the highest-impact change to recommend the next version. Mixed ranges take the highest classification.
- If the range contains any substantive feature, breaking change, unusually large feature, or ambiguous version impact, explain the classification and recommend a minor increment for normal features or a major increment for breaking changes and unusually large features. If the user already supplied a version, honor it and state any mismatch with the recommendation without asking them to repeat or reconfirm it. Otherwise, ask what the next version should be before assigning a version, creating a tag, or publishing a release.
- If the range is patch-only, use the next patch version unless the user supplied a different version or the repository follows another established versioning scheme.
- Categorize changes into sections: Breaking Changes, Added, Changed, Fixed, Notes
- Focus on user-facing changes, important bug fixes, and breaking changes
- Include PR links and contributor attribution
- Draft for user review only; do not create a tag or publish a GitHub release without explicit approval
When version impact is uncertain, ask rather than silently choosing the smaller increment. Do not treat commit labels alone as authoritative; evaluate the actual behavior described by the changes.
Output
State the recommended semantic-version impact and why. If a version decision is required, present the changelog with the version marked as pending and ask for the version. Otherwise, present the patch-version changelog in a markdown code block for review.
When not to use it
- →To publish a release without user approval
Prerequisites
Limitations
- →Drafts require manual review before publication
How it compares
This process automates the categorization and formatting of user-facing changes compared to manually reviewing git logs.
Compared to similar skills
releasenotes side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| releasenotes (this skill) | 1 | 2mo | No flags | Beginner |
| updating-changelog | 1 | 5mo | Review | Intermediate |
| bd-to-br-migration | 1 | 6mo | Review | Intermediate |
| readme-sync | 0 | 1mo | Review | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by exceptionless
View all by exceptionless →You might also like
updating-changelog
AztecProtocol
Updates changelog documentation for contract developers and node operators by analyzing branch changes relative to 'next'. Use when preparing a PR, updating migration notes, documenting breaking changes, or when asked to update changelog/release notes.
bd-to-br-migration
Dicklesworthstone
Migrate docs from bd (beads) to br (beads_rust). Use when updating AGENTS.md, converting bd commands, "bd sync" → "br sync --flush-only", or beads migration.
readme-sync
hiroshi0530
|
pr-demo
mikeyobrien
Use when creating animated demos (GIFs) for pull requests or documentation. Covers terminal recording with asciinema and conversion to GIF/SVG for GitHub embedding.
tutorial-any-repo
TKONIY
Automatically generate a file-by-file code tutorial website for any repository. Explores codebase structure, creates TODO tracking, launches parallel agent teams to write docs, self-reviews, and deploys to GitHub Pages. Use when user says "write a tutorial for this project", "explain this codebase",
ml-paper-writing
davila7
Write publication-ready ML/AI papers for NeurIPS, ICML, ICLR, ACL, AAAI, COLM. Use when drafting papers from research repos, structuring arguments, verifying citations, or preparing camera-ready submissions. Includes LaTeX templates, reviewer guidelines, and citation verification workflows.