Help us improve
Share bugs, ideas, or general feedback.
From changelog
Creates CHANGELOG.md from scratch by analyzing full git commit history into tag-based or date-grouped sections with Added/Changed/Fixed categories.
npx claudepluginhub florianbuetow/claude-code --plugin changelogHow this skill is triggered — by the user, by Claude, or both
Slash command
/changelog:createThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create a new `CHANGELOG.md` from scratch by analyzing the full git history. 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.
Generates or updates CHANGELOG.md from git history in Keep-a-Changelog format using parallel haiku subagents per version range.
Analyzes git commit history to generate changelogs with semantic versioning, conventional commit categorization, and formats like Keep a Changelog, Conventional, or GitHub. Use for CHANGELOG.md updates, release notes, and version bumps.
Share bugs, ideas, or general feedback.
Create a new CHANGELOG.md from scratch by analyzing the full git history. Follows Keep a Changelog with Semantic Versioning.
Run these commands in parallel:
git tag --sort=-version:refname # All tags, newest first
git log --oneline --date=short --format="%h %ad %s" # Full commit history
git remote get-url origin 2>/dev/null # Remote URL for version links
Determine:
v1.2.0, 1.0.0), use them as version boundaries to create one section per tagged release. Commits after the latest tag go under [Unreleased].Always produce date-based sections. Never dump all commits into a single flat [Unreleased] list.
Use tags as primary version boundaries. Within each tagged version, order entries chronologically. Commits after the latest tag go under [Unreleased].
Group commits by date into meaningful sections. Use the commit dates to find natural boundaries:
## Week of 2026-03-24).## 2026-03).## YYYY-MM-DD (for the start date of each group) rather than invented version numbers.[Unreleased].The goal is 4–12 sections that each tell a coherent story. Adjust granularity to hit that range. A single flat list is never acceptable.
For each section (tag-based or date-based), 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 the full template and formatting rules.
Build the file with:
# Changelog header and standard intro paragraph referencing Keep a Changelog and SemVer## [Unreleased] section (just the heading, no empty sub-headings)## [X.Y.Z] – YYYY-MM-DD## YYYY-MM-DD (start date of the group)Use ISO date format (YYYY-MM-DD). Detect the remote URL for version links from git remote get-url origin.
Show the full generated changelog content inline.
**BREAKING:**, describe impact, provide migration path.../changelog/references/format-guide.md — Complete format spec, template, style rules, antipatterns, breaking change handling