keeping-a-changelog

Create, validate, and release Keep a Changelog 2.0.0-compliant CHANGELOG.md and RELEASE_NOTES.md files.

Updated Mar 28, 2026
One-click install
npx skills add https://github.com/thedutchvisiongroup/agent-skills --skill keeping-a-changelog-thedutchvisiongroup
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: keeping-a-changelog
Source: https://github.com/thedutchvisiongroup/agent-skills/tree/main/skills/keeping-a-changelog
Command: npx skills add https://github.com/thedutchvisiongroup/agent-skills --skill keeping-a-changelog-thedutchvisiongroup

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Maintaining a consistent, human-readable changelog is tedious and error-prone: entries get dumped from git logs, dates drift from ISO format, releases lack structure, and user-facing release notes fall out of sync with the internal record. This Skill enforces the Keep a Changelog 2.0.0 format end to end, from drafting entries to cutting releases. ## Core Features & Use Cases - Changelog authoring and curation: Draft entries from git diffs or named changes, curate what is notable, and place one-bullet entries under the six standard change types (Added, Changed, Deprecated, Removed, Fixed, Security). - Programmatic validation and release cutting: The bundled changelog.py script validates format compliance, extracts release sections, lists versions, and cuts [Unreleased] into a dated version with updated compare links. - User-facing release notes: Write optional RELEASE_NOTES.md files in English or Dutch with enforced version/date parity against the changelog. - Migration: Migrate legacy, non-conforming changelogs to the format using audit, mapping, and reconstruction strategies. - Use Case: After merging a sprint's worth of pull requests, ask the agent to document the changes; it drafts curated entries under [Unreleased], validates the file, cuts release 2.1.0, and drafts the Dutch release notes. ## Quick Start Ask the agent to document the recent git changes in CHANGELOG.md and validate the result.

Frequently Asked Questions about keeping-a-changelog

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a Keep a Changelog compliant CHANGELOG.md?

Start with the standard skeleton: an H1, the preamble pinning Keep a Changelog 2.0.0 and your versioning scheme, and an empty [Unreleased] section. Add entries as one bullet each under the six type headings, then run changelog.py validate to confirm compliance.

How do I cut a release from an Unreleased changelog section?

Run changelog.py release CHANGELOG.md <version> with an optional --date flag. It renames [Unreleased] into the dated version, inserts a fresh empty [Unreleased], updates compare link definitions, and refuses to run if validation errors exist or the section is empty.

Can release notes be written in Dutch instead of English?

Yes, RELEASE_NOTES.md may be English or Dutch, but only one language per file. Dutch files use the type headings Nieuw, Gewijzigd, Verouderd, Verwijderd, Gefixt, and Beveiliging, while CHANGELOG.md itself must always remain English.

What is the difference between CHANGELOG.md and RELEASE_NOTES.md?

CHANGELOG.md is the complete internal record for developers and is always required. RELEASE_NOTES.md is an optional user-facing file containing a curated subset of entries in outcome-first language, released versions only, with version labels and dates matching the changelog exactly.

How do I migrate a non-conforming changelog to Keep a Changelog format?

Audit the existing file with the validator, then either record from now on with a fresh skeleton or reconstruct history from git tags. Map legacy headings to the six types, rewrite entries as single bullets, and validate until zero errors remain.

When should a project not maintain a changelog?

Skip a changelog for one-off scripts, docs-only repositories, or projects without versioned releases. Also do not copy git commit messages into the changelog, since commits and changelog entries are written for different audiences.