Changelog generator

Skill ECNU-ICALK/AutoSkill/SkillBank/Common/AwesomeClaudeSkills/changelog-generator

AutoSkill: Experience-Driven Lifelong Learning via Skill Self-Evolution

Install

npx -y skills add ECNU-ICALK/AutoSkill --skill changelog-generator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

What its author says it does

Copied from the file, not written here

Generates user-facing changelogs and release notes from git commit history. Parses conventional commits, categorizes changes into features, fixes, breaking changes, and more, then rewrites technical messages into customer-friendly language. Use when the user asks to generate a changelog, write release notes, summarize recent commits, prepare CHANGELOG.md, or document what changed between versions.

SKILL.md

2.7 KB, as published. Nobody here has run it

Changelog Generator

Generate structured, user-facing changelogs from git commit history.

Workflow

Step 1 — Gather commits

Determine the commit range from the user's request, then fetch commits:

# Between tags/versions
git log v1.2.0..v1.3.0 --oneline --no-merges
# Since a date
git log --since="2024-03-01" --oneline --no-merges
# Since last tag (default when no range given)
git log "$(git describe --tags --abbrev=0)"..HEAD --oneline --no-merges

If there are no tags and no range specified, ask the user for a date or count.

Step 2 — Categorize each commit

Apply these rules based on the commit message prefix:

Prefix / pattern	Category
`feat:` `feature:`	New Features
`fix:` `bugfix:`	Bug Fixes
`perf:`	Performance
`BREAKING CHANGE` or `!:` suffix	Breaking Changes
`security:` `vuln:`	Security
`docs:` `test:` `ci:` `chore:` `refactor:` `style:` `build:`	Skip (internal)

For non-conventional messages, infer category from content. Exclude purely internal commits (test infra, CI config, linting, dependency bumps with no user impact).

Step 3 — Rewrite for a non-technical audience

Transform each kept commit into a clear, benefit-focused sentence:

Strip scope tags like (api): or (auth):
Expand abbreviations and jargon
Lead with the user-visible outcome, not the implementation
Use present tense: "Add", "Fix", "Improve"
One sentence per entry

Example: fix(auth): race condition in token refresh becomes "Fix an issue where sessions could expire unexpectedly during use."

Step 4 — Format the output

# Changelog — vX.Y.Z (YYYY-MM-DD)

## Breaking Changes
- [entry]

## New Features
- [entry]

## Improvements
- [entry]

## Bug Fixes
- [entry]

## Security
- [entry]

Omit any empty section. Order: breaking changes, features, improvements, fixes, security. If the repo already has a CHANGELOG.md or CHANGELOG_STYLE.md, match its existing conventions instead.

Step 5 — Validate before presenting

Confirm no internal-only commits leaked through
Confirm every entry is understandable without reading source code
Confirm date and version label are correct
Write to CHANGELOG.md (prepend above existing content) or print inline, based on the user's request