---
name: Changelog Generator
slug: changelog-generator-10
category: Writing
description: Changelog Generator turns git commit history into user-facing changelogs and release notes. Use it to summarize recent commits, prepare CHANGELOG.md, or document changes between versions.
github: "https://github.com/ECNU-ICALK/AutoSkill/tree/main/SkillBank/Common/AwesomeClaudeSkills/changelog-generator"
language: Python
stars: 564
forks: 53
install: "npx degit https://github.com/ECNU-ICALK/AutoSkill/tree/main/SkillBank/Common/AwesomeClaudeSkills/changelog-generator ~/.claude/skills/changelog-generator"
installs_to: ~/.claude/skills/changelog-generator
source_path: SkillBank/Common/AwesomeClaudeSkills/changelog-generator/SKILL.md
collection_size: 25
category_size: 1012
collection_url: "https://dirskills.com/collections/ECNU-ICALK/AutoSkill"
added: 2026-08-25T05:14:25.745Z
last_synced: 2026-08-25T05:14:25.745Z
canonical_url: "https://dirskills.com/skills/changelog-generator-10"
---

# Changelog Generator

Changelog Generator turns git commit history into user-facing changelogs and release notes. Use it to summarize recent commits, prepare CHANGELOG.md, or document changes between versions.

**Install:**

```bash
npx degit https://github.com/ECNU-ICALK/AutoSkill/tree/main/SkillBank/Common/AwesomeClaudeSkills/changelog-generator ~/.claude/skills/changelog-generator
```

## README

# 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:

```bash
# 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

```markdown
# 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

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