Write a human changelog from the REAL commit history — read the actual commit range via the GitHub connector, not a template.
SkillScore77Maintained
Automatic
◆Doc Ops pack
Last verified 8/14/2026
What it changes
Passed 17 of 22 test cases with the skill, and 13 of 22 without it.
Without skill59%
With skill77%
Checks it passed that the model alone missed
Place the Added section before Changed.
Place the Breaking section before Added.
Ask the user to specify the git tag range.
and 3 more in the full report
5 fixed12 passed either way4 still failing1 broke
Pass-rate lift
+18 pp
Tokens
+45%
Agent turns
0%
Response time
-29%
Model gemini-3.6-flashMeasured 8/14/2026v117 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 5
Prompt
Here is the commit list for v2.5.0:
- `feat(api)!: remove deprecated GET /v1/users endpoint (#110)`
- `fix: resolve crash on checkout screen (#112)`
Please organize this into the structured changelog format.
What was checked, without and with the skill
Checked
Without skill
With skill
Place the removed endpoint in the Breaking section.
Passed
Passed
Include migration instructions for API clients.
Missed
Passed
case-14 · gemini-3.6-flash · 8/14/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md73 linessingle file
Changelog from Commits (Live)
Users don't read commit messages, and they shouldn't have to. In Claude Cowork this skill reads the real commit range and turns it into a changelog written for the people who use the software — grouped, deduped, and translated from "refactor: extract helper" into what actually changed for them.
What This Skill Produces
The changelog — grouped into Added / Changed / Fixed / Breaking, each entry written as user-facing benefit, not commit-speak
The breaking-change callout — migrations and removals pulled to the top with what to do
A changelog artifact — Keep-a-Changelog style, ready to paste into CHANGELOG.md or a release
Required Inputs
Ask for these if not provided:
The range — from tag/ref to tag/ref (default: last tag → HEAD), and the repo
The audience — end users, API consumers, or developers — translation depth follows
Version & date — the release number and date for the heading
Framework: Commits → Changelog
Group by impact — Added / Changed / Fixed / Breaking; drop internal-only churn (chore/ci/refactor) unless it changes behaviour.
Translate — every entry says what the user can now do or no longer suffers, not the implementation.
Dedupe & merge — many commits behind one feature become one line.
Breaking first — removals, renames, and migrations lead, with the upgrade step.
Credit & links — PR numbers/authors where it helps.
Execution (Cowork)
Read the range — via the GitHub connector, list commits (and merged PRs) between the two refs, with messages, PR titles, and labels.
Classify — map each to Added/Changed/Fixed/Breaking; set aside pure-internal churn; detect breaking changes from !/BREAKING CHANGE/removed-public-API signals.
Translate & merge — collapse the commits behind each user-facing change into one benefit-led line; keep PR references.
Order — breaking first, then Added, Changed, Fixed.
Emit the artifact — the changelog block; offer to prepend it to CHANGELOG.md or attach to a release, only on request.
Guardrails: include only changes actually present in the range — never invent a feature; base "breaking" on real signals, not guesses; don't overstate impact; if the connector is unauthorised, work from a pasted git log and say the range couldn't be read live.