A free Claude Code skill for writing changelog entries

Claude Code doesn’t ship a skill for writing changelogs. Its bundled skills, listed in the Claude Code commands reference, don’t include one, and neither Anthropic’s skills repository nor its official plugin marketplace lists one (checked September 18 and 19, 2026). So the changelog skills people install are community files. The one below is 47 lines: it reads your commits, turns them into the few changes a user would notice, and lists the commits behind every entry so you can check the draft before it goes out. What it gives you is a draft; publishing it is a separate step, covered at the end of the next section.

The worked example further down is a real change to Moonjar, the Mac app I’m building, which publishes this blog and is in early access. The skill doesn’t need Moonjar; only the optional picture step mentions it.

If you’re after Claude Code’s own release notes, you don’t need a skill: Claude Code’s /release-notes command shows them. Skills with names like claude-code-changelog, such as xupeng’s claude-code-changelog, fetch and explain those same notes, not yours.

---
name: changelog-entry
description: >-
  Drafts user-facing changelog entries from git commits since
  a tag, commit or date. Use when asked for a changelog entry,
  release notes or what shipped.
argument-hint: "[last release tag, commit, date or range]"
allowed-tools: Bash(git log *) Bash(git show *) Bash(git describe *)
---

Write for the people who use the product, not the people
who wrote the code. Run git from this repository, one
command per call. Do not add -C, shell wrappers or
command substitution; use the three git commands below.

1. Range: read from the last release to HEAD. The user
   may name it (a tag or commit), give a date (from that
   day on) or a range (A..B, used as given). If they give
   HEAD's own tag, or nothing, the last release is
   `git describe --tags --abbrev=0 'HEAD^'`. If that
   finds no earlier tag, ask for a date or start commit
   and stop. Don't infer a range from the oldest commit.
2. Read the commits:
       git log --no-merges --date=short \
         --format='%h %ad %s%n%b' RANGE
   Open an unclear one with `git show --stat HASH`.
3. Sort: one entry per change a user would notice. Group
   the commits behind it. Leave out refactors, tests, CI
   and dependency bumps unless users feel them.
4. Voice: if CHANGELOG_STYLE.md exists, follow it; if not,
   match the three newest entries in CHANGELOG.md. If
   neither exists: a title that says what people can do
   now, then one to three plain sentences in the present
   tense, with the app's exact UI labels.
5. Truth: every sentence traces to a commit. Never add
   numbers, speedups or reasons the commits don't state.
   Put anything you're unsure of under Questions.
6. Picture (optional): if the change is visible and
   Moonjar's MCP tools are connected, search its library
   for a capture of that screen and style it with
   create_design, pointing at what changed. Ask before
   capturing anything new. Without Moonjar, name the
   screen worth capturing.

Reply with the entries in Markdown, then Sources (the
hashes behind each entry), Left out (hash and reason) and
Questions. Don't write to any file unless asked.

Save it as ~/.claude/skills/changelog-entry/SKILL.md to have it in every project, or as .claude/skills/changelog-entry/SKILL.md inside a repository and commit it so everyone working there gets it. Those are the personal and project locations in Claude Code’s skills documentation, and the folder name becomes the command.

Then type /changelog-entry followed by the tag of your last release, such as /changelog-entry v2.2.0, or a commit, a date or a range such as v2.2.0..v2.3.0. Or ask Claude for the changelog entry for this release and let the description match. If you’ve already tagged the new release, that works too: it reads from the tag before it. Whatever you type after the command still reaches Claude: the docs say that when a skill has no $ARGUMENTS placeholder, Claude Code appends what you typed to the end of the skill as ARGUMENTS:. The argument-hint line shows what to type as you start the command.

You need Claude Code to run it. Its setup docs say Claude Code needs a Pro, Max, Team, Enterprise or Console account, and the free claude.ai plan doesn’t include it; Claude’s pricing page listed Pro at $20 a month billed monthly on September 19, 2026.

It reads commit messages, not pull requests or tickets, so a draft is only as good as your commits. The example below comes from commits with long, descriptive bodies. With one-line commits, expect thinner entries and more under Questions. If your team explains the why in pull requests, paste the release’s pull request descriptions into the chat too.

What comes back is a draft for a person to finish. To turn it into a note users read (a headline in their words, where to find the change, one picture), use the template in how to write release notes. To publish it, paste the entries, not the Sources, Left out and Questions lists, into your changelog: a Framer CMS changelog takes Markdown as is, and the best changelog tools compares hosted pages and widgets.

Why it’s written this way

• It finds the last release, even after you’ve tagged this one. Run on your latest commit, git describe returns a tag that sits on that commit, which would leave nothing to read. Step 1 asks about the commit before it (HEAD^, quoted so zsh doesn’t read it as a pattern), so it works whether or not you’ve tagged the release yet.

• It asks where to start instead of guessing. With no tags, git describe fails: in our own Moonjar repository, which has none, git describe --tags --abbrev=0 exited with code 128 when run on September 18, 2026. That’s also why the skill runs git as ordinary steps rather than through Claude Code’s dynamic context injection (the ! syntax that runs a command before the skill loads): the docs say a failed injected command aborts the whole invocation, so a skill built on that line wouldn’t load at all in a repository without tags.

• One entry per change, not per commit. Keep a Changelog says an entry should “document the noteworthy difference, often across multiple commits”. Step 3 does that grouping and drops what users never feel.

• It asks for nothing that writes. allowed-tools names only the three read-only git commands the skill uses. Claude Code already runs read-only git commands without asking, per its permissions docs, so the line records the skill’s footprint rather than widening it. Everything else still goes through your permission settings. Compare changelog-creator further down, which pre-approves Write and Edit.

• Every sentence needs a commit. The reply ends with the hashes behind each entry, what was left out and why, and any open questions, so checking the draft means checking a short list instead of rereading the log.

• It writes nothing. You paste the entry where it belongs, or ask for it to be written to a file.

Check it after you install it

On September 19, 2026, we installed the exact skill above in four scratch repositories and ran these checks with Claude Code 2.1.277, using Opus 5 at max effort. All six invocations passed: a tag, a date, the no-tag question and its follow-up, and both ways of asking about an already-tagged release. Each draft cited the intended change and excluded the baseline commit. None needed a permission approval or changed a tracked file. These are small range tests, so repeat them in your repository before relying on a draft:

1. From a tag. In a repository you know, type /changelog-entry followed by the tag of an earlier release, such as /changelog-entry v2.2.0. It should read the commits without asking permission and reply with entries, Sources, Left out and Questions. Check that every hash under Sources appears in git log v2.2.0..HEAD.

2. From a date. Type /changelog-entry since 2026-09-01. The entries should cover only commits from that date on; compare the hashes with git log --since=2026-09-01.

3. With no tag at all. In a repository without tags, type /changelog-entry on its own. It should say there’s no tag and ask where to start, not pick a starting point for you. Answer with a commit or a date; it should read the requested range and reply. The simple read-only git commands ran without approval in our default-permission tests. An earlier version sometimes built compound commands that needed approval, which is why the skill now asks for one command per call. If you get a prompt, check the exact command and your permission settings.

4. On a release you’ve already tagged. Make a scratch repository with two tagged commits using the commands below, start Claude Code in it, and type /changelog-entry on its own, then /changelog-entry v0.2.0. Both should draft one entry from the second commit, not report that nothing changed since v0.2.0. The folder is new, so use the personal install in ~/.claude/skills, or copy the skill into this repository’s .claude/skills/changelog-entry/ folder first.

git init changelog-check && cd changelog-check
git commit --allow-empty -m "Add dark mode"
git tag v0.1.0
git commit --allow-empty -m "Fix a crash when exporting a PDF"
git tag v0.2.0

If a check fails, the fix is usually in the step it tests: step 1 for the range, step 5 for a sentence you can’t trace.

Make it sound like your changelog

Step 4 follows a CHANGELOG_STYLE.md if the repository has one, and otherwise matches the three newest entries in CHANGELOG.md. If your changelog lives somewhere else, such as a CMS or a help center, put your rules and a few past entries in a CHANGELOG_STYLE.md (Composio’s skill, further down, suggests the same file name), or change step 4 to name the file you keep them in. nextest’s skill, further down, shows how far a single project can take that.

To see what these steps produce on a real repository, an AI coding agent (Claude, running in Claude Code) followed them by hand on September 18, 2026 against Moonjar’s own repository, in the session that drafted this page. The skill wasn’t installed for this. The agent ran the same git commands and applied the same rules. To word and check two details, the list of small things and what at does, it also read one commit’s full diff and the current source files, which the skill’s steps don’t ask for.

The input was the two pull requests that added Moonjar’s glass loupe: 15 commits and the two merges, from September 16 and 17, 2026. The repository has no tags, so step 1 had nothing to find, and the start point was given instead: the commit just before the loupe work began (7c6a738). It has no CHANGELOG.md or CHANGELOG_STYLE.md either, so step 4 used its default voice. This is the draft:

New: point at small things with a glass loupe. When the thing a screenshot is about is too small to lift, such as a badge, a back chevron or a window’s traffic lights, Moonjar can show it enlarged under a round glass lens, with a refracting rim and a soft shadow. Agents ask for it with the highlight style magnify in create_design, update_design or a cut’s add_highlight; zoom runs from 1 to 6, and at moves the lens onto empty space so the original stays in view. The lens can hang past the edge of the device, and on a recording it stays in step with the screen while the preview plays and doesn’t change when you pause.

Fixed: recordings with a transparent background stay transparent. A VP8 or VP9 WebM with an alpha channel turned opaque when paused and lost its transparency in renders. It now keeps it in paused frames, renders and thumbnails.

The entry above is the original September 18 draft. For the illustration below, revised September 22, the loupe uses its default position directly over the time total. Use at only for an intentionally detached callout whose connection to the original is clear.

Ellie’s demo task list, with the loupe centered over the time total beside Add a task. Captured September 16, 2026; styled with Moonjar September 17; loupe position revised September 22. Photo by The Metropolitan Museum of Art on Unsplash.

Under the entries, the reply listed what step 5 asks for:

• Sources. Loupe: 0fe523e, eedf4e1, 23ab772, 9202c6e, 6358545, 6ace6f2, 1ae899a, b141112, d6cdf3c and c988091. Transparency: 0439274, c988091 and 753630f.

• Left out. d6d8f3f and 8490804, which change the units named in tool replies and history summaries and remove two temporary scripts, and 6f535f5, a test script. None of them changes what gets made.

• Questions. The repository has no release tags, so which version or date should these go under?

Twelve of the fifteen commits went into the two entries and three were left out. Nine of the ten behind the loupe entry came after the commit that introduced it, within the same two days, and most of those are about how the lens behaves in the live preview. For someone reading the changelog they’re part of the new feature, not fixes to an old one, so they sit inside the loupe entry. The transparency fix is its own entry because it changes how recordings that already existed behave.

In Moonjar, an agent asks for the loupe through tool calls, not a button, so step 4’s “exact UI labels” came out as tool and parameter names here. For an app people tap through, the same step would use the button and screen names instead.

Where the picture came from

Step 6 runs only when Moonjar’s MCP tools are connected, and in this session they were. A search of Moonjar’s library for “loupe” returned 14 styled screenshots that already use one, made on September 17 and 18 from demo data of the apps I build. The original example used an existing screenshot from Ellie, my planner app. On September 22, 2026, we revised its illustration so the loupe sits directly over the time total; the original capture and the quoted draft are unchanged. Had there been none, the step would have styled an existing capture of the screen with create_design, pointing the loupe at what changed, and it asks before capturing anything new.

Moonjar is a Mac app that Claude Code, Codex or another MCP client drives to take screenshots of the iOS Simulator, Mac windows and web pages, style them like the image above, and record the Simulator and Mac windows. It’s in early access. Without it, the skill names the screen worth capturing and you take that screenshot yourself. If you want the picture step to work in your repository, request early access.

Checked September 18, 2026, from each skill’s own SKILL.md, README and repository. None of them was installed or run for this page. If you’d rather not use a skill at all, AI changelog generators compares hosted tools that draft from commits, pull requests or tickets.

changelog-generator (Composio)

Composio’s changelog-generator SKILL.md was the first result in a US web search for “changelog skill claude” on September 18, 2026, in a repository with about 75,000 stars. It describes the job: scan the history, sort changes into features, improvements, fixes, breaking changes and security, rewrite them in customer language and skip refactors and tests. It also lists prompts to try and shows a sample weekly update.

The catch: it gives Claude no commands, no rule for choosing the range when you don’t give one and no rule against adding detail, so the method is whatever Claude decides that day. Its own sample output includes a sync speed figure that nothing in the sample ties to a commit.

changelog (Claude Directory)

Claude Directory’s changelog page holds a skill you copy by hand into .claude/skills/changelog/SKILL.md, from the claudedirectory repository. It sorts commits into Keep a Changelog’s six sections, reads Conventional Commit prefixes, looks at the diff for other commits, and takes a version or a range after /changelog.

The catch: the text has no frontmatter, so Claude Code uses its first non-empty line, a heading, as the description (per the skills docs). That gives Claude little to go on when deciding whether to load it on its own, so run it by name. Its sections are Keep a Changelog’s change types, Deprecated and Removed among them, which suit a developer-facing CHANGELOG.md more than a product update.

git-weekly-changelog (plugin)

A plugin that was listed in Anthropic’s community marketplace when its catalog was checked on September 18, 2026; the plugin docs describe that marketplace as third-party plugins that passed Anthropic’s automated validation and safety screening, each pinned to a specific commit. Add the marketplace with /plugin marketplace add anthropics/claude-plugins-community, install with /plugin install git-weekly-changelog@claude-community, and run /git-weekly-changelog:git-weekly-changelog, optionally followed by a range such as “last 2 weeks” (its README). It defaults to the last seven days, uses read-only git log and git diff, groups changes into themed sections, and requires every bullet to trace to a commit, diff or changed file. It writes in the language you ask in, Korean included.

The catch: its README offers it for team updates, release notes and sprint reviews, and its output reads like the first of those. The output template has sections for refactoring and documentation, its list of labels adds tests and CI, and every draft ends with a summary paragraph. For a public changelog you’d cut those; for a weekly update to your team, it fits better than the skill above.

prepare-changelog (nextest)

nextest keeps its changelog rules as a project skill, with a name and a description on top. Screenshot of github.com, captured September 18, 2026 and framed with Moonjar. Background photo by Bernd Dittrich on Unsplash.

The Rust test runner nextest keeps its changelog rules as a project skill at .claude/skills/prepare-changelog/SKILL.md, last changed January 4, 2026. It’s 277 lines of house style: section order, what to include and leave out, present tense, links to docs and pull requests, a thank-you for first-time contributors, and the git commands for finding what changed since the last release.

The catch: it’s written for nextest throughout, so it’s a model rather than something to install. It’s also a good public example of what step 4 of the skill above picks up from a CHANGELOG_STYLE.md: one project’s rules, written down once, so every draft starts from them.

changelog-creator (Tons of Skills)

Tons of Skills’ changelog-creator SKILL.md is one of the 2,900 skills that the README of Jeremy Longshore’s Tons of Skills marketplace counts. The repository used to be called claude-code-plugins-plus-skills, the name Claude Directory’s listing still uses.

The catch: its instructions are four general lines about step-by-step guidance and best practices. They never mention commits, a range or an entry format, so Claude supplies all of that itself. Its description lists the bare word “changelog” among the phrases that should trigger it. Its allowed-tools line also lists Read, Write, Edit and Grep, and the skills docs say listed tools run without asking during the turn that invokes the skill, so while it runs, Claude can change files without a prompt.

How this page was made. Both images were made with Moonjar, our product: the loupe picture uses Ellie’s demo data captured September 16, 2026 and styled September 17, over a photo by The Metropolitan Museum of Art on Unsplash. Its loupe position was revised September 22; the cover uses the same capture and centered loupe in a wider layout. The nextest page was captured from github.com on September 18, 2026 over a photo by Bernd Dittrich on Unsplash. The example entries were drafted by an AI coding agent on September 18, 2026 from Moonjar’s git history, following the skill’s steps by hand. The skill’s git commands were run against the same repository that day and its frontmatter was parsed as YAML. On September 19, the exact 47-line skill printed above was installed and invoked in four isolated synthetic repositories, with six successful invocations in Claude Code 2.1.277 (Opus 5, max effort). Those tests checked the tag and date ranges, the no-tag question and follow-up, and the two already-tagged release cases; they did not recreate the hand-followed Moonjar example or test the optional image step. Claude Code’s docs were rechecked on September 19. The five community skills were read from their own files and weren’t installed. This page was drafted with AI assistance.