How do I install the Changelog skill?

Run npx skillmds@latest add concertonotes/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. 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?

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?

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

Changelog by concertonotes — Agent Skill

Name: Changelog
Rating: 4.666666666666667 (3 reviews)
Author: ConcertoNotes

Changelog

Use when the user asks to manage a project's CHANGELOG.md — add an entry, derive entries from git commits, or cut a release — or runs /changelog. Follows Keep a Changelog 1.1.0 and Semantic Versioning 2.0.0. Action selected via argument: add | from-commits | release.

ConcertoNotes Updated Sep 8, 2026 0 repo stars

File contents

changelog

Manage CHANGELOG.md per Keep a Changelog 1.1.0 + SemVer 2.0.0. Three actions: add (one hand-written entry), from-commits (derive from Conventional Commits), release (cut a version).

Edits CHANGELOG.md ONLY — never version files, never git tag/git commit. release prints suggested commands.

Step 1 — Resolve the action

$ARGUMENTS contains add / from-commits (or commits) / release → that action; else infer from the request, and AskUserQuestion (add | from-commits | release) if still ambiguous.

Step 2 — Pre-flight (all actions)

root=$(git rev-parse --show-toplevel 2>/dev/null) || root=.
ls "$root/CHANGELOG.md" 2>/dev/null

All actions read/edit $root/CHANGELOG.md (repo-root, never cwd-relative).

Exists → Read it; note its style (compare-link footers? PR refs? capitalization?).
Missing + add/from-commits → write the standard Keep a Changelog 1.1.0 skeleton (title + intro linking keepachangelog.com/en/1.1.0 and semver.org/spec/v2.0.0, then ## [Unreleased]), then proceed.
Missing + release → STOP: nothing to release; suggest /changelog add or /changelog from-commits.

Step 3 — Insert under `[Unreleased]` (add, from-commits)

Via Edit, append - <imperative description> under the entry's ### <Category> within ## [Unreleased], creating the subsection in Keep a Changelog's canonical order if absent. Obey the contract in references/writing-guidelines.md (never modify released sections, never date [Unreleased]).

Step 4 — Run the action

references/writing-guidelines.md is the single source of truth for entry rules, the Conventional Commits map, and the SemVer bump table — load it for every action.

add — entry from the user's text; else AskUserQuestion for category (the six Keep a Changelog categories) + a ≤15-word description. Tighten wording per writing-guidelines, then insert (Step 3).
from-commits — see below.
release — follow references/release.md.

from-commits

The changelog, not git tags, is the source of truth for what shipped — derive entries, don't mirror the log.

Range. git tag --sort=-version:refname | head -5: ≥1 tag → <latest-tag>..HEAD. No tag but a prior ## [X.Y.Z] section → git log --grep="release.*X\.Y\.Z" -iE -1 --format=%H for the lower bound. No baseline → git rev-list --count HEAD, print N, AskUserQuestion (all N | last 30 | last 100 | other). Never silently default to all commits.
Gather. git log --oneline <range>, then git log --pretty=format:"%h %s%n%b%n---" <range> (BREAKING footers live in bodies).
Classify → filter → aggregate. Per writing-guidelines: map prefixes to categories, keep macro-only changes, collapse a 10–20-commit feature into 1–3 entries. De-duplicate against existing [Unreleased] entries.
Propose & confirm. Show entries grouped by category, plus what was skipped/aggregated (one-line reasons). Get approval, then insert per Step 3.

---name: changelogdescription: Use when the user asks to manage a project's CHANGELOG.md — add an entry, derive entries from git commits, or cut a release — or runs /changelog. Follows Keep a Changelog 1.1.0 and Semantic Versioning 2.0.0. Action selected via argument: add | from-commits | release.---# changelogManage `CHANGELOG.md` per Keep a Changelog 1.1.0 + SemVer 2.0.0. Three actions: **add** (one hand-written entry), **from-commits** (derive from Conventional Commits), **release** (cut a version).Edits `CHANGELOG.md` ONLY — never version files, never `git tag`/`git commit`. `release` prints suggested commands.## Step 1 — Resolve the action`$ARGUMENTS` contains `add` / `from-commits` (or `commits`) / `release` → that action; else infer from the request, and `AskUserQuestion` (`add | from-commits | release`) if still ambiguous.## Step 2 — Pre-flight (all actions)```bashroot=$(git rev-parse --show-toplevel 2>/dev/null) || root=.ls "$root/CHANGELOG.md" 2>/dev/null```All actions read/edit `$root/CHANGELOG.md` (repo-root, never cwd-relative).- Exists → `Read` it; note its style (compare-link footers? PR refs? capitalization?).- Missing + `add`/`from-commits` → write the standard Keep a Changelog 1.1.0 skeleton (title + intro linking keepachangelog.com/en/1.1.0 and semver.org/spec/v2.0.0, then `## [Unreleased]`), then proceed.- Missing + `release` → STOP: nothing to release; suggest `/changelog add` or `/changelog from-commits`.## Step 3 — Insert under `[Unreleased]` (add, from-commits)Via `Edit`, append `- <imperative description>` under the entry's `### <Category>` within `## [Unreleased]`, creating the subsection in Keep a Changelog's canonical order if absent. Obey the contract in `references/writing-guidelines.md` (never modify released sections, never date `[Unreleased]`).## Step 4 — Run the action`references/writing-guidelines.md` is the single source of truth for entry rules, the Conventional Commits map, and the SemVer bump table — load it for every action.- **add** — entry from the user's text; else `AskUserQuestion` for category (the six Keep a Changelog categories) + a ≤15-word description. Tighten wording per writing-guidelines, then insert (Step 3).- **from-commits** — see below.- **release** — follow `references/release.md`.### from-commitsThe changelog, not git tags, is the source of truth for what shipped — derive entries, don't mirror the log.1. **Range.** `git tag --sort=-version:refname | head -5`: ≥1 tag → `<latest-tag>..HEAD`. No tag but a prior `## [X.Y.Z]` section → `git log --grep="release.*X\.Y\.Z" -iE -1 --format=%H` for the lower bound. No baseline → `git rev-list --count HEAD`, print N, `AskUserQuestion` (`all N | last 30 | last 100 | other`). Never silently default to all commits.2. **Gather.** `git log --oneline <range>`, then `git log --pretty=format:"%h %s%n%b%n---" <range>` (BREAKING footers live in bodies).3. **Classify → filter → aggregate.** Per writing-guidelines: map prefixes to categories, keep macro-only changes, collapse a 10–20-commit feature into 1–3 entries. De-duplicate against existing `[Unreleased]` entries.4. **Propose & confirm.** Show entries grouped by category, plus what was skipped/aggregated (one-line reasons). Get approval, then insert per Step 3.

Frequently asked questions