Agent Skills › mercurjs/mercur › release-note

release-note

GitHub

将 Mercur 版本的自动变更日志和合并 PR 转化为符合产品语调的人类可读 GitHub 发布说明，涵盖亮点、修复及贡献者致谢。

.claude/skills/release-note/SKILL.md mercurjs/mercur

Trigger Scenarios

用户要求为稳定版本编写或润色发布说明用户提供自动生成的变更列表并要求生成正式说明

Install

npx skills add mercurjs/mercur --skill release-note -g -y

More Options

Non-standard path

npx skills add https://github.com/mercurjs/mercur/tree/main/.claude/skills/release-note -g -y

Use without installing

npx skills use mercurjs/mercur@release-note

指定 Agent (Claude Code)

npx skills add mercurjs/mercur --skill release-note -a claude-code -g -y

安装 repo 全部 skill

npx skills add mercurjs/mercur --all -g -y

预览 repo 内 skill

npx skills add mercurjs/mercur --list

SKILL.md

Frontmatter

{
    "name": "release-note",
    "description": "Write the GitHub release note for a stable Mercur release from the auto-generated changelog and the merged PRs. Use when the user asks to \"write \/ create \/ polish the release note\" for a `vX.Y.Z` tag, pastes the auto-generated \"What's Changed\" list, or wants a release note in Mercur's voice.",
    "argument-hint": "[vX.Y.Z]"
}

release-note — Mercur GitHub release notes

Turn a release's merged PRs into a curated, human-readable note in Mercur's own voice. The reference is our v2.3.0 note and references/example-v2.3.4.md. Other projects' notes (e.g. Vendure) are inspiration for structure only — never copy their tone, section names, or length 1:1.

Use this skill when:

a stable tag (vX.Y.Z) was pushed and the auto-generated note needs replacing
the user pastes the "What's Changed" list and asks for a proper note

Workflow

Collect the PR list. Use what the user pasted, or:
```
gh release view vX.Y.Z --json body -q .body
```
The range is the previous stable tag → this tag (vX.Y.(Z-1)...vX.Y.Z), not the last canary. The GitHub "View changes" link from changelogithub points at the last canary and is wrong for this purpose.
Filter. Drop:
- every chore: vX.Y.Z-canary.N / -rc.N / chore: vX.Y.Z version bump
- change + revert pairs that net to zero (e.g. a pin and its rollback)
- a feature, its revert, and its re-land collapse into one entry citing the re-land PR
Read the substantive PRs — titles are not enough to explain impact:
```
gh pr view <n> --json body -q .body
```
Always read ! (breaking) PRs, feat PRs, and anything touching migrations, config (withMercur, feature flags) or Medusa versions.
Draft into the scratchpad as release-notes-vX.Y.Z.md using the format below, then send it to the user for review.

Publish only after the user approves:

gh release edit vX.Y.Z --notes-file <path>

Format

# Mercur vX.Y.Z

<2–4 sentence intro: the theme of the release, the headline features, the Medusa bump if any, "plus a batch of fixes">

## ⚠️ Before you upgrade
<only if needed: breaking changes (from `!` PRs), migrations to run, config/flag changes. Short bullets with PR refs.>

## ✨ Highlights

### <emoji> <Feature name>
<2–4 sentences: what it enables for an operator/vendor/developer, the hook/API name in backticks, what happens if you don't opt in. (#PR)>

### 🧩 More extension points
- <smaller additive seams, one line each (#PR)>

### Platform
- **Bump Medusa to X.Y.Z** (#PR).

## 🐛 Fixes
- <imperative, one line, user-visible effect (#PR)>

## 📚 Docs
- <docs PRs (#PR)>

## 🙌 New contributors
- @handle made their first contribution in #PR — thank you!

**Full Changelog**: https://github.com/mercurjs/mercur/compare/vPREV...vX.Y.Z

Rules

Voice: friendly, concise, product-first ("sellers can now…", "lets a plugin…"). Not a security advisory, no tables, no exhaustive per-file detail.
Group by impact, not by package. Features go in Highlights; small additive hooks go under "More extension points"; everything else is a Fix.
Every bullet cites its PR as (#1234). Omit sections that would be empty.
Breaking changes must name the removed endpoints/fields/links concretely so users can grep for them.
Mention migrations whenever a PR adds columns or a Migration* file.
Don't invent behaviour — if a PR body doesn't say it, don't claim it.
No AI attribution in the note.