Generate Professional Changelogs from Git History

Changelog Generator analyzes a repository's Git history and release documentation to produce a changelog for developers and users. It locates existing changelog and version files, reviews commits and release branches, detects versions and tag dates, and groups significant changes into categories such as Added, Changed, Deprecated, Removed, Fixed, and Security.

The workflow parses conventional commit messages, identifies breaking changes and deprecations, and filters merge commits, version bumps, and trivial changes. It follows semantic versioning, handles prerelease versions such as alpha, beta, and release candidates, and orders entries with the newest first. For example, feat: entries map to Added, fix: to Fixed, and docs: to Documentation updates. Technical commit messages are rewritten as user-focused descriptions, with migration guidance for breaking changes and references to relevant issues, pull requests, or documentation.

Use it when preparing a release changelog from repository history, organizing changes across version ranges, or checking whether notable changes are clearly described. It is useful for release management workflows that need consistent categorization and reverse chronological ordering.

If repository history is inaccessible, request repository access or manual version information. Review generated entries for completeness, accuracy, and correct categorization before release. Include CVE numbers for security fixes when available.

Inputs include Git commit history, tags and timestamps, release branches, existing changelog files, package or version files, and project documentation. Repository inspection can use Read, Bash, Glob, Grep, and WebSearch. Commit conventions help identify feature, fix, documentation, and breaking changes. Output follows the Keep a Changelog structure, with an Unreleased section and versioned sections containing categorized entries.

A changelog begins with:

# Changelog

The result should capture all significant user-visible changes, explain migration steps for breaking changes, and retain relevant issue or pull request references. The workflow also provides a rationale for categorization decisions. Validation checks completeness across version ranges and applies consistent formatting. Release dates come from tag timestamps, and entries are grouped by detected version ranges.

The process uses Git history and tags, repository files, conventional commit patterns, package or version files, and release documentation. It references Keep a Changelog and semantic versioning conventions.

Maintainers and release managers can use it to prepare consistent release notes. Developers can use the resulting history to understand changes between versions, while end users benefit from descriptions focused on visible behavior and migration needs.