---
name: Changelog
slug: changelog-2
category: Writing
description: Changelog turns a range of commits or merged PRs into a changelog entry grouped by change type. Use it when asked for release notes, a changelog, or what changed between two points.
github: "https://github.com/omnigent-ai/omnigent/tree/main/examples/scribe/skills/changelog"
language: Python
stars: 8855
forks: 1336
install: "npx degit https://github.com/omnigent-ai/omnigent/tree/main/examples/scribe/skills/changelog ~/.claude/skills/changelog"
installs_to: ~/.claude/skills/changelog
source_path: examples/scribe/skills/changelog/SKILL.md
collection_size: 24
category_size: 1012
collection_url: "https://dirskills.com/collections/omnigent-ai/omnigent"
added: 2026-08-15T06:50:44.969Z
last_synced: 2026-08-15T06:50:44.969Z
canonical_url: "https://dirskills.com/skills/changelog-2"
---

# Changelog

Changelog turns a range of commits or merged PRs into a changelog entry grouped by change type. Use it when asked for release notes, a changelog, or what changed between two points.

**Install:**

```bash
npx degit https://github.com/omnigent-ai/omnigent/tree/main/examples/scribe/skills/changelog ~/.claude/skills/changelog
```

## README

# changelog — write a changelog from a commit/PR range

Turn a range of history into a clear changelog entry that a user can read to
decide whether and how to upgrade.

## Gather the range

Establish the range first. Honor an explicit one ("since v1.2.0", "the last 10
commits", "PRs merged this week"); otherwise default to commits since the most
recent tag (`git describe --tags --abbrev=0` then `git log <tag>..HEAD`).

Collect the raw material yourself with `sys_os_shell`:
- `git log <range> --no-merges --pretty=format:'%h %s'` for the commit subjects.
- `git log <range> --merges` or `gh pr list --search "merged:>=<date>"` for PRs.
- `git diff <range> --stat` to see the surface area, and `gh pr view <n>` for a
  PR's intent when a subject line is terse.

When a subject is unclear about user impact, dispatch the researcher
(`purpose: explore`) to read the diff and report what actually changed for
users — do not guess from the subject alone.

## Group by change type

Use the Keep a Changelog categories, dropping any that are empty:

    ## <version or range> — <YYYY-MM-DD>

    ### Added
    ### Changed
    ### Deprecated
    ### Removed
    ### Fixed
    ### Security

## Write each entry

- One line per user-visible change, in the imperative or past tense, describing
  the effect on the user — not the internal mechanics.
- Lead with the change, link the PR or commit in parentheses at the end.
- Omit pure-internal churn (refactors, test-only changes, CI) unless it changes
  behavior. A changelog is for users, not a commit dump.
- Call out breaking changes explicitly and point to the migration-guide skill
  if upgrade steps are needed.

## Verify

Before finalizing, route the draft through the `reviewer` (`purpose: review`)
when the changelog will ship — version numbers, "removed"/"breaking" claims, and
flag names are exactly what a fact-check catches.