Changelog Generator is a skill that reads git commit history between versions or tags and rewrites developer-facing commit messages as user-facing release notes. A commit like “fix(auth): handle null token in refresh flow” is rewritten as “Fixed an issue where users were unexpectedly logged out when their session expired.” The skill categorizes each entry into one of four types — new features, improvements, bug fixes, and breaking changes — and filters out internal or noise commits that are not relevant to end users. It groups related commits together, suggests an appropriate semantic version bump based on the nature of the changes, and can match the format of an existing CHANGELOG.md file if one is present in the repository. Output tone is configurable: professional, friendly, or technical, depending on the audience for the release notes. The skill works with any git history but produces its most structured output when commits follow conventional commit conventions (feat, fix, refactor prefixes). Without conventional commits, categorization is less precise. There are no environment variables required and no package installation steps documented in the available facts.

Use cases

Generate a CHANGELOG entry when cutting a new release from a set of git commits

Rewrite cryptic internal commit messages into user-readable bug-fix and feature descriptions

Automatically suggest whether a release warrants a major, minor, or patch version bump

Match the tone and format of an existing CHANGELOG.md when adding new entries

Filter internal refactoring and chore commits out of public-facing release notes

Produce release notes in professional, friendly, or technical tone for different audiences

When to use it

Preparing a public or internal release and need user-facing notes from raw git history

Repository uses conventional commits and wants structured changelog output automatically

Maintaining a CHANGELOG.md and want new entries to match the existing format

Unsure which semver version number to assign to the next release

When not to use it

Repositories with no git history or non-git version control systems

Commit messages do not follow any convention and precise categorization is critical

Need to pull release notes from issue trackers or pull request descriptions rather than git commits

Require a packaged CLI or CI pipeline integration — no package or transport details are provided in the facts