How do I install the Release Changelog skill?

Run npx skillmds@latest add umijs/release-changelog in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Release Changelog safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Release Changelog?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Release Changelog free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Release Changelog?

umijs (@umijs) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Release Changelog by umijs — Agent Skill

Name: Release Changelog
Author: umijs

Release Changelog

Polish a published qiankun GitHub Release's aggregated notes into a bilingual (English then Chinese) write-up with an agent. Use after a release goes out — turning the mechanically-aggregated, per-package release notes into a clean, human-readable, English + Chinese write-up (highlights, de-duped cross-package lines, clearer wording) via `gh release edit`. Triggers include "polish the release notes", "clean up the GitHub release", "improve the changelog for the latest release".

umijs Updated Sep 17, 2026

File contents

Release changelog

Qiankun releases are commit-driven: CI auto-derives changesets from Conventional Commits, changesets writes each sub-package's own CHANGELOG.md (so npm shows a per-package changelog), and on publish scripts/generate-release-notes.mjs aggregates those into one GitHub Release per version.

That aggregated Release is mechanical (raw per-package changelog lines). This skill polishes it into a human-readable, bilingual write-up — an English version on top, a Chinese version below — after the fact, directly on the GitHub Release, without touching any committed changelog. Read .changeset/README.md for the surrounding flow.

When to run

After a release has been published (the "Version Packages" PR was merged and CI created the GitHub Release). Typically: "polish the latest release notes".

Steps

Find the release to polish (default: the most recent one):
```
gh release list --limit 5
gh release view <tag> --json tagName,name,body
```
Confirm the target tag with the user if it's not obviously the latest.
Read the mechanical notes from the release body. This is the raw material — the aggregated per-package changelog. Do not invent anything not present in it (cross-check against git log <prev-tag>..<tag> only to understand, not to add unlisted changes).
Polish the notes, keeping the per-package structure so consumers still see each sub-package and its version. Polishing means:
- Lead with a short Highlights list (2–5 bullets) when the release has notable user-facing changes; skip it for small patch releases.
- Rewrite terse lines into clear, user-facing wording; keep the (#PR) reference at the end of each line.
- De-duplicate: a change that touched many packages is often better stated once under the facade qiankun section than repeated under every package.
- Drop noise (pure "Updated dependencies" internal bumps).
Produce a bilingual document — the full English version first, then the full 简体中文 version, separated by a --- rule. Keep the identical per-package structure and (#PR) references in both halves; translate the prose (highlights, descriptions), never the package names, versions, or PR numbers. Template:
```


## Highlights

- ...

## qiankun `<version>`

- ...

---



## 更新亮点

- ...

## qiankun `<version>`

- ...
```
Show the user the proposed notes and get approval.
Update the release (does not re-tag or re-publish npm):
```
gh release edit <tag> --notes-file <polished.md>
```

Do not

Do not run gh release create, re-tag, or re-publish to npm — only edit the notes of an existing release.
Do not edit any CHANGELOG.md or .changeset/* — the per-package changelogs are the committed record; this skill only refines the GitHub Release prose.
Do not add changes that aren't in the mechanical notes / commit history.

---name: release-changelogdescription: Polish a published qiankun GitHub Release's aggregated notes into a bilingual (English then Chinese) write-up with an agent. Use after a release goes out — turning the mechanically-aggregated, per-package release notes into a clean, human-readable, English + Chinese write-up (highlights, de-duped cross-package lines, clearer wording) via `gh release edit`. Triggers include "polish the release notes", "clean up the GitHub release", "improve the changelog for the latest release".---# Release changelogQiankun releases are commit-driven: CI auto-derives changesets from Conventional Commits, changesets writes each sub-package's own `CHANGELOG.md` (so npm shows a per-package changelog), and on publish `scripts/generate-release-notes.mjs` aggregates those into **one GitHub Release** per version.That aggregated Release is **mechanical** (raw per-package changelog lines). This skill polishes it into a human-readable, **bilingual** write-up — an English version on top, a Chinese version below — after the fact, directly on the GitHub Release, without touching any committed changelog. Read `.changeset/README.md` for the surrounding flow.## When to runAfter a release has been published (the "Version Packages" PR was merged and CI created the GitHub Release). Typically: "polish the latest release notes".## Steps1. **Find the release to polish** (default: the most recent one): ```bash gh release list --limit 5 gh release view <tag> --json tagName,name,body ``` Confirm the target tag with the user if it's not obviously the latest.2. **Read the mechanical notes** from the release `body`. This is the raw material — the aggregated per-package changelog. Do not invent anything not present in it (cross-check against `git log <prev-tag>..<tag>` only to understand, not to add unlisted changes).3. **Polish** the notes, keeping the per-package structure so consumers still see each sub-package and its version. Polishing means: - Lead with a short **Highlights** list (2–5 bullets) when the release has notable user-facing changes; skip it for small patch releases. - Rewrite terse lines into clear, user-facing wording; keep the `(#PR)` reference at the end of each line. - De-duplicate: a change that touched many packages is often better stated once under the facade `qiankun` section than repeated under every package. - Drop noise (pure "Updated dependencies" internal bumps).4. **Produce a bilingual document** — the full **English** version first, then the full **简体中文** version, separated by a `---` rule. Keep the identical per-package structure and `(#PR)` references in both halves; translate the prose (highlights, descriptions), never the package names, versions, or PR numbers. Template: ```markdown  ## Highlights - ... ## qiankun `<version>` - ... ---  ## 更新亮点 - ... ## qiankun `<version>` - ... ```5. **Show the user the proposed notes** and get approval.6. **Update the release** (does not re-tag or re-publish npm): ```bash gh release edit <tag> --notes-file <polished.md> ```## Do not- Do not run `gh release create`, re-tag, or re-publish to npm — only edit the notes of an existing release.- Do not edit any `CHANGELOG.md` or `.changeset/*` — the per-package changelogs are the committed record; this skill only refines the GitHub Release prose.- Do not add changes that aren't in the mechanical notes / commit history.

Frequently asked questions