| name | git-release-notes-generation |
| description | Generate release notes from git branch commit history and analyze changes. Use when you want to generate release notes, prepare release notes, prep for a PR, find what changed in this branch, or get branch change summary. |
| trigger_phrases | ["generate release notes","prepare release notes","generate a PR description"] |
| tags | ["git","github"] |
Generate Release Notes from Git Branch
Analyze git commit history and generate customer-facing "What's New" and technical release notes from branch changes.
When this skill is used during PR preparation, the generated notes usually make a strong starting point for the pull request description.
Quick Commands
See what changed on your branch:
git log main..HEAD --oneline
Get detailed commit messages:
git log main..HEAD --pretty=format:"%h %s%n%n%b%n"
See file changes:
git diff main..HEAD --name-status
Get commit stats:
git log main..HEAD --stat
Release Notes Template
Use this structure for your release notes:
Features and Fixes are optional sections. Include only the sections that are actually warranted by the branch.- If a branch primarily introduces a new feature, fold implementation corrections and polish into that feature description rather than listing them as separate fixes.
- Use
Fixes only for fixes to behavior that already shipped before this branch.
- If UI work, API work, and server support all enable the same new workflow, describe them as one feature bullet and move the implementation details into
Technical Changes.
- Do not turn enabling infrastructure into a user-facing feature bullet unless users can directly perceive it as a separate capability.
## What's New
### ✨ Features
- [User-facing feature descriptions]
### 🐛 Fixes
- [User-visible bug fixes]
---
## Technical Changes
### 🏗️ Infrastructure
- [Build, CI, tooling changes]
### 🧹 Code Quality
- [Refactoring, cleanup, technical debt]
### 📝 Documentation
- [Doc updates, comments, README changes]
## Testing
[What was tested, test coverage changes]
Analysis Process
- Determine the branch's primary shipped outcome.
- Identify the smallest number of user-facing outcomes that fully describe the branch.
- Separate new user-facing capabilities from fixes to already-shipped behavior.
- Group changes by release meaning, not by commit wording or architecture layers.
- Collapse iterative implementation fixes into the parent feature when they were never independently released.
- Keep UI, API, and backend support together when they only exist to deliver one feature.
- Focus on user impact.
- Include technical context.
- Mention testing.
PR Preparation Hint
If you are using this skill while preparing a pull request:
- Treat the generated notes as a draft PR body, not just standalone release notes.
- Keep the strongest reviewer-facing sections near the top, especially the user-facing changes and testing.
- Trim customer-marketing language if the audience is primarily engineers reviewing the PR.
Example Output
## What's New
### ✨ Features
- Added dark mode toggle in user preferences
### 🐛 Fixes
- Fixed login redirect loop when session expires
- Resolved memory leak in file upload component
## Technical Changes
### 🏗️ Infrastructure
- Added the settings persistence and theme wiring needed to support dark mode across sessions
## Testing
- Added unit tests for theme switching
- Manual testing on Chrome, Firefox, Safari
- Verified session edge cases
Overview
Analyzes git commit history and generates customer-facing "What's New" and technical release notes from branch changes. The output also works well as a draft pull request description when preparing a PR.
