AutoChangelog

What it is

AutoChangelog is a CLI tool that initializes, validates, appends structured entries to, and cuts versioned releases from CHANGELOG.md files. It is built for release pipelines and CI environments where changelog correctness is a first-class requirement, not an optional check.

It is not a changelog generator. It does not infer or generate entry text from git history or commit messages. Every operation is explicit: every entry is authored directly, every release date is supplied by the caller.

Why it exists

Most release processes treat the changelog as an afterthought. Files are edited manually, inconsistently, and rarely validated. The result is a history that cannot be trusted: malformed versions, missing entries, sequences that regress, sections that corrupt downstream tooling.

AutoChangelog exists because the changelog is part of the product. It deserves the same discipline as the code it documents. A malformed changelog is a broken release artifact, not a cosmetic issue.

What it enforces

• Format compliance Validates Keep a Changelog structure throughout the file. Sections, headings, and link formats are checked for correctness on every run.
• Version heading syntax Version headings must follow the prescribed format. Ambiguous or informally-styled version entries are rejected.
• Release sequencing Versions must be in correct descending order. No regressions, no duplicates, no gaps that corrupt downstream parsing.
• Unreleased section When present, the [Unreleased] block must appear before any versioned release. Structural placement is validated on every run. Promotion to a versioned block is handled by the release command.
• CI exit codes Exit codes are precise and consistent. Validation failure, format error, and missing file each produce distinct codes designed for scripted environments without manual inspection.

In practice

A complete release cycle using AutoChangelog:

# 1. Initialize a changelog
autochangelog init

# 2. Record what changed
autochangelog add --section Added --message "Initial release"

# 3. Cut the release (version and date are always explicit)
autochangelog release --version 1.0.0 --date 2026-04-14

# 4. Validate (also runs as a CI gate before every release)
autochangelog validate CHANGELOG.md

Try it now in your browser →  ·  View the real AutoChangelog CHANGELOG.md →

The validate command runs as a gate before any release operation is permitted to proceed. Exit codes are distinct and scriptable:

• 0 Changelog is valid and correctly structured
• 1 Validation failed — output identifies the specific violation
• 2 Parse error — file has structural errors that prevent validation
• 3 File not found or unreadable
• 4 Usage error — invalid option or missing required argument
• 5 Internal error

Output is plain text on stdout, structured for logging and scripted pipelines. No interactive prompts, no configuration files required for basic validation.

Full command reference →

Who it is for

AutoChangelog is for teams where the changelog is a release artifact, not a developer courtesy. The tool is not appropriate for projects where changelog discipline is optional or informal.

• Teams shipping versioned software where a corrupt changelog represents a real release defect, not a cosmetic problem
• Release pipelines that consume CHANGELOG.md as a structured input for release notes, diffs, or downstream systems
• Projects that need exact version sequencing enforced consistently across contributors and environments
• Developers who want changelog correctness to be automatic and non-negotiable, not reviewed by hand before each release