From alemtuzlak-skills
Generates human-friendly changelogs from git history between ref ranges, tags, or PRs. Follows Keep a Changelog format, polishes commit messages, and optionally creates GitHub Releases.
npx claudepluginhub alemtuzlak/skills --plugin alemtuzlak-skillsThis skill uses the workspace's default tool permissions.
Auto-generate human-friendly changelogs from git history. Follows Keep a Changelog format, polishes commit messages into user-friendly language, and optionally creates GitHub Releases.
Generates structured changelogs and release notes from git history and PRs, classifying breaking changes, features, fixes, performance, docs using conventional commits.
Generates user-friendly changelogs from git commit history by scanning, categorizing (features, fixes, etc.), filtering noise, and rephrasing technical details for customers.
Generates formatted CHANGELOG.md from git commit history by categorizing conventional commits into Added, Fixed, Changed, and Breaking sections using Keep a Changelog format.
Share bugs, ideas, or general feedback.
Auto-generate human-friendly changelogs from git history. Follows Keep a Changelog format, polishes commit messages into user-friendly language, and optionally creates GitHub Releases.
The primary input is a git ref range. Resolve the argument (if provided):
... or .. -> git ref range (e.g. v1.0.0...v1.1.0)#\d+ pattern -> PR (extract changes from that PR only). For single PR input: read the PR diff and description, categorize changes, use the PR title as the entry. Skip the version header. Ask the user if they want to append these entries to an existing changelog version or create a new one.digraph changelog {
rankdir=TB;
"Resolve input" [shape=box];
"Phase 1: Gather" [shape=box];
"Phase 2: Categorize" [shape=box];
"Phase 3: Polish" [shape=box];
"Phase 4: Review" [shape=box];
"Approved?" [shape=diamond];
"Phase 5: Output" [shape=box];
"Resolve input" -> "Phase 1: Gather";
"Phase 1: Gather" -> "Phase 2: Categorize";
"Phase 2: Categorize" -> "Phase 3: Polish";
"Phase 3: Polish" -> "Phase 4: Review";
"Phase 4: Review" -> "Approved?";
"Approved?" -> "Phase 3: Polish" [label="revisions"];
"Approved?" -> "Phase 5: Output" [label="yes"];
}
Do NOT skip phases. Ask questions at a natural pace. If the user answers multiple at once, accept bundled answers and skip ahead.
If the user says "just pick defaults" or similar, pick reasonable defaults, state what you chose, and ask for a single confirmation.
Run git log between the two refs to collect all commits. If the repo uses PRs, also check for merged PRs in the range using gh pr list --state merged.
For each commit/PR, extract:
Read if they exist: README, package.json (or equivalent). Goal: understand what the product is to write user-friendly descriptions.
If nothing found, ask: "Can you briefly describe the product? I need context to write user-friendly changelog entries."
Check if the repo has an existing CHANGELOG.md. If it does:
If no existing changelog:
Sort all changes into Keep a Changelog categories. Breaking Changes get a dedicated section at the top:
feat!:, fix!:, BREAKING CHANGE: footers, or removed/renamed APIs in the diff.Categorization rules:
feat:, fix:, etc.), use the type to categorizePresent the categorized list:
"Here's what I found in this range:"
Added (3)
- Feature A
- Feature B
- Feature C
Fixed (2)
- Bug fix A
- Bug fix B
"Anything to add, remove, or recategorize?"
Do NOT proceed until the user confirms.
Rewrite each entry into human-friendly language:
(#123))Format: ## [version] - YYYY-MM-DD
If the upper bound of the range is a version tag (e.g. v1.2.0), use that as the version. If the upper bound is HEAD or a branch name, ask: "What version number should this changelog use?"
Use the date of the most recent commit in the range, in ISO format (YYYY-MM-DD).
After generating the user-friendly changelog, ask:
"Want me to also generate a technical appendix with implementation details? (useful for developer-facing docs)"
If yes, generate a more detailed section with technical specifics, breaking change migration guides, and API changes.
Present the complete changelog entry:
"Here's the changelog:"
## [1.2.0] - 2026-04-11 ### Added - You can now export reports to PDF (#123) ### Fixed - Dashboard no longer flickers on page load (#456)"Want any changes?"
Wait for approval. Only proceed to output once the user confirms.
Detect existing CHANGELOG.md in the repo root. If found, read the entire file, identify the insertion point (before the first ## [ line), present the proposed insertion point to the user, and confirm before writing. If not found, create one with a standard header:
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/).
Always confirm before writing:
"I'll prepend this to
CHANGELOG.md. Good to go?"
After saving the changelog, ask:
"Want me to also create a GitHub Release with this changelog?"
If yes, use gh release create <tag> --notes "<changelog content>" to create the release. If gh is not available, inform the user and skip.
gh not available -> inform user, skip PR enrichment and GitHub Release, rely on git log only/blog-post or /newsletter)