git-release-notes-generation

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

1. Determine the branch's primary shipped outcome.
2. Identify the smallest number of user-facing outcomes that fully describe the branch.
3. Separate new user-facing capabilities from fixes to already-shipped behavior.
4. Group changes by release meaning, not by commit wording or architecture layers.
5. Collapse iterative implementation fixes into the parent feature when they were never independently released.
6. Keep UI, API, and backend support together when they only exist to deliver one feature.
7. Focus on user impact.
8. Include technical context.
9. 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.