How do I install the Changelog Gen skill?

Run npx skillmds@latest add pandemonium-research/changelog-gen 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 Gen safe to use?

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

Which AI agents work with Changelog Gen?

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 Gen free to use?

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

Who published Changelog Gen?

Pandemonium-Research (@pandemonium-research) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Changelog Gen by pandemonium-research

Name: Changelog Gen
Author: Pandemonium-Research

Changelog Gen

Produces CHANGELOG entries from git history following the Keep a Changelog format. Uses a bundled script to extract commits since the last tag, classifies them into changelog sections using the shared commit conventions reference, and outputs a ready-to-paste release block.

File contents

Instructions

Use this skill when the user wants to generate a CHANGELOG entry for an upcoming release.

Shared reference

Load ../assets/commit-conventions.md before classifying any commits. This file defines the mapping from commit types to changelog sections:

Commit type	Changelog section
`feat`	Added
`fix`, `revert`	Fixed
`refactor`, `perf`	Changed
`docs`, `style`, `test`, `build`, `ci`, `chore`	Omit
Breaking change (`!` or `BREAKING CHANGE:` footer)	Breaking Changes (always first)

Bundled script

scripts/parse-git-log.sh extracts structured commit data since the last git tag.

Ask the user to run it in their project root and share the output:

bash path/to/changelog-gen/scripts/parse-git-log.sh

If the user cannot run the script (e.g., Windows without bash), ask them to share the output of:

git log $(git describe --tags --abbrev=0)..HEAD --pretty=format:"%H|%s|%b---END---"

Template

Load assets/changelog-template.md for the output format. Use it exactly — do not invent a different structure.

Workflow

Get the commit list (via script output or manual git log).
Get the release version number from the user (e.g., 1.4.0).
Load the commit conventions and classify each commit into its changelog section.
Omit commits with types that map to "Omit" in the table above.
Within each section, sort entries with breaking changes first, then by significance.
Deduplicate — if multiple commits address the same thing, merge into one entry.
Fill in the template with today's date and the version, then output the result.

Rules

Only include commits that map to a changelog section — never pad with chore/docs/test commits
Write entries in plain language from a user perspective, not as internal implementation notes
Breaking changes must always appear in a dedicated Breaking Changes section at the top
If the commit log is empty or only contains omitted types, tell the user and ask if they want to write a manual entry

---name: changelog-gendescription: Produces CHANGELOG entries from git history following the Keep a Changelog format. Uses a bundled script to extract commits since the last tag, classifies them into changelog sections using the shared commit conventions reference, and outputs a ready-to-paste release block.---## InstructionsUse this skill when the user wants to generate a CHANGELOG entry for an upcoming release.### Shared referenceLoad `../assets/commit-conventions.md` before classifying any commits. This file defines the mapping from commit types to changelog sections:| Commit type | Changelog section ||-------------|------------------|| `feat` | Added || `fix`, `revert` | Fixed || `refactor`, `perf` | Changed || `docs`, `style`, `test`, `build`, `ci`, `chore` | Omit || Breaking change (`!` or `BREAKING CHANGE:` footer) | Breaking Changes (always first) |### Bundled script`scripts/parse-git-log.sh` extracts structured commit data since the last git tag.Ask the user to run it in their project root and share the output:```bashbash path/to/changelog-gen/scripts/parse-git-log.sh```If the user cannot run the script (e.g., Windows without bash), ask them to share the output of:```bashgit log $(git describe --tags --abbrev=0)..HEAD --pretty=format:"%H|%s|%b---END---"```### TemplateLoad `assets/changelog-template.md` for the output format. Use it exactly — do not invent a different structure.### Workflow1. Get the commit list (via script output or manual git log).2. Get the release version number from the user (e.g., `1.4.0`).3. Load the commit conventions and classify each commit into its changelog section.4. Omit commits with types that map to "Omit" in the table above.5. Within each section, sort entries with breaking changes first, then by significance.6. Deduplicate — if multiple commits address the same thing, merge into one entry.7. Fill in the template with today's date and the version, then output the result.### Rules- Only include commits that map to a changelog section — never pad with chore/docs/test commits- Write entries in plain language from a user perspective, not as internal implementation notes- Breaking changes must always appear in a dedicated **Breaking Changes** section at the top- If the commit log is empty or only contains omitted types, tell the user and ask if they want to write a manual entry

Frequently asked questions