How do I install the Changelog From Commits skill?

Run npx skillmds add mohitagw15856/changelog-from-commits in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Changelog From Commits safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Changelog From Commits?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Changelog From Commits free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Changelog From Commits?

Mohit Aggarwal (@mohitagw15856) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Changelog From Commits by mohitagw15856

Name: Changelog From Commits
Rating: 4.2 (5 reviews)
Author: Mohit Aggarwal

Changelog From Commits

Write a human changelog from the REAL commit history — read the actual commit range via the GitHub connector, not a template. Use when asked to write the changelog for this release, what changed since the last tag, draft release notes from my commits, or summarise this range for users in Cowork. Reads commits/PRs between two refs via the GitHub connector, groups them into user-facing changes (features / fixes / breaking), translates commit-speak into human benefit, and produces a changelog artifact ready for the release.

File contents

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.

Output Format

A Changelog block:

## [version] — date

### ⚠ Breaking
- what changed → what to do (#PR)

### Added
- user-facing capability (#PR)

### Changed
- what's different now (#PR)

### Fixed
- the problem that's gone (#PR)

Quality Checks

Every entry maps to a real commit/PR in the range
Entries read as user benefit, not commit messages
Breaking changes lead and include the migration step
Internal-only churn was excluded (unless it changed behaviour)
Multiple commits behind one feature are a single line

Anti-Patterns

Pasting raw commit messages as the changelog.
Inventing a feature not in the range to round it out.
Burying a breaking change in the middle of "Changed".
Listing every chore:/refactor: that users never see.

Example Trigger Phrases

"Write the changelog since the last tag in Cowork."
"Draft release notes from my commits for v2.0."
"What changed for users between v1.4 and HEAD?"
"Summarise this commit range as a human changelog."

---name: changelog-from-commitsdescription: Write a human changelog from the REAL commit history — read the actual commit range via the GitHub connector, not a template. Use when asked to write the changelog for this release, what changed since the last tag, draft release notes from my commits, or summarise this range for users in Cowork. Reads commits/PRs between two refs via the GitHub connector, groups them into user-facing changes (features / fixes / breaking), translates commit-speak into human benefit, and produces a changelog artifact ready for the release.--- # 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 1. **Group by impact** — Added / Changed / Fixed / Breaking; drop internal-only churn (chore/ci/refactor) unless it changes behaviour. 2. **Translate** — every entry says what the *user* can now do or no longer suffers, not the implementation. 3. **Dedupe & merge** — many commits behind one feature become one line. 4. **Breaking first** — removals, renames, and migrations lead, with the upgrade step. 5. **Credit & links** — PR numbers/authors where it helps. ## Execution (Cowork) 1. **Read the range** — via the GitHub connector, list commits (and merged PRs) between the two refs, with messages, PR titles, and labels. 2. **Classify** — map each to Added/Changed/Fixed/Breaking; set aside pure-internal churn; detect breaking changes from `!`/`BREAKING CHANGE`/removed-public-API signals. 3. **Translate & merge** — collapse the commits behind each user-facing change into one benefit-led line; keep PR references. 4. **Order** — breaking first, then Added, Changed, Fixed. 5. **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. ## Output Format A **Changelog** block: ``` ## [version] — date ### ⚠ Breaking - what changed → what to do (#PR) ### Added - user-facing capability (#PR) ### Changed - what's different now (#PR) ### Fixed - the problem that's gone (#PR) ``` ## Quality Checks - [ ] Every entry maps to a real commit/PR in the range - [ ] Entries read as user benefit, not commit messages - [ ] Breaking changes lead and include the migration step - [ ] Internal-only churn was excluded (unless it changed behaviour) - [ ] Multiple commits behind one feature are a single line ## Anti-Patterns - **Pasting raw commit messages** as the changelog. - **Inventing a feature** not in the range to round it out. - **Burying a breaking change** in the middle of "Changed". - **Listing every `chore:`/`refactor:`** that users never see. ## Example Trigger Phrases - "Write the changelog since the last tag in Cowork." - "Draft release notes from my commits for v2.0." - "What changed for users between v1.4 and HEAD?" - "Summarise this commit range as a human changelog."

Frequently asked questions