cc-router: Skill for Claude Code

发版准备（release-prep）

这个 skill 在做什么

cc-router 每个版本的更新内容写在仓库根目录 release-notes/<版本>/，编译期内嵌进 app（升级后自动弹窗展示，侧栏底部礼花可重开），CI 也用同一份文件生成 GitHub Release 正文。本 skill 把「升版本号 + 写四语更新内容 + 校验 + 本地提交」串起来，停在打 tag 之前。

完整设计见 docs/superpowers/specs/2026-09-27-release-notes-popup-design.md（本地文件，被 gitignore）。

铁律

• 绝不 git tag、绝不 git push、绝不 gh release …。结束时只打印用户要执行的命令。
• 写之前先问、不猜：拿不准的条目（是否对用户可见、属于哪一节、要不要写）列出来问用户。
• 简中是准绳，繁中、英、日从简中译出；四份结构逐条对应。
• 提交说明里不提任何其他开源项目的名字，不写用户私有配置值（示例一律中性化），不写 OSS / 国内镜像源的运维细节（bucket、ACL、密钥之类）。

流程

Step 1：前置检查与版本号

git status --short          # 必须干净（允许的只有与本次发版无关、用户明确说不管的文件）
git rev-parse --abbrev-ref HEAD   # 应在 main；不在就问用户
git describe --tags --abbrev=0 --match 'v*'   # 上一个版本 tag，记为 PREV
node -p "require('./package.json').version"   # 当前版本号

• 用户给了版本号：确认它比 PREV 新（semver）。
• 没给：按 Step 2 的素材判断——有「新功能」→ 升 minor；只有修复 → 升 patch；有破坏性变化或用户说是大版本 → 升 major。给出建议版本号请用户确认后再继续。
• 预发布版本（含 -，如 6.1.0-beta.1）：先问用户要不要写更新内容。不写的话 CI 会放行，预发布说明本来也不会展示给正式版用户；这种情况跳过 Step 4–5。
• 顺便问一句版本代号（如 6.0.0 的 Sketchbook），可以不填。

Step 2：收集素材

git log --no-merges --reverse --format='--- %h %an%n%B' PREV..HEAD

默认只读提交信息（标题 + 正文）——这个仓库的提交正文大多写得很完整，够用。以下情况必须看改动本身：标题含糊（如 update providers、fix、wip）、没有正文、或正文与标题对不上。先 git show --stat <sha> 看动了哪些文件，再只看相关文件的 diff（git show <sha> -- <path>），弄清它实际包含几处用户可感知的变化。

整理规则：

1. 排除只动 release-notes/ 的提交：它们是在补写 / 修订已发布版本的说明（例如 PREV 打 tag 之后才补齐的上一版说明），不是本版本的变化。
2. 按用户可感知的变化归类，不按 conventional-commit 前缀机械归类：
   • ## 新功能：用户能用到的新能力、新界面、新入口、行为上的新选项。
   • ## 修复：上一个版本里已经存在的问题被修好。
   • ## 其他：用户能感知但不算功能 / 修复的变化（打包、日志、依赖升级带来的可见影响、文档）。
3. 同一版本里新功能的修补提交并进那条新功能，不单列进「修复」。判断方法：修的东西是在 PREV 之后才加的（同一 scope、提交时间在 PREV 之后）。
4. 默认不写：纯重构、测试、CI 流程、内部文档、代码风格、只影响开发者的改动。例外：它带来了用户可见的影响（例如「安装目录不再附带 yaml 文件」）。
5. 合并同类、拆分混装：同一功能的多个提交写成一条，子要点用二级列表；反过来，一个提交里混了几处不相干的变化（常见于标题含糊的提交，比如一个「修复 + 新端点 + 改名」的厂商更新），按变化拆到各自的分节里。
6. 外部贡献者的 PR（提交作者不是维护者）：问用户要不要致谢，不要自己决定。PR 编号从合并提交的标题找（Merge pull request #48 from …），找不到再用只读命令 gh pr list --state merged --search <sha>。用户同意的话，写在要点名后面的编号里：
   • zh：**新增 Requesty 服务商**（#48，感谢 @作者）：…
   • en：**Requesty provider** (#48, thanks @author): …
   • ja：**Requesty プロバイダーを追加**（#48、@author さんに感謝）：…
7. 拿不准的条目汇总成一个列表问用户（一次问完，不要一条一条问）。