release-notes

# Release Notes

## Overview
This skill generates structured release notes by analyzing git history. It determines the version range from git tags, categorizes commits by type, identifies contributors, and produces a comprehensive `RELEASE_NOTES.md`. A brief interview confirms version number, highlights, and breaking changes before final output.

## Instructions

### Phase 1: Discovery & Analysis
1. Determine the version range to document:
   - Run `git tag --sort=-version:refname` to find existing tags.
   - If tags exist, use the range from the most recent tag to HEAD.
   - If no tags exist, use `AskUserQuestion` to ask the user for the range (e.g., a specific commit SHA, "last 20 commits", or "all history").
   - The user may also specify a custom range as an argument (e.g., `/release-notes v1.0.0..v1.1.0`).

2. Collect commit history for the determined range:
   - Run `git log <range> --pretty=format:"%H|%an|%ae|%s|%b" --no-merges` to get commit details.
   - Run `git log <range> --pretty=format:"%H|%an|%ae|%s|%b" --merges` to identify PR merges.
   - Run `git shortlog -sne <range>` to gather contributor information.

3. Categorize each commit based on its message prefix or content:
   - **Features**: Messages starting with `feat`, `add`, `new`, or containing "added", "implement"
   - **Bug Fixes**: Messages starting with `fix`, `bugfix`, or containing "fixed", "resolve"
   - **Breaking Changes**: Messages containing `BREAKING CHANGE`, `BREAKING:`, or using `!` after type (e.g., `feat!:`)
   - **Improvements**: Messages starting with `refactor`, `improve`, `update`, `perf`, `enhance`
   - **Documentation**: Messages starting with `docs`, `doc`
   - **Other**: Messages starting with `chore`, `ci`, `build`, `test`, `style`, or anything else

4. For each category, extract a clean one-line summary from the commit message subject line. Strip conventional commit prefixes (e.g., `feat: add login` becomes `Add login`).

5. Identify potential highlights by looking for: