← ClaudeAtlas

changelog-generatorlisted

Use when the user wants a CHANGELOG.md entry generated from commit history, a diff between two tags/releases, or a list of merged PRs. Triggers on phrases like "generate a changelog", "write release notes", "what changed since v1.2.0". Follows the Keep a Changelog format.
Thelavdevawasthi/claude-git-skills · ★ 0 · Code & Development · score 70
Install: claude install-skill Thelavdevawasthi/claude-git-skills
# Changelog Generator ## When to use this - The user provides commit messages, merged PR titles, or a `git log` range between two versions/tags and wants a changelog entry. - The user asks for "release notes" for a version. ## Steps 1. **Group changes into standard Keep a Changelog categories**: - `Added` — new features - `Changed` — changes to existing functionality - `Deprecated` — features being phased out - `Removed` — removed features - `Fixed` — bug fixes - `Security` — security-related fixes 2. **Rewrite each entry from the user's perspective, not the developer's.** A commit like `refactor(auth): switch to jwt validation lib` becomes, from a changelog perspective, either nothing (pure internal refactor, no user-facing effect) or `Changed: improved reliability of login session validation` if it affects behavior. If a commit has no user-facing impact, leave it out of the changelog entirely rather than forcing it into a category. 3. **Order entries within each category** with the most significant/user-relevant changes first. 4. **Use this format** (Keep a Changelog style): ```markdown ## [1.3.0] - YYYY-MM-DD ### Added - [entry] ### Changed - [entry] ### Fixed - [entry] ``` 5. **Omit empty categories entirely** — don't print a `### Removed` heading with nothing under it. 6. If commit messages are too vague to tell what user-facing effect a change had (e.g. just "fix bug"), say so and ask for clarification rather than guessing at a plausible-sou