changelog-curator takes the dump from git log --oneline or a list of merged PR titles and turns it into the kind of changelog your users actually read: grouped into Added / Changed / Fixed / Removed, written in plain English, noise dropped, sorted by what matters most.
One file. Drop in. Restart. Done.
At a glance
| Field | Value |
|---|---|
| Name | changelog-curator |
| Version | 1.0.0 |
| Files | 1 file (SKILL.md) |
| Runtime | None — pure prompting |
| Triggers on | “write a changelog from these commits”, “turn this git log into release notes”, “draft v2.3 changelog”, “what should I put in CHANGELOG.md for this PR list” |
| Does NOT trigger on | writing release blog posts (longer-form), generating commit messages from a diff |
Step 1 — Create the folder
bash
mkdir -p ~/.claude/skills/changelog-curatorWindows:
powershell
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.claude\skills\changelog-curator" | Out-NullStep 2 — Paste this file
Path: ~/.claude/skills/changelog-curator/SKILL.md
markdown
---
name: changelog-curator
description: Use this skill when the user pastes a git log, a list of commit messages, or a list of merged PR titles and asks for a changelog or release notes. Trigger on "write a changelog from these commits", "turn this git log into release notes", "draft v2.3 changelog", "what should I put in CHANGELOG.md for this PR list", or any input that's clearly a commit/PR dump (lots of "feat:", "fix:", PR numbers like "#1234", short SHAs). Do NOT use for writing long-form release blog posts, marketing announcements, or generating a commit message from a code diff.
version: 1.0.0
---
# changelog-curator
Turns commit/PR dumps into the section of CHANGELOG.md a real user will read.
## When invoked
Ask only one question if it's not in the input: **what version + date is this for?** (e.g., `v2.3.0` and `2026-04-26`). Do NOT ask about the audience or the format — assume Keep-a-Changelog style markdown.
Output ONE markdown block, this exact shape:
## [{version}] — {date}
### Added
- …
### Changed
- …
### Fixed
- …
### Removed
- …
If a category has nothing, OMIT the heading entirely (don't write "_None._" — changelogs are scanned, blank sections add noise). The skill must always output at least one of the four.
## Categorisation rules
- **Added.** New features, new endpoints, new options, new UI surfaces. Conventional commit prefix `feat:` usually maps here.
- **Changed.** Behaviour change to something that already existed. New default value, redesigned screen, faster algorithm. Prefix `refactor:`, `perf:`, or commits where the user-visible behaviour shifted.
- **Fixed.** Bug fixes. Prefix `fix:`.
- **Removed.** Deleted features, removed flags, dropped support for X. If a deprecation just LANDS in this version (warning only), it's a "Changed" — don't write "Removed" until the actual removal ships.
## Noise to drop
These do NOT belong in a user-facing changelog. Filter them out silently:
- `chore:`, `ci:`, `build:`, `test:`, `docs:` (unless docs are user-facing)
- Dependency bumps (unless they fix a CVE — then "Fixed: …")
- "Merge pull request #…" / "Merge branch …"
- Internal refactors with no user-visible effect
- Typo fixes in code comments
- Linter / formatter sweeps
## Writing rules
- **Plain English.** "Add dark mode" not "implement theme switching mechanism with CSS custom properties".
- **Imperative present tense.** "Add", "Fix", "Change" — never "Added", "Fixed".
- **One bullet per user-visible change**, even if it took six commits. Merge related commits silently.
- **Link issues/PRs in parens** at the end of the line if numbers are in the input: `Fix login race on slow networks (#1234)`.
- **No internal jargon.** "Bumped Redis client" → drop it OR rewrite as the user-visible effect ("Fix occasional connection drops").
## Sort within each section
Order bullets by **impact on the user**, descending. Roughly:
1. Breaking changes (call out with a `**BREAKING**` prefix in bold)
2. Major new features
3. Important fixes (security, data loss, common errors)
4. Minor features
5. Minor fixes
If you can't tell impact, fall back to the order in the input.
## When NOT to use
- Long-form release blog posts → different skill (long-form writing)
- Marketing announcements → different skill (product marketing)
- Generating a single commit message from a diff → different skill (commit-message)
## Output
Print only the markdown block. No preamble, no "here's your changelog:" — just the block, ready to paste into CHANGELOG.md.Step 3 — Restart Claude Code
Quit, re-open.
Step 4 — Try it
text
Write the v2.3.0 changelog (release date 2026-04-26) from these commits:
feat: dark mode support across all surfaces (#812)
fix: login race condition on slow networks (#834)
chore: bump redis to 7.2
refactor: rewrite search index for 3x speedup (#840)
feat: CSV export on the orders page (#845)
fix: cents-to-dollars rounding in receipts (#851)
docs: typo in README
ci: cache pnpm store
fix: prevent duplicate signup emails (#853)
feat: API endpoint /v2/orders.search (#857)
chore: drop support for Node 16You’ll get a clean Added / Changed / Fixed / Removed block, dependency bump and CI noise dropped, search rewrite under “Changed” (it’s a perf change to existing behaviour), Node 16 drop under “Removed” with a BREAKING tag.
Customising
- Conventional Commits emoji style. Add a line: “Prefix each bullet with the conventional commit emoji (✨ for Added, 🐛 for Fixed, …).”
- Hebrew/RTL output. Add: “Default language: Hebrew. Use right-to-left punctuation conventions.”
- GitHub Releases format. Replace the H2 heading with the GitHub release title style and add an “**Full diff:**” line at the top with a placeholder.
Related
For more drop-in skills, browse the Skill Library. For why descriptions are written this way, see Writing Skill Descriptions That Actually Trigger.