How do I install the Changelog skill?

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

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

Changelog by rokurokulab — Agent Skill

Name: Changelog
Author: rokurokulab

Changelog

Add a CHANGELOG.md entry in Keep-a-Changelog style for unreleased work, or generate the next version's entries from git log since the last tag. Use when preparing a release, updating CHANGELOG after merging features, or when the user asks "what's in the next release?"

rokurokulab Updated Sep 17, 2026

File contents

changelog

Keep CHANGELOG.md honest and human-readable, in Keep a Changelog format with SemVer versioning.

When to invoke

User says "update the changelog", "add to CHANGELOG", "generate release notes"
User is preparing a release (tagging, version bump)
After merging a feature/fix, if the project keeps CHANGELOG in lockstep with merges (check the recent commit pattern to confirm)

What to do

Read existing CHANGELOG.md to learn the project's category vocabulary, ordering, and link style. Match it.
Determine scope of update:
- "Add to unreleased": the user just merged something; append to the [Unreleased] section.
- "Cut a release": user is bumping version; rename [Unreleased] to [X.Y.Z] - YYYY-MM-DD, add a fresh empty [Unreleased], update version-comparison links at the bottom.
Categorize entries under the standard headings (skip empty ones):
- Added — new features
- Changed — non-breaking changes to existing behavior
- Deprecated — soon-to-be-removed features
- Removed — features removed in this release
- Fixed — bug fixes
- Security — vulnerability fixes
Source the entries from git log <last-tag>..HEAD --oneline (Conventional Commits map cleanly: feat: → Added, fix: → Fixed, refactor: / perf: → Changed, etc.). Skip noise (chore:, ci:, docs: unless user-facing).
Phrase entries from the user's perspective, not the developer's. "Added retry on flaky upstream calls" — not "Implemented exponential backoff in HTTPClient.do_request".
One bullet per change, reference PR/issue if available: - Added retry on 5xx upstream errors. (#123).

Output format

Print the diff to apply (or the new section, if appending). Don't reformat unrelated parts of the file.

If you're cutting a release, include the version-link footer update:

[Unreleased]: https://github.com/owner/repo/compare/v1.2.0...HEAD
[1.2.0]: https://github.com/owner/repo/compare/v1.1.0...v1.2.0

If the user has git-cliff configured, mention that running git-cliff may be the better path and just generate the section it would produce as a preview.

---name: changelogdescription: Add a CHANGELOG.md entry in Keep-a-Changelog style for unreleased work, or generate the next version's entries from git log since the last tag. Use when preparing a release, updating CHANGELOG after merging features, or when the user asks "what's in the next release?"---# changelogKeep `CHANGELOG.md` honest and human-readable, in [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) format with [SemVer](https://semver.org/) versioning.## When to invoke- User says "update the changelog", "add to CHANGELOG", "generate release notes"- User is preparing a release (tagging, version bump)- After merging a feature/fix, if the project keeps CHANGELOG in lockstep with merges (check the recent commit pattern to confirm)## What to do1. **Read existing `CHANGELOG.md`** to learn the project's category vocabulary, ordering, and link style. Match it.2. **Determine scope of update**: - "Add to unreleased": the user just merged something; append to the `[Unreleased]` section. - "Cut a release": user is bumping version; rename `[Unreleased]` to `[X.Y.Z] - YYYY-MM-DD`, add a fresh empty `[Unreleased]`, update version-comparison links at the bottom.3. **Categorize entries** under the standard headings (skip empty ones): - **Added** — new features - **Changed** — non-breaking changes to existing behavior - **Deprecated** — soon-to-be-removed features - **Removed** — features removed in this release - **Fixed** — bug fixes - **Security** — vulnerability fixes4. **Source the entries** from `git log <last-tag>..HEAD --oneline` (Conventional Commits map cleanly: `feat:` → Added, `fix:` → Fixed, `refactor:` / `perf:` → Changed, etc.). Skip noise (`chore:`, `ci:`, `docs:` unless user-facing).5. **Phrase entries from the user's perspective**, not the developer's. "Added retry on flaky upstream calls" — not "Implemented exponential backoff in HTTPClient.do_request".6. **One bullet per change**, reference PR/issue if available: `- Added retry on 5xx upstream errors. (#123)`.## Output formatPrint the diff to apply (or the new section, if appending). Don't reformat unrelated parts of the file.If you're cutting a release, include the version-link footer update:```markdown[Unreleased]: https://github.com/owner/repo/compare/v1.2.0...HEAD[1.2.0]: https://github.com/owner/repo/compare/v1.1.0...v1.2.0```If the user has [git-cliff](https://git-cliff.org) configured, mention that running `git-cliff` may be the better path and just generate the section it would produce as a preview.

Frequently asked questions