Slash Command

/changelog

Parses git history since last release tag, categorizes commits by type, generates Keep a Changelog markdown with next version suggestion, and offers to prepend to CHANGELOG.md.

Git

documentation

From smart-commit

Install

Run in your terminal

npx claudepluginhub rohitg00/awesome-claude-code-toolkit --plugin smart-commit

Command Content

Other plugins with /changelog

/changelog

Generate structured changelog from recent git commits, grouped by date and categorized by type (features, fixes, etc.) in markdown format.

deep-wiki

1.9k

/changelog

git/

Generates changelog from git history since last tag or specified ref, grouping conventional commits (feat, fix, etc.) by type with breaking changes and version bump suggestion in Keep a Changelog Markdown.

claude-code-toolkit

1.0k

/changelog

Generates structured changelog from ADVPL/TLPP code changes by analyzing git diffs since a commit/date, classifying by type (NEW, FIX, etc.), and grouping entries. Supports --since, --format, --output, --group-by.

ReadGlobGrep+3

advpl-specialist

/changelog

Analyzes git commits since last release, categorizes by type (Added, Fixed, etc.), generates user-friendly CHANGELOG.md entries in Keep a Changelog format, and updates file after confirmation.

universal-dev-standards

/changelog

cc/

Generates and appends versioned entries to CHANGELOG.md from Git commits and staged changes, auto-classifying into Added/Changed/Fixed/etc. per Keep a Changelog. Uses <version> or today's date.

ReadWriteEdit+1

code-pilot

/changelog

Generates engaging changelogs for recent PR merges to main branch, highlighting breaking changes, features, bug fixes, improvements, and contributor shoutouts. Optional: daily|weekly|days.

compound-engineering

Stats

Parent Repo Stars1013

Parent Repo Forks275

Last CommitFeb 4, 2026

Actions

View Source View Plugin View on GitHub View README

/smart-commit:changelog

Parse the git history since the last release tag and generate a structured markdown changelog.

Process

Identify the latest release tag by running git tag --sort=-v:refname | head -20.
- Look for semver-formatted tags (v1.2.3, 1.2.3, etc.)
- If no tags exist, use the initial commit as the starting point

Retrieve all commits since the last tag:

git log <last-tag>..HEAD --pretty=format:"%H|%s|%an|%ad" --date=short

Parse each commit message and categorize by conventional commit type:
- Added - feat commits introducing new functionality
- Fixed - fix commits correcting bugs or errors
- Changed - refactor, perf, style commits modifying existing behavior
- Deprecated - commits mentioning deprecation in subject or body
- Removed - commits removing features, files, or dead code
- Security - commits addressing vulnerabilities or security concerns
- Documentation - docs commits
- Internal - chore, ci, test, build commits
For each commit entry, format as:
- Concise description derived from the commit subject
- Scope in parentheses if present
- Shortened commit hash as a reference
Suggest the next version number based on changes:
- MAJOR bump if any BREAKING CHANGE footers are present
- MINOR bump if any feat commits are present
- PATCH bump if only fix, refactor, perf, docs, chore commits
Generate the changelog in Keep a Changelog format.

Output Format

## [X.Y.Z] - YYYY-MM-DD

### Added
- Description of new feature (scope) [`abc1234`]

### Fixed
- Description of bug fix (scope) [`def5678`]

### Changed
- Description of modification (scope) [`ghi9012`]

### Internal
- Description of internal change [`jkl3456`]

Rules

Group entries by category, not chronologically
Omit empty categories entirely
Keep descriptions user-facing: translate technical commits into impact statements
If a commit message is unclear, read the diff with git show <hash> --stat for context
Merge commits and revert-of-reverts should be excluded
Present the changelog for review before writing to CHANGELOG.md
Prepend to existing CHANGELOG.md if one exists, do not overwrite history

Process

Identify the latest release tag by running git tag --sort=-v:refname | head -20.

Look for semver-formatted tags (v1.2.3, 1.2.3, etc.)
If no tags exist, use the initial commit as the starting point

Retrieve all commits since the last tag:

git log <last-tag>..HEAD --pretty=format:"%H|%s|%an|%ad" --date=short

Parse each commit message and categorize by conventional commit type:

Added - feat commits introducing new functionality
Fixed - fix commits correcting bugs or errors
Changed - refactor, perf, style commits modifying existing behavior
Deprecated - commits mentioning deprecation in subject or body
Removed - commits removing features, files, or dead code
Security - commits addressing vulnerabilities or security concerns
Documentation - docs commits
Internal - chore, ci, test, build commits

For each commit entry, format as:

Concise description derived from the commit subject
Scope in parentheses if present
Shortened commit hash as a reference

Suggest the next version number based on changes:

MAJOR bump if any BREAKING CHANGE footers are present
MINOR bump if any feat commits are present
PATCH bump if only fix, refactor, perf, docs, chore commits

Generate the changelog in Keep a Changelog format.

## [X.Y.Z] - YYYY-MM-DD ### Added - Description of new feature (scope) [`abc1234`] ### Fixed - Description of bug fix (scope) [`def5678`] ### Changed - Description of modification (scope) [`ghi9012`] ### Internal - Description of internal change [`jkl3456`]

Rules

Group entries by category, not chronologically

Omit empty categories entirely

Keep descriptions user-facing: translate technical commits into impact statements

If a commit message is unclear, read the diff with git show <hash> --stat for context

Merge commits and revert-of-reverts should be excluded

Present the changelog for review before writing to CHANGELOG.md

Prepend to existing CHANGELOG.md if one exists, do not overwrite history