smithery.ai

update-changelog

Read this skill before updating changelogs

First seen Mar 26, 2026

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,259 B
  • docs SUMMARY.md 66 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 2 installs

SKILL.md

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