update-changelog
Automates the process of identifying changes and updating the project changelog.
Install
mkdir -p .claude/skills/update-changelog && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/7183" && unzip -o skill.zip -d .claude/skills/update-changelog && rm skill.zipInstalls to .claude/skills/update-changelog
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Read this skill before updating changelogsKey capabilities
- →Identify the most recent git tag as a baseline version
- →Extract commit logs between the baseline and HEAD
- →Append new entries to the Unreleased section of a changelog
- →Format entries using markdown with past-tense verbs
- →Group changes by importance and type
How it works
It determines the baseline version via git tags, retrieves commits since that point, and appends them to the Unreleased section of the changelog file while following specific markdown and content guidelines.
Inputs & outputs
When to use update-changelog
- →Update changelog with recent commits
- →Format new entries for a release
- →Identify notable changes for users
About this skill
Update the repository changelog with changes between the last release and the current version (main) that are not yet incorporated. If CHANGELOG.md does not exist, use CHANGELOG instead.
Step-by-Step Process
1. Determine baseline version
If no baseline version is provided, use the most recent git tag. You can find it with git describe --tags --abbrev=0.
2. Find the commits from git
Use the following commands to gather commit information:
# Get the baseline version (if not provided)
git describe --tags --abbrev=0
# Get all commits since the baseline version
git log <baseline-version>..HEAD
3. Update the changelog
Read the existing changelog file (CHANGELOG.md, or CHANGELOG if missing) and check if there are changes not yet incorporated, then add them. Always add them to the "Unreleased" section only. If there is none yet, add it at the top in the same style as the existing changelog (for example, ## Unreleased vs ## [Unreleased]).
Ground Rules When Writing Changelogs
Content Guidelines
- Focus on notable changes that affect users (features, fixes, breaking changes)
- Mention pull requests (
#NUMBER) when available, but not raw commit hashes - Ignore insignificant changes (typo fixes, internal refactoring, minor documentation updates)
- Group related changes together when appropriate
- Order entries by importance: breaking changes first, then features, then fixes
Style Guidelines
- Use valid markdown syntax
- Start each entry with a past-tense verb or descriptive phrase
- Keep entries concise but descriptive enough to understand the change
- Use bullet points (
*or-) for individual changes - Format code references with backticks (e.g.,
`foo.cleanup`)
Example Format
## 2.13.0
* Added multi-key support to the `|sort` filter. #827
* Fix `not undefined` with strict undefined behavior. #838
* Added support for free threading Python. #841
## 2.12.0
* Item or attribute lookup will no longer swallow all errors in Python. #814
* Added `|zip` filter. #818
* Fix `break_on_hyphens` for the `|wordwrap` filter. #823
* Prefer error message from `unknown_method_callback`. #824
* Ignore `.jinja` and `.jinja2` as extensions in auto escape. #832
Good vs. Bad Examples
Good:
Fixed an issue with the TypeScript SDK which caused an incorrect config for CJS.Added support for claim timeout extension on checkpoint writes.Improved error reporting when task claim expires.
Bad:
Fixed bug(too vague)Updated dependencies(insignificant unless it fixes a security issue)Refactored internal code structure(internal change, not user-facing)Fixed typo in comment(insignificant)
Notes
- If the current changelog already has an "Unreleased" section with content, append to it rather than replacing it
- Preserve the existing changelog style and formatting (headings, bullet style, ordering, and spacing)
- If the repo uses a different default branch name, treat that as the "current version" instead of
main - When in doubt about whether a change is significant, err on the side of including it
When not to use it
- →Including insignificant changes like typo fixes or internal refactoring
- →Replacing existing changelog content instead of appending to it
Limitations
- →Requires manual identification of notable changes
- →Depends on the existence of git tags for baseline determination
How it compares
Unlike manual entry, this process automates the retrieval of commits and enforces consistent categorization and formatting standards.
Compared to similar skills
update-changelog side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| update-changelog (this skill) | 1 | 6mo | Review | Beginner |
| prepare-changelog | 6 | 7mo | Review | Beginner |
| workthrough | 10 | 8mo | Review | Beginner |
| generate-release-notes | 7 | 8mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by mitsuhiko
View all by mitsuhiko →You might also like
prepare-changelog
nextest-rs
Guidelines for preparing changelog entries for nextest releases following Keep a Changelog format
workthrough
bear2u
Automatically document all development work and code modifications in a structured workthrough format. Use this skill after completing any development task, bug fix, feature implementation, or code refactoring to create comprehensive documentation.
generate-release-notes
teambit
Generate comprehensive release notes for Bit from git commits and pull requests. Use when creating release notes, building changelogs, documenting version releases, or preparing a new Bit release.
changelog-generator
ComposioHQ
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
release-note-generation
microsoft
Toolkit for generating PowerToys release notes from GitHub milestone PRs or commit ranges. Use when asked to create release notes, summarize milestone PRs, generate changelog, prepare release documentation, request Copilot reviews for PRs, update README for a new release, manage PR milestones, or collect PRs between commits/tags. Supports PR collection by milestone or commit range, milestone assignment, grouping by label, summarization with external contributor attribution, and README version bumping.
doc-check
coder
Checks if code changes require documentation updates