Changelog Generator

# Changelog Generator

Convert git history into user-facing release notes. Bridge the gap between
"fix(auth): null check on session" and "Fixed an issue where login could fail
intermittently."

## Keywords
changelog, release notes, release, version, semver, semantic versioning,
conventional commits, git log, commit message, CHANGELOG.md, keep a changelog,
fix, feat, breaking change, what's new, release announcement

## Core Truth

Engineers write commits for engineers. Users don't care about "refactored token
parser." They care about: "What changed for me?" The job is translation.

Three audiences read changelogs:
1. **Users** — want to know what to expect
2. **Customers' developers** — want breaking change warnings
3. **Internal team** — want context for support

A good changelog serves all three with different sections.

---

## 1. When To Use

- Preparing a release
- Generating CHANGELOG.md for a repo
- Writing customer release notes
- Producing in-app "What's new" content
- Auditing what shipped in the last quarter

## 2. The Categories

Use Keep-a-Changelog categories or a variant:

| Category | What goes here |
|----------|----------------|
| **Added** | New features, new endpoints, new options |
| **Changed** | Behavior changes that aren't bugs |
| **Deprecated** | Features still working but going away |
| **Removed** | Features deleted |
| **Fixed** | Bug fixes |
| **Security** | Vulnerability patches |
| **Breaking** | Anything that requires user action |

## 3. Translation Patterns

| Commit | Public version |
|--------|----------------|
| `fix: null check on session` | Fixed intermittent login failures |
| `feat: add webhook retry` | Webhooks now retry automatically on failure |
| `refactor: extract email service` | (Don't include — internal change) |
| `chore: bump dependencies` | (Don't include — unless security) |
| `perf: cache db query` | Faster page load times for large datasets |
| `BREAKING: rename auth header` | **Breaking:** The `X-Auth` header is now `X-Authorization` |

## 4. Filtering Rules

Skip these commit types in user-facing changelogs:
- chore (dep bumps, lint fixes)
- refactor (internal code changes)
- test (test-only changes)
- docs (unless user-facing docs)
- style (formatting)
- ci (build pipeline)

Include these always:
- feat
- fix
- perf
- security
- BREAKING CHANGE markers

## 5. Versioning Heuristic

Even without strict semver:
- **Major** — breaking changes, removed features
- **Minor** — new features, backwards compatible
- **Patch** — bug fixes only

If commits are unconventional, infer from the changes:
- Any breaking change → major
- Any new feature → minor
- Only fixes → patch

## 6. Output Format

### CHANGELOG.md (Keep-a-Changelog style)