用途
该技能为 Docus 的新版本生成完整的 GitHub Release 正文，输出为仓库根目录下的 v<version>.md 文件。使用者编辑该文件后，将内容粘贴到 GitHub Release 中。生成脚本负责机械性工作，撰写者负责需要判断和核实的两部分：Highlights 与 New documentation 列表。
运行时机
pnpm release 会写入 CHANGELOG.md 区块、打标签、推送，并在浏览器中打开预填的 GitHub Release。应在此时运行该技能，用生成的正文替换预填内容。
补丁版本（x.y.z 中 z > 0）没有 Highlights 分区。生成脚本会根据版本号判断这一点，因此补丁版本跳过第 2 步。
使用步骤
1. 生成脚手架
运行以下命令生成脚手架：
node .claude/skills/release-notes/scripts/generate.mjs # CHANGELOG.md 中最新的版本
node .claude/skills/release-notes/scripts/generate.mjs 5.16.0 # 指定版本
脚本读取 CHANGELOG.md 中对应版本的区块，写出 v<version>.md，其中包含：
## ✨ Highlights占位（由撰写者填写，仅次要版本与主要版本）；- 从 changelog 复制而来、带 emoji 标题的 Breaking Changes / Features / Bug Fixes / Performance / Reverts 分区；
## 💚 Contributors：通过一次 gh api graphql 调用获取 PR 作者与提交共同作者，@larbish 排在首位，其余按贡献数量排序；- 当 docs/content/en 有变更时，生成
## 📚 New documentation占位； - Full Changelog 对比链接。
脚本会打印 Highlight 候选（Features、Performance 和 Breaking Changes 的条目）以及新文档候选（新页面与新增的 ##/### 标题）。gh 必须已完成认证（gh auth status）。
2. 撰写 Highlights（仅次要版本与主要版本）
补丁版本跳过此步，即使某个修复值得注意。
挑选 2 到 4 项变更，按影响力从高到低排列。候选可以来自 Performance：次要版本可以没有新功能（v5.15.0 全部是性能工作）。
适合写入 Highlight 的内容：
- 用户可以开启或配置的新能力（app.config.ts 键、nuxt.config.ts 选项、新组件、插槽或组合式函数）；
- 广泛或横切性的变更（assistant、MCP、llms.txt 与 agents、搜索、SEO、i18n、主题、性能）；
- 解决长期存在或广受欢迎需求的变更。
跳过范围窄的修复、文档修复和内部重构。每个 Highlight 按以下格式撰写：
### 🤖 简短标题
用一两句话说明它做什么、为什么重要，并链接[指南](https://docus.dev/en/ai/assistant#custom-provider)。
```ts [app.config.ts]
// 最小化的真实示例
[!TIP] 可选的提示框，用于说明注意事项或有趣的细节。
规则：
- 写之前先核实。对照已合并的 PR（gh pr view <n> --repo nuxt-content/docus）、docs/content/en/**、layer/index.d.ts（nuxt.config 选项）、layer/app/types/index.d.ts 与 layer/nuxt.schema.ts（app.config）、layer/modules/** 和 layer/app/components/** 核对选项名、默认值与组件。绝不编造 API。
- 语气保持一致：简洁、直接，不用长破折号，读起来像 Baptiste 写的。可参考最近几次发布：先运行 gh release list --repo nuxt-content/docus --limit 5，再运行 gh release view <tag> --repo nuxt-content/docus。
- 描述实际发布的内容，而不是它带来的可能性。标题必须与真实变更相符。不要把一个小选项夸大成大功能（例如 markdown 协商上的 vary 头属于缓存修复，不是“agent-ready docs”）。
- 不确定时，宁可少写几条准确的 Highlight，也不要写满四条。
Emoji 用法：🤖 assistant/MCP/agents，🏎️ 性能，🔍 搜索/SEO，🎨 主题/自定义，🌐 i18n，🧩 组件，♿ 无障碍。
### 3. 破坏性变更与升级说明
如果存在 ⚠️ Breaking Changes 分区，或某个功能/修复要求用户升级时修改项目（查看 PR 描述确认），在相关分区下方添加提示框，写明迁移步骤和文档链接：
```markdown
> [!WARNING]
> 变更了什么、需要做什么，以及[文档链接](https://docus.dev/en/...)。
4. 填写 New documentation（有候选的发布）
只保留记录本次发布新内容的页面和章节。删掉被重命名、移动或改写的标题。逐个核对锚点与页面上的标题是否一致。以裸 URL 列表形式列出，每条一个：
## 📚 New documentation
* https://docus.dev/en/ai/assistant#custom-provider
如果没有符合条件的条目，删除整个分区。
5. 检查并汇报
- 确认贡献者名单正确。邮箱未关联 GitHub 账号的共同作者会被漏掉，可运行：git log <prev>..<tag> --pretty=%b | grep -i co-authored-by。
- 删除遗留的 <!-- TODO --> 注释。
- 告知用户文件路径、选择了哪些 Highlight（仅次要/主要版本）以及保留了哪些文档链接。
- 不要提交该文件。它是临时草稿文件（已被 .gitignore 忽略），由用户粘贴到 GitHub。
格式约定（与过去的发布保持一致）
- 分区顺序：Highlights → Breaking Changes → Features → Bug Fixes → Performance → Reverts → Contributors → New documentation → Full Changelog。
- 补丁版本跳过 Highlights，从第一个 changelog 分区开始。
- 标题使用 unicode emoji（## 🚀 Features），不使用 :shortcodes:。
- Performance Improvements 更名为 Performance。
- 文档 URL 去掉数字前缀：docs/content/en/4.ai/1.assistant.md → https://docus.dev/en/ai/assistant。