Write changelog

Skill SID-SURANGE/cursor-team-ops/skills/core/write-changelog

Enforcement & release-hygiene layer for Cursor agents — blocking git/DB/license guardrails, commit hygiene, and docs-ops.

Install

npx -y skills add SID-SURANGE/cursor-team-ops --skill write-changelog

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Generate a CHANGELOG.md entry from recent commits or a PR range, following Keep-a-Changelog format. Triggered by "update changelog", "add changelog entry", "write-changelog", "what changed since last release".

SKILL.md

3.2 KB, as published. Nobody here has run it

📋 Skill: write-changelog

Purpose

Keep CHANGELOG.md honest and current. Teams universally let changelogs rot — this skill drafts the entry from commit history so the human only needs to review and confirm, not write from scratch.

Trigger phrases

"update changelog"
"add changelog entry"
"write-changelog"
"what changed since last release"
"generate a changelog entry"
"write the changelog for this release"

Steps

1. Determine the range

# What version are we releasing?
cat VERSION   # or package.json version, pyproject.toml, etc.

# Commits since the last tag
git log $(git describe --tags --abbrev=0)..HEAD --oneline

# If no tags exist
git log --oneline -30

Ask the user for the new version number if it is not clear from a VERSION file.

2. Categorise commits

Map each commit to a Keep-a-Changelog section:

Commit type	Section
`feat:`	Added
`fix:`	Fixed
`refactor:`, `perf:`	Changed
`docs:`	Changed (if user-visible) or skip
Removal of a feature	Removed
`BREAKING CHANGE:` in body	Changed with a ⚠️ Breaking prefix
`chore:`, `style:`, `test:`, `ci:`	Skip — internal, not user-facing

Omit commits that are invisible to users (tooling, CI, test-only changes).

3. Draft the entry

## [VERSION] — YYYY-MM-DD

### Added
- Short description of new capability. (#PR or commit ref)

### Changed
- Short description of changed behaviour. (#PR or commit ref)

### Fixed
- Short description of bug fixed. (#PR or commit ref)

### Removed
- Short description of removed feature. (#PR or commit ref)

Rules:

Each bullet describes the user-visible effect, not the implementation detail.
Use past tense: "Added", "Fixed", "Removed" — not "Adds", "Fixes".
Include a PR or commit reference in parentheses when available.
Omit empty sections entirely.
Date format: ISO 8601 (YYYY-MM-DD).

4. Read the existing CHANGELOG.md

head -40 CHANGELOG.md

Confirm the existing format and insert the new entry at the top, below the # Changelog heading and above the previous release.

5. Present and confirm

Show the drafted entry in a code block. Say: "Ready to prepend this to CHANGELOG.md?" Do not write the file until the user confirms.

6. Write on confirmation

Prepend the entry to CHANGELOG.md. Do not touch any other section.

Output

A single Keep-a-Changelog section, ready to prepend to CHANGELOG.md.

Notes

If CHANGELOG.md does not exist, create it with the standard header first:

# Changelog

All notable changes to this project will be documented in this file.
The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).

If commits don't follow Conventional Commits, infer categories from the diff or ask the user to classify ambiguous entries.
Never include [Unreleased] sections — write the version and date directly.

Gives 1 of the 12 instructions most readme changelog skills give

Counted across 471 of the 478 authors here whose files we hold, read 2026-08-06

follow the Keep a Changelog formatin 31 of 471, across 26 files
omit empty sectionshere, and in 21 of 471
Run from the git repository rootin 20 of 471, across 7 files
save output directly to CHANGELOG.mdin 20 of 471, across 7 files
Group commits into logical categoriesin 19 of 471, across 6 files
Review the generated changelog before publishingin 19 of 471, across 6 files
Apply changelog guidelines and brand voicein 18 of 471, across 5 files
Exclude internal commits like refactoring and testsin 18 of 471, across 5 files
Specify date ranges for focused changelogsin 17 of 471, across 4 files
Convert technical commits into customer languagein 17 of 471, across 4 files
group commits by conventional commit typein 14 of 471
insert new entry below unreleased sectionin 14 of 471

Said here and by no other author read

omit commits that are invisible to users
describe the user-visible effect for each bullet
insert the new entry at the top
show the drafted entry before writing

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.