---
name: Release Notes Drafter
slug: release-notes-drafter-2
category: Writing
description: Release Notes Drafter turns a git ref range into user-facing release notes grouped into Features, Fixes, and Breaking changes. Use it when you need a changelog entry or a summary of what shipped.
github: "https://github.com/jnMetaCode/ai-coding-guide/tree/main/codex/templates"
language: CSS
stars: 508
forks: 85
install: "npx degit https://github.com/jnMetaCode/ai-coding-guide/tree/main/codex/templates ~/.claude/skills/templates"
installs_to: ~/.claude/skills/templates
source_path: codex/templates/SKILL.md
collection_size: 1
category_size: 1012
added: 2026-08-26T05:12:44.080Z
last_synced: 2026-08-26T05:12:44.080Z
canonical_url: "https://dirskills.com/skills/release-notes-drafter-2"
---

# Release Notes Drafter

Release Notes Drafter turns a git ref range into user-facing release notes grouped into Features, Fixes, and Breaking changes. Use it when you need a changelog entry or a summary of what shipped.

**Install:**

```bash
npx degit https://github.com/jnMetaCode/ai-coding-guide/tree/main/codex/templates ~/.claude/skills/templates
```

## README

# Release Notes Drafter

Generate clear, user-facing release notes from `git log` between two refs.

## When to fire

- User mentions: "release notes", "changelog", "what shipped", "summarize this milestone"
- A git ref range or version tag is in scope (e.g. `v1.2.0..HEAD`, `last-tag..main`)

## Inputs you should gather

1. The two refs (default: `<latest tag>..HEAD` if user didn't specify)
2. Audience: end users (default), API consumers, internal team
3. Output format: markdown (default), JSON, or plain text

## Steps

1. Run `git log <from>..<to> --pretty=format:'%h%x09%s%x09%an' --no-merges`
2. For each commit, classify:
   - `feat:` / `add:` → **Features**
   - `fix:` / `bugfix:` → **Fixes**
   - `BREAKING CHANGE:` (in body) → **Breaking** (top of doc, explicit migration note)
   - everything else (`chore:`, `docs:`, `refactor:`, `test:`) → omit unless user-visible
3. For each entry, rewrite the commit message in user-facing language (no `feat(api):` prefix; no internal jargon)
4. If there's a PR number in the commit (`(#1234)`), link it
5. Group by category, sort by impact (breaking > features > fixes > minor)

## Output template

```markdown
## <version> — <date>

### ⚠️ Breaking changes
- <one-sentence summary>. **Migration:** <what to do>. ([#PR])

### ✨ Features
- <user-visible benefit>. ([#PR])

### 🐛 Fixes
- <symptom that's now fixed>. ([#PR])
```

## Gotchas

- Don't dump raw commit messages — rewrite from the *user's* perspective
- Squash-merged repos: each merge commit covers many internal commits; read the PR description for context
- Conventional Commit `chore:` and `docs:` rarely belong in user-facing notes
- If `BREAKING CHANGE:` is in the body of a `feat:`, the entry must surface as Breaking, not Feature
- For monorepos, prefix entries with the affected package name (`[@org/auth]`)

## References

- See `references/conventional-commits.md` for the full type list
- See `examples/v1.2.0.md` for a polished sample