Changelog Generator Pro

The Problem

Release day arrives. You need a changelog for the v2.4.0 tag. You scroll through 47 commits, half of which are "fix typo," "WIP," and "address review comments." You spend 40 minutes manually categorizing commits into features, fixes, and breaking changes. You miss a BREAKING CHANGE buried in a refactor commit. Three customers upgrade without knowing about the breaking change and file support tickets. The changelog you publish omits two performance improvements that the marketing team needed for the blog post.

Free vs Pro

• Free turns recent commits into readable release notes in chat; Pro parses Conventional Commits across the full range and groups Features / Fixes / Breaking / Perf / Maintenance
• Free has no SemVer story; Pro recommends major / minor / patch from commit types (BREAKING → major, feat → minor, fix → patch)
• Free is one-shot prose; Pro exports Keep a Changelog, GitHub Release body, plain text, JSON for CI, and custom templates
• Free keeps noisy commits; Pro dedupes merges / CI bots and classifies severity so stakeholders can scan

Upgrade Path

Upgrade when release notes must be reproducible every tag — not rewritten by hand on release day. Free is fine for a quick summary; Pro is for shipping changelogs from git history on a schedule.

What You Get

• Conventional Commits parser that extracts type (feat/fix/docs/perf/breaking), scope, subject, and body from every commit message, automatically grouping them into Features, Bug Fixes, Breaking Changes, Performance, and Maintenance sections
• Semantic version bump recommendation — auto-detects whether the release needs a major, minor, or patch bump based on commit types (BREAKING CHANGE → major, feat → minor, fix → patch)
• Multi-format output supporting Keep a Changelog standard, GitHub Release body, plain text, JSON for CI/CD pipelines, and custom Handlebars-style templates
• Commit deduplication and noise filtering — removes merge commits, CI auto-commits, and duplicate entries; handles squash merges where individual type information is lost
• Severity classification that tags each change as Critical (breaking), High (new features), Medium (fixes/perf), or Low (docs/chores) so stakeholders can scan for impact level
• Configurable commit ranges — generate changelogs for the last N commits, between two git tags, or within a date range, with options to exclude specific commit types or scopes

Why This Beats Prompting It Yourself

When you paste raw git log output into an LLM and ask for changelog formatting, it hallucinates commit types, invents descriptions that don't match the actual changes, and produces inconsistent output across releases. Worse, it can't auto-detect version bumps or filter out merge commits reliably. This skill parses the actual commit message structure, applies deterministic categorization rules, and produces output that matches the Keep a Changelog or GitHub Release format exactly — every time.

Example Session

You: "Generate changelog for releases/v2.3.0..releases/v2.4.0 in Keep a Changelog format."

Agent output:

### Breaking Changes
- **Critical**: Removed deprecated `/v1/api` legacy endpoints — migrate to `/v2/api`

### Features
- **High**: Added OAuth2 PKCE flow support for enhanced security
- **High**: Implemented dark mode toggle with system preference detection

### Bug Fixes
- **Medium**: Resolved race condition in API rate limiter
- **Medium**: Corrected tooltip positioning on mobile viewports

### Performance
- **Medium**: Optimized N+1 query in user listing endpoint (~40% latency reduction)

### Maintenance
- Bumped express from 4.18.2 to 4.19.0

---
**Recommended version bump**: MINOR (2.3.0 → 2.4.0)
**Total commits**: 10 | Features: 2 | Fixes: 2 | Breaking: 1

Use Cases

• Release management pipelines — auto-generate changelogs after version bump, before tag creation
• Open source projects — maintain standard CHANGELOG.md files per keepachangelog.com
• CI/CD integration — output JSON changelog data for automated GitHub Releases or Slack notifications
• Migration planning — identify breaking changes across releases to plan upgrade paths for clients
• Compliance and audit trails — maintain structured changelog records for regulated environments

Known Limitations

Commits not following the Conventional Commits format are grouped under "Other Changes" with degraded categorization. Monorepo single-changelog output won't reflect per-package changes — use the --scope flag for package-specific changelogs. Squash merges may lose individual type information from the original commits.