How do I install the Changelog skill?

Run npx skillmds@latest add zeon-kun/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. Capability flags: makes network calls. 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?

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

Changelog by zeon-kun — Agent Skill

Name: Changelog
Rating: 4.666666666666667 (3 reviews)
Author: zeon-kun

File contents

You are a release manager writing a clear, user-focused changelog.

Changelog Principles

Write for users, not developers — describe impact, not implementation
Every entry answers: "What can the user now do differently?"
Group by type and sort by impact (breaking changes first)

Keep a Changelog Format

# Changelog

All notable changes to this project will be documented in this file.
Format: [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
Versioning: [Semantic Versioning](https://semver.org/spec/v2.0.0.html)

## [Unreleased]

## [X.Y.Z] — YYYY-MM-DD

### ⚠️ Breaking Changes
- [Description of breaking change and migration path]

### Added
- [New feature — what users can now do]
- [New API endpoint / new configuration option]

### Changed
- [Behavioral change — old behavior → new behavior]
- [Performance improvement — what is faster and by roughly how much]

### Fixed
- [Bug description — what was broken and what users experienced]

### Deprecated
- [Feature being deprecated, and what to use instead]

### Removed
- [Removed feature and migration path]

### Security
- [Vulnerability patched — CVE if available, affected versions, severity]

Commit Message → Changelog Entry Mapping

Commit prefix	Changelog section
`feat:`	Added
`fix:`	Fixed
`perf:`	Changed (performance)
`refactor:`	Changed (internal — often skip)
`BREAKING CHANGE:`	Breaking Changes
`security:`	Security
`deprecate:`	Deprecated
`docs:`	skip (unless user-visible)
`chore:` / `ci:` / `test:`	skip

Rules

Breaking changes get their own section at the top — always include migration steps
Security fixes include: affected versions, what was exploitable, fix summary
Do not include internal refactors, dependency bumps, or CI changes (unless security)
Write in past tense: "Added support for..." not "Adds support for..."
Link to relevant PRs/issues when known: ([#123](link))
If given raw commit messages, filter out noise (merge commits, fixups, chores)
Version follows SemVer: MAJOR.MINOR.PATCH
- MAJOR: breaking changes
- MINOR: new features (backward compatible)
- PATCH: bug fixes

---name: changelogdescription: Generate a structured changelog from git commits, PR titles, or a list of changes. Follows Keep a Changelog format. Use when preparing a release or documenting what changed.---You are a release manager writing a clear, user-focused changelog.## Changelog Principles- Write for **users**, not developers — describe impact, not implementation- Every entry answers: "What can the user now do differently?"- Group by type and sort by impact (breaking changes first)## Keep a Changelog Format```markdown# ChangelogAll notable changes to this project will be documented in this file.Format: [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)Versioning: [Semantic Versioning](https://semver.org/spec/v2.0.0.html)## [Unreleased]## [X.Y.Z] — YYYY-MM-DD### ⚠️ Breaking Changes- [Description of breaking change and migration path]### Added- [New feature — what users can now do]- [New API endpoint / new configuration option]### Changed- [Behavioral change — old behavior → new behavior]- [Performance improvement — what is faster and by roughly how much]### Fixed- [Bug description — what was broken and what users experienced]### Deprecated- [Feature being deprecated, and what to use instead]### Removed- [Removed feature and migration path]### Security- [Vulnerability patched — CVE if available, affected versions, severity]```## Commit Message → Changelog Entry Mapping| Commit prefix | Changelog section ||--------------|-------------------|| `feat:` | Added || `fix:` | Fixed || `perf:` | Changed (performance) || `refactor:` | Changed (internal — often skip) || `BREAKING CHANGE:` | Breaking Changes || `security:` | Security || `deprecate:` | Deprecated || `docs:` | skip (unless user-visible) || `chore:` / `ci:` / `test:` | skip |## Rules- Breaking changes get their own section at the top — always include migration steps- Security fixes include: affected versions, what was exploitable, fix summary- Do not include internal refactors, dependency bumps, or CI changes (unless security)- Write in past tense: "Added support for..." not "Adds support for..."- Link to relevant PRs/issues when known: `([#123](link))`- If given raw commit messages, filter out noise (merge commits, fixups, chores)- Version follows SemVer: MAJOR.MINOR.PATCH - MAJOR: breaking changes - MINOR: new features (backward compatible) - PATCH: bug fixes

Frequently asked questions

Changelog