mcpField
U
update-changelog

update-changelog

github.com/alibabaDevelopment29.6k40 installsUpdated 8w ago
Repository

About update-changelog

update-changelog is a skill for updating `docs/CHANGELOG.md` using repository evidence rather than guesswork. It checks release notes, tags, and history, then writes a concise entry that follows the project's existing style.

Key features

  1. 01Match the existing changelog format and tone
  2. 02Identify the latest undocumented version
  3. 03Use release notes, tags, history, and diffs as evidence
  4. 04Include user-visible changes and relevant fixes
  5. 05Verify dates, versions, and Markdown structure

Use cases

  1. 01Add the newest release entry to `docs/CHANGELOG.md`
  2. 02Align changelog text with GitHub Releases
  3. 03Summarize a tag using commit history and code diffs

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/alibaba/page-agent --skill update-changelog

After installing, type/update-changelogin Claude Code to confirm it loaded.

Details

From the project README

Update Changelog

Update docs/CHANGELOG.md from repository evidence instead of guesswork.

When to Use

  • Add the newest release entry to docs/CHANGELOG.md
  • Sync changelog text with GitHub Releases
  • Summarize the latest tag from git history or code diffs

Defaults

  • Keep the wording brief
  • Only add the latest missing version unless the user explicitly asks to backfill older releases
  • Prefer GitHub sources first, especially Releases and tag metadata
  • Skip Features / Improvements / Bug Fixes headings when the release only has a few clear items

Procedure

1. Read the local style
  • Open docs/CHANGELOG.md
  • Match the existing tone, bullet style, section ordering, and date format
2. Determine the target release
  • Read the root package.json version and compare it with the top changelog entry
  • Find the previous tag for the target version
  • If the latest version is already documented, stop and report that no changelog update is needed
3. Gather evidence

Prefer these sources in order:

  1. GitHub release notes
GH_PAGER=cat gh release view v<version> --repo <owner>/<repo> --json tagName,name,publishedAt,body
  1. Tag date
git log -1 --format=%cs v<version>
  1. Commit history between tags
git --no-pager log --format='%h %s' --no-merges v<previous>..v<version>
  1. Diff scope when commit subjects are vague
git --no-pager diff --name-only v<previous>..v<version>
git --no-pager diff --stat v<previous>..v<version>
  1. Read touched files directly only when the user-visible change is still unclear
4. Distill what belongs in the changelog

Include:

  • User-visible features
  • Important behavior changes
  • Bug fixes that improve reliability, compatibility, or developer experience
  • Small docs updates only when they materially change supported setups or onboarding

Exclude unless explicitly requested:

  • Pure version bumps
  • Routine dependency updates
  • Internal refactors with no visible impact
  • Mechanical formatting noise
5. Choose the structure
  • If the release has 1 to 3 clear points, write flat bullets directly under the version heading
  • If the release has several distinct items, use short headings such as ### Features, ### Improvements, and ### Bug Fixes
  • Do not force categories when they make the entry longer or noisier
6. Write the entry
  • Add or update only the requested release entry
  • Keep bullets short and concrete
  • Reuse project terminology from nearby entries
  • Avoid marketing language
  • Do not copy noisy GitHub release text verbatim
7. Verify
  • Check dates, version numbers, and tag boundaries
  • Ensure Markdown structure matches nearby entries
  • Confirm no intermediate versions were added unless requested

Completion Checks

  • The newest requested version is documented
  • The wording is concise and consistent with the surrounding changelog
  • The entry is backed by GitHub releases, git history, or code diff evidence
  • Low-signal internal changes were left out

Comments

Markdown supported