How do I install the Changelog skill?

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

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: executes scripts. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Changelog?

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

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

Who published Changelog?

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

Changelog by geekswamp — Agent Skill

Name: Changelog
Rating: 4.2 (5 reviews)
Author: geekswamp

Changelog

Generate and update project changelog entries from git commit history. Use this skill whenever the user mentions changelogs, release notes, summarizing commits, or preparing for a new version. Trigger it for App Store, Play Store, or web app announcement requests, even if they do not explicitly ask for a 'changelog' file. This skill is also specialized for creating friendly, bilingual release notes for non-technical users.

geekswamp Updated Sep 10, 2026

File contents

Generate Changelog

Follow this workflow in order. Do not skip step 1.

1. Generate Source Data First

Always run the gen-changelog.sh script, UNLESS the user provides the script output directly in their request.

bash scripts/gen-changelog.sh

The JSON result will be generated when you run the gen-changelog.sh script. Treat this command output (or the provided output) as the single source of truth for:

last_tag
next_version
date
categorized commit list

If the output is No changes since last release. (or no commits are found), there is no need to create or update the changelog. Report that no changelog update is needed and stop immediately without modifying any files.

2. Use the Changelog Template

Use CHANGELOG.md as the rendering template for the new release block.

Map data from JSON output:

{{version}} -> next_version without leading v
{{date}} -> date
{{#added}} -> commits with category == "added"
{{#breaking}} -> commits with category == "breaking" or breaking == true
{{#changed}} -> commits with category == "changed"
{{#fixed}} -> commits with category == "fixed"
{{#reverted}} -> commits with category == "reverted"

For each commit line:

Use - {{message}} (#{{pr}}) only when pr is not empty.
Use - {{message}} when pr is empty.

Remove empty sections so the output does not include blank category headings, and ensure each changelog entry starts with a capital letter.

3. Update CHANGELOG.md

If CHANGELOG.md does not exist, create it from the rendered template content.

If CHANGELOG.md already exists:

Keep the existing title and intro paragraph.
Insert the new release section directly below the intro, before older releases.
Preserve older release entries below the new one.

4. Verify Final Result

Before finishing, review the generated changelog to ensure the following:

The version number and release date exactly match the values returned by the script output.
Section headings appear in the correct order: Added, Breaking Changes, Changed, Fixed, Reverted.
Empty sections are completely removed so no unused category headings remain.
Each changelog entry starts with a capital letter.
Each entry is slightly improved from the original commit message to be clearer and more informative for end users.
Avoid raw or technical commit-style messages; rewrite them into short, user-friendly descriptions when necessary.
The Markdown structure is valid, clean, and easy to read.
All content is written in English.

Additional Guidelines

When release notes are requested (for example for App Store, Play Store, or announcements), generate them based on the latest version in CHANGELOG.md.
Read and follow all guidelines defined in references/release_notes.md.
Only include the most important user-facing improvements from that release.
Ensure the final release notes follow the structure, tone, and language limits specified in the reference file.

---name: changelogdescription: Generate and update project changelog entries from git commit history. Use this skill whenever the user mentions changelogs, release notes, summarizing commits, or preparing for a new version. Trigger it for App Store, Play Store, or web app announcement requests, even if they do not explicitly ask for a 'changelog' file. This skill is also specialized for creating friendly, bilingual release notes for non-technical users.---# Generate ChangelogFollow this workflow in order. Do not skip step 1.## 1. Generate Source Data FirstAlways run the [gen-changelog.sh](./scripts/gen-changelog.sh) script, UNLESS the user provides the script output directly in their request.```bashbash scripts/gen-changelog.sh```The JSON result will be generated when you run the `gen-changelog.sh` script. Treat this command output (or the provided output) as the single source of truth for:- `last_tag`- `next_version`- `date`- categorized commit listIf the output is `No changes since last release.` (or no commits are found), there is **no need to create or update the changelog**. Report that no changelog update is needed and stop immediately without modifying any files.## 2. Use the Changelog TemplateUse [CHANGELOG.md](./templates/CHANGELOG.md) as the rendering template for the new release block.Map data from JSON output:- `{{version}}` -> `next_version` without leading `v`- `{{date}}` -> `date`- `{{#added}}` -> commits with `category == "added"`- `{{#breaking}}` -> commits with `category == "breaking"` or `breaking == true`- `{{#changed}}` -> commits with `category == "changed"`- `{{#fixed}}` -> commits with `category == "fixed"`- `{{#reverted}}` -> commits with `category == "reverted"`For each commit line:- Use `- {{message}} (#{{pr}})` only when `pr` is not empty.- Use `- {{message}}` when `pr` is empty.Remove empty sections so the output does not include blank category headings, and ensure each changelog entry starts with a capital letter.## 3. Update CHANGELOG.mdIf `CHANGELOG.md` does not exist, create it from the rendered template content.If `CHANGELOG.md` already exists:- Keep the existing title and intro paragraph.- Insert the new release section directly below the intro, before older releases.- Preserve older release entries below the new one.## 4. Verify Final ResultBefore finishing, review the generated changelog to ensure the following:- The version number and release date exactly match the values returned by the script output.- Section headings appear in the correct order: **Added**, **Breaking Changes**, **Changed**, **Fixed**, **Reverted**.- Empty sections are completely removed so no unused category headings remain.- Each changelog entry starts with a capital letter.- Each entry is slightly improved from the original commit message to be clearer and more informative for end users.- Avoid raw or technical commit-style messages; rewrite them into short, user-friendly descriptions when necessary.- The Markdown structure is valid, clean, and easy to read.- All content is written in **English**.## Additional Guidelines- When release notes are requested (for example for App Store, Play Store, or announcements), generate them based on the **latest version in `CHANGELOG.md`**.- Read and follow all guidelines defined in [`references/release_notes.md`](./references/release_notes.md).- Only include the **most important user-facing improvements** from that release.- Ensure the final release notes follow the **structure, tone, and language limits** specified in the reference file.

Frequently asked questions