Help us improve
Share bugs, ideas, or general feedback.
From changelog
Updates existing CHANGELOG.md by appending new version sections from git commits since last documented version, classifying into Added, Changed, Fixed, etc. per Keep a Changelog.
npx claudepluginhub florianbuetow/claude-code --plugin changelogHow this skill is triggered — by the user, by Claude, or both
Slash command
/changelog:updateThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Update an existing `CHANGELOG.md` with new entries by analyzing commits since the last documented version. Follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) with [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
Generates a formatted CHANGELOG.md from git commit history, grouped by type and ready for release.
Writes or updates a CHANGELOG following Keep a Changelog format. Translates commits into user-facing entries, highlights breaking changes, and links versions.
Generates or updates CHANGELOG.md from git history in Keep-a-Changelog format using parallel haiku subagents per version range.
Share bugs, ideas, or general feedback.
Update an existing CHANGELOG.md with new entries by analyzing commits since the last documented version. Follows Keep a Changelog with Semantic Versioning.
Read CHANGELOG.md from the project root (case-insensitive: also check changelog.md, Changelog.md).
Parse to determine:
## [X.Y.Z] heading.[Unreleased] section? — Note its position and any existing bullets.The boundary commit is the last commit already documented in the changelog. Everything after it is new.
Strategy (try in order until one succeeds):
1.2.0) has a corresponding git tag (v1.2.0 or 1.2.0), use that tag as the boundary: git log <tag>..HEAD.## [1.2.0] – 2026-03-15) and find commits after that date: git log --after="2026-03-15".If none of these strategies produce a clear boundary, inform the user and ask which commit to start from.
Run these commands in parallel:
git tag --sort=-version:refname # All tags, newest first
git log --oneline --date=short --format="%h %ad %s" <boundary>..HEAD # Commits since boundary
git remote get-url origin 2>/dev/null # Remote URL for version links
Determine:
[Unreleased].For each new version range, classify commits into six categories:
| Category | Signals |
|---|---|
| Added | feat:, "add", "new", "introduce", "implement" |
| Changed | refactor:, "update", "change", "rename", "migrate", "improve" |
| Deprecated | deprecate:, "sunset" |
| Removed | remove:, "drop", "delete", "strip" |
| Fixed | fix:, "bug", "patch", "resolve", "correct" |
| Security | security:, "CVE", "vulnerability" |
Skip merge commits — Merge commits (e.g., "Merge branch ...", "Merge pull request ...") duplicate the merged commits.
Omit commits that are purely internal (CI/CD, docs-only, trivial chores) unless user-facing.
Prefix priority — When a conventional commit prefix is present (e.g., feat:, fix:), use it to determine the category. Only fall back to keyword matching when no recognized prefix exists.
Synthesize, do not copy — Group related commits into single user-facing bullet points. Write short, specific, past-tense descriptions focused on what the user sees or feels.
Consult ../changelog/references/format-guide.md for formatting rules.
Insertion rules:
## [Unreleased] (or below the header/intro if no Unreleased section exists)[Unreleased] bullets and add a fresh empty [Unreleased] section above the new version[Unreleased] section, merging with any existing bullets thereUse ISO date format (YYYY-MM-DD). Only include category headings that have entries.
Show only the new section(s) that were added, not the entire file.
**BREAKING:**, describe impact, provide migration path.../changelog/references/format-guide.md — Complete format spec, template, style rules, antipatterns, breaking change handling