Conventional changelog
A portable, shareable collection of AI agent skills — structured instruction packs that teach coding agents how to perform specific tasks consistently.
npx -y skills add ebal/AI-Skills --skill conventional-changelogAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 22 days oldThe repository was created 22 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 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
Keep a Changelog v1.1.0 format for maintaining CHANGELOG.md files. Use when creating, updating, or reviewing changelogs. Covers the standard categories (Added, Changed, Deprecated, Removed, Fixed, Security), Unreleased tracking, version dating, yanked releases, and anti-patterns. Trigger when the user says "update changelog", "write changelog", "release notes", or needs help maintaining a project changelog.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
6.6 KB, as published. Nobody here has run it
Keep a Changelog — Conventional Changelog Skill
Maintain a human-readable, chronologically ordered CHANGELOG.md following Keep a Changelog v1.1.0.
File
Name it CHANGELOG.md at the project root. Use Markdown.
Header
Place this preamble at the top of the file:
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
Structure
## [Unreleased]
## [1.2.0] - 2025-07-14
### Added
- ...
### Changed
- ...
## [1.1.0] - 2025-06-01
### Fixed
- ...
Rules
- Latest version first — reverse chronological order. The
[Unreleased]section is always at the top. - Every version gets an entry — even if the only change is a dependency bump.
- Date format — ISO 8601:
YYYY-MM-DD. - Group changes by type — each type gets its own
###subsection within a version. - Link versions — each version heading should be a link to its comparison (GitHub/GitLab tag diff or commit range).
- Mention SemVer — the header should state adherence to Semantic Versioning.
Change Categories
Use exactly these six categories. Do not invent new ones. A category with no changes is omitted (do not leave empty sections).
| Category | SemVer | Use When |
|---|---|---|
### Added | MINOR | New features visible to users. |
### Changed | MINOR | Changes in existing functionality. |
### Deprecated | — | Features that will be removed in a future release. |
### Removed | MAJOR | Features removed entirely. |
### Fixed | PATCH | Bug fixes. |
### Security | PATCH | Vulnerability fixes or exposure changes. |
Entry Style
- For humans, not machines — write descriptions a user can understand without reading source code.
- Imperative mood — "Add feature" not "Added feature".
- One line per change — keep entries concise. Group related changes if needed.
- Link to issues/PRs — reference
#123orowner/repo#123in the entry when relevant. - No commit hashes — this is a curated log, not
git log.
Unreleased Section
Keep an ## [Unreleased] section at the top to track upcoming changes. This serves two purposes:
- Users see what to expect in the next release.
- At release time, move its contents into a new version section.
At release time:
- Create a new
## [X.Y.Z] - YYYY-MM-DDsection below[Unreleased]. - Move all entries from
[Unreleased]into the new section. - Update the version comparison links at the bottom of the file.
Version Links
Maintain comparison links at the bottom of the file. For GitHub:
[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
[1.1.0]: https://github.com/OWNER/REPO/compare/v1.0.0...v1.1.0
Yanked Releases
Mark yanked releases clearly:
## [0.0.5] - 2014-12-13 [YANKED]
The [YANKED] tag is intentionally loud. It is also machine-parseable due to the brackets.
Anti-Patterns — Never Do These
| Anti-Pattern | Why It's Bad | Do This Instead |
|---|---|---|
Dump git log as changelog | Full of noise: merge commits, obscure titles, trivial changes | Curate entries manually; one entry per user-visible change |
| Ignore deprecations | Users hit breaking changes with no warning | Always add a Deprecated entry before removing features |
| Use regional date formats | DD/MM/YYYY vs MM/DD/YYYY is ambiguous | Always use ISO 8601: YYYY-MM-DD |
| Incomplete changelog | Users can't trust it as a source of truth | Every version gets an entry; every notable change is listed |
| Leave empty sections | Creates noise, implies something was forgotten | Omit categories with no changes |
| Put breaking changes only in body | Changelog tools won't detect them | Use ### Removed or note it prominently in the entry |
Generating Entries from Git History
When building a changelog from git history, use conventional commit types to map commits to categories:
| Commit Type | Changelog Category |
|---|---|
feat | ### Added |
fix | ### Fixed |
perf | ### Changed |
refactor | ### Changed |
deprecate / ! suffix | ### Deprecated |
revert | ### Removed (if it removes a feature) |
security | ### Security |
docs, style, test, ci, chore, build | Omitted (not user-visible) |
Example
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
## [1.2.0] - 2025-07-14
### Added
- Dark mode support for the dashboard.
- Export reports as PDF (#142).
### Changed
- Upgrade minimum Node.js version to 18.
- Improve error messages for failed login attempts.
### Deprecated
- The `legacyExport` option. Use `export` instead.
### Fixed
- Fix race condition when saving multiple settings concurrently (#139).
- Resolve blank screen on Safari 17.
### Security
- Update jsonwebtoken to patch CVE-2024-XXXXX.
## [1.1.0] - 2025-06-01
### Added
- User profile page.
### Fixed
- Typo in onboarding flow.
## [1.0.0] - 2025-05-01
### Added
- Initial release.
[unreleased]: https://github.com/acme/app/compare/v1.2.0...HEAD
[1.2.0]: https://github.com/acme/app/compare/v1.1.0...v1.2.0
[1.1.0]: https://github.com/acme/app/compare/v1.0.0...v1.1.0
[1.0.0]: https://github.com/acme/app/releases/tag/v1.0.0