Changelog

Skill tuliosousapro/SaaS-blueprint/skills/changelog

Generates and maintains changelogs following Keep a Changelog format. Use when updating release notes, finishing tasks, or tagging versions. For version bumps, see semantic-versioning.From its SKILL.md

Install

npx -y skills add tuliosousapro/SaaS-blueprint --skill changelog

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

2 things to look at

4 stars4 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.
runs commandsInstructs the agent to run 1 command, including `git log --oneline`.

SKILL.md

2.6 KB, 592 tokens by cl100k_base, as published. Nobody here has run it

Changelog Skill

When to Use

After completing a sprint or shipping a feature.
Before tagging a release or pushing to main.
When the user asks "what changed?" or "update the changelog".

Reference

Keep a Changelog v1.1.0

Instructions

1. Locate or Create CHANGELOG.md

Check project root for CHANGELOG.md.
If missing, create it with the header:

# 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]

2. Gather Changes

Scan recent work using:

git log --oneline since last tagged version.
tasks/todo.md completed items.
User description of what was shipped.

3. Categorize Changes

Every change goes into exactly one category:

Category	When to Use
Added	New features, new files, new capabilities
Changed	Modifications to existing functionality
Deprecated	Features that will be removed in future versions
Removed	Features that were removed
Fixed	Bug fixes
Security	Vulnerability patches

4. Determine New Version

Automatically invoke the semantic-versioning skill.
Use the categorized changes to determine if the next version should be Major, Minor, or Patch.
Ensure the version is updated in both CHANGELOG.md and .github/repository-metadata.json.

5. Write Entry

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

### Added
- Brief description of what was added

### Changed
- Brief description of what changed

### Fixed
- Brief description of what was fixed

6. Rules

Most recent version at the top.
Always include the date in ISO format (YYYY-MM-DD).
One line per change, starting with a verb.
Group related changes under the same category.
Keep an [Unreleased] section at the top for ongoing work.
Never delete old entries.
Synchronization: Always ensure the version number matches between CHANGELOG.md and .github/repository-metadata.json.

Quality Gates

Every entry has a date.
No empty categories (remove the heading if nothing to list).
Entries are human-readable (not git commit hashes).
Version Integrity: The new version strictly follows SemVer logic and is synchronized across the workspace.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most readme changelog skills give in 592 tokens

Counted across 446 of the 460 authors here whose files we hold, read 2026-09-06

Follow Keep a Changelog formatin 24 of 446
Collect commits since the last git tagin 15 of 446, across 13 files
Omit empty sectionsin 14 of 446
Put breaking changes first with migration stepsin 14 of 446
Include migration guidance for breaking changesin 11 of 446, across 10 files
Categorize commits by conventional commit prefixin 11 of 446
Mark breaking changes prominentlyin 10 of 446
Prepend the new entry to CHANGELOG.mdin 9 of 446
Highlight breaking changes with migration notesin 8 of 446, across 7 files
Classify changes into Keep a Changelog categoriesin 8 of 446, across 7 files
Group related commits into single entriesin 8 of 446
Write the changelog from commitsin 8 of 446

Said here and by no other author read

Scan changes since the last tagged version
Invoke the semantic-versioning skill to determine the version
Keep the version number synchronized across files
Date entries in ISO format
Start each change line with a verb

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.