Skip to content
Back to skills

Changelog Writer

ASecurity

Use when writing release notes, a CHANGELOG.md entry, a version summary or "what's new" text from git history, merged pull requests or tickets, or deciding the next semantic version number.

  • 3 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added October 17, 2026
ai-agentsgitapisecurity

Works with

  • cursor
  • cli
  • api

Security analysis

A100/100

Scanned October 17, 2026

npx -y skills add WST2002/claude-code-skills --skill changelog-writer --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Changelog Writer?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Changelog Writer
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/wst2002-changelog-writer/badge)](https://www.skillsdirectory.com/skills/wst2002-changelog-writer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: changelog-writer
description: Use when writing release notes, a CHANGELOG.md entry, a version summary or "what's new" text from git history, merged pull requests or tickets, or deciding the next semantic version number.
---

# Changelog Writer

## Overview

Release notes tell users what changed for them and what they must do. Build them from the real history between two versions, group by impact, and write in the reader's language, not in commit-speak.

## Method

1. **Find the range:** last release tag to now — `git describe --tags --abbrev=0`, then `git log <tag>..HEAD --oneline --no-merges`. With GitHub: `gh pr list --state merged --search "merged:>=<date>"` or `gh release view`.
2. **Read each change**, not just the subject line, when the impact is unclear (`git show <sha> --stat`).
3. **Classify** each change: Added, Changed, Deprecated, Removed, Fixed, Security (Keep a Changelog). Drop internal-only changes (refactors, CI, tests) unless the audience is developers of the project.
4. **Decide the version** (Semantic Versioning): any breaking change → major; new backward-compatible feature → minor; only fixes → patch.
5. **Rewrite for the audience:** user-facing benefit first, one line each, link the PR or issue.
6. **Write breaking changes with migration steps.**
7. **Follow the existing CHANGELOG.md style** if the project has one.

## Format

```markdown
## [2.4.0] - 2026-10-16

### Added
- Export orders to CSV from the Orders page. (#412)

### Changed
- Search now matches partial words. (#405)

### Fixed
- Coupon discount no longer disappears when the cart quantity changes. (#398)

### Security
- Upgrade `jsonwebtoken` to 9.0.2 to fix token verification bypass. (#401)

### Breaking changes
- `GET /api/orders` now returns paginated results. Read items from `data` and
  pass `cursor` to fetch the next page. (#410)
```

Dates in ISO format. Newest version at the top. Omit empty sections.

## Common mistakes

- Copying commit subjects ("fix stuff", "wip") into release notes.
- Hiding breaking changes inside "Changed" with no migration steps.
- Listing internal refactors that users do not care about.
- Choosing a minor version for a release that breaks clients.
- Mentioning features from unmerged branches.

---

Made by **Wageesha Tripathi** · [LinkedIn](https://www.linkedin.com/in/wst2002/) · [Email](mailto:tripathiwageesha2002@gmail.com) · [More skills](https://github.com/WST2002/claude-code-skills)

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.