Changelog Automation

/changelog-automation

Automate changelog generation, release notes, and version management following industry standards. The user pastes a git log, list of merged PRs, or their release config; deliver formatted changelog entries, release notes, and automation configs as chat artifacts. For end-user product documentation, use technical-documentation.

When to Use

• Setting up automated changelog generation
• Implementing Conventional Commits
• Creating release note workflows
• Standardizing commit message formats
• Generating GitHub/GitLab release notes
• Managing semantic versioning

Keep a Changelog Format

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

## [2.1.0] - 2024-01-15

### Added
- Dark mode support with automatic preference sync

### Changed
- Checkout flow is 40% faster

### Fixed
- Race condition in payment processing

### Security
- Updated lodash to patch prototype pollution vulnerability

Categories: Added, Changed, Deprecated, Removed, Fixed, Security.

Conventional Commits

# Feature with scope
feat(auth): add OAuth2 support for Google login

# Bug fix with issue reference
fix(checkout): resolve race condition in payment processing

Closes #123

# Breaking change
feat(api)!: change user endpoint response format

BREAKING CHANGE: The user endpoint now returns `userId` instead of `id`.
Migration guide: Update all API consumers to use the new field name.

# Multiple paragraphs
fix(database): handle connection timeouts gracefully

Previously, connection timeouts would cause the entire request to fail
without retry. This change implements exponential backoff with up to
3 retries before failing.

Fixes #456
Reviewed-by: @alice

Type-to-semver mapping: feat = minor, fix = patch, ! or BREAKING CHANGE: footer = major. Other types (docs, chore, refactor, test, ci) do not bump by default.

Release Notes Structure

When generating release notes from a pasted log or PR list, produce:

## Summary

One or two sentences on the headline changes of this release.

## Highlights

### Dark Mode
Users can now switch to dark mode from settings. The preference is
automatically saved and synced across devices.

### Performance
- Checkout flow is 40% faster
- Reduced bundle size by 15%

## Breaking Changes

None in this release. (Or: list each with a migration step.)

## Upgrade Guide

No special steps required. Standard deployment process applies.

## Known Issues

- Dark mode may flicker on initial load (fix scheduled for v2.1.1)

## Dependencies Updated

| Package | From    | To      | Reason                   |
| ------- | ------- | ------- | ------------------------ |
| react   | 18.2.0  | 18.3.0  | Performance improvements |
| lodash  | 4.17.20 | 4.17.21 | Security patch           |

Workflow

1. Ask the user for the raw material: git log --oneline v1.2.0..HEAD, merged PR titles, or their existing CHANGELOG.md.
2. Classify each change (feature, fix, breaking, security, internal); drop noise commits (merges, formatting).
3. Determine the semver bump from the classified changes.
4. Deliver the changelog entry and/or release notes as a markdown artifact, plus automation config (semantic-release, release-please, commitlint) if they want it generated on every release.

Best Practices

Do's

• Follow Conventional Commits -- enables automation
• Reference issues -- link commits to tickets
• Use scopes consistently -- define team conventions
• Automate releases -- reduce manual errors

Don'ts

• Don't mix changes -- one logical change per commit
• Don't skip validation -- use commitlint in CI
• Don't hand-edit generated changelogs -- fix the commits or the config
• Don't forget breaking changes -- mark with ! or footer

Detailed Patterns and Worked Examples

Tooling configs (semantic-release, release-please, git-cliff, commitlint/husky) and CI wiring live in references/details.md. Read that file when you need the concrete templates.

Usage

/changelog-automation $ARGUMENTS