| name | my-update-version |
| description | 针对 cc-desktop 的版本发布 skill：检查 master 与工作区状态，确定新版本，更新 package.json 与文档、生成 CHANGELOG、提交 bump commit、创建 tag、推送 origin 与本地备份 remote，并在可用时确认 CI 是否触发。用户要求发版、升级版本号、更新更新日志、打 tag 或推送发布时使用。 |
CC Desktop 版本发布
用于本仓库的正式发版流程。目标是稳定完成版本号更新、更新日志生成、Git 提交、打 tag、按 remote 规则推送 origin 与本地备份仓库，并把关键确认点交给用户，不静默跳过。
适用场景
- 用户要求“发版”“升级版本号”“出一个新版本”“打 tag 并推送”
- 用户要求同步更新
package.json、CLAUDE.md、docs/CHANGELOG.md 和文档头部版本号
- 用户要求按本仓库约定推送
master、发布 tag 与本地备份仓库
执行要求
- 所有 Git 操作都使用非交互命令。
- 编辑文件时优先使用
apply_patch；如果该工具在当前环境不可用，则使用最小范围的文件写入命令。
- 在每个关键点前先向用户汇报当前状态，再继续执行。
- 任何失败都必须显式报告；不要假装成功。
- 不要用破坏性 Git 命令。
- 如果网络或沙箱限制阻止
git push、git tag、gh 等命令，在真正需要执行时再申请提升权限。
- 发版关键步骤必须严格串行执行，绝对不要把
git commit、git tag、git push、gh run list 放进并行工具调用里。
- 顺序必须固定为：先
git commit 成功，再 git tag 成功，再 git push origin master 成功，再 git push origin vX.Y.Z 成功，之后才允许推送本地备份 remote 或检查 CI。
- 每一步执行后都要重新读取并确认当前
HEAD / tag / remote 状态，再进入下一步；不要基于“上一步应该成功”的假设继续。
输入规则
- 用户可直接指定版本号，例如：
1.7.35
- 未指定时，从
package.json 当前版本做 patch +1
- 版本号必须是
X.Y.Z 格式
工作流
1. 预检查
先运行并汇总以下信息：
git branch --show-current
git status --short
git remote
git describe --tags --abbrev=0
Get-Content package.json -TotalCount 40
规则：
- 当前分支必须是
master，否则停止并提示用户先处理分支。
- 如果工作区不干净，不要把脏改动静默塞进发版 commit。要明确问用户：
- 是否先把这些改动整理并提交为正常业务 commit，再继续发版。
- 如果用户不希望纳入本次发版，则停止。
- 从
package.json 读取当前版本号。
- 在继续前，向用户明确展示：当前版本、建议新版本、最近 tag、当前 remote 列表。
2. 确定新版本号
- 如果用户显式给出版本号，直接使用。
- 否则对当前版本做 patch +1。
- 在任何文件修改前，向用户展示
当前版本 -> 新版本 并等待确认。
3. 生成 CHANGELOG 条目
命令：
git describe --tags --abbrev=0
git log <last-tag>..HEAD --oneline
如果仓库中还没有 tag，则改用：
git log --oneline -20
处理规则：
- 只基于 commit 历史生成更新日志，不要从未提交 diff 猜测更新内容。
- 按 commit message 前缀分组：
feat: -> 新增 (Feat)fix: -> 修复 (Fix)docs: -> 文档 (Docs)chore: / build: / ci: -> 其他 (Chore)test: -> 测试 (Test)
- 没有前缀时，根据提交内容做最合理的中文归类。
- 为每条 commit 生成简洁中文描述，不直接照抄原 commit message。
- 省略纯版本 bump 提交，例如
chore: bump version to X.Y.Z。
- 空分类不要输出。
生成格式：
---
## vX.Y.Z - YYYY-MM-DD
### 新增 (Feat)
- 条目描述
### 修复 (Fix)
- 条目描述
插入规则：
- 目标文件是
docs/CHANGELOG.md
- 插入位置是文件开头第一个
--- 之后
- 保留已有历史条目顺序，新版本始终放在最前面
4. 更新版本相关文件
更新以下文件：
package.json
CLAUDE.md
docs/CHANGELOG.md
docs/ARCHITECTURE.md
docs/code-index/main.md
- 更新文档头部
> CC Desktop vX.Y.Z |
docs/code-index/renderer.md
- 更新文档头部
> CC Desktop vX.Y.Z |
docs/code-index/ipc-channels.md
- 更新文档头部
> CC Desktop vX.Y.Z |
如果某个目标文件不存在，或找不到预期版本模式，不要盲改。先停止并把不匹配点报告给用户。
5. Git 提交
默认提交文件：
git add package.json CLAUDE.md docs/CHANGELOG.md docs/ARCHITECTURE.md docs/code-index/main.md docs/code-index/renderer.md docs/code-index/ipc-channels.md
git commit -m "chore: bump version to X.Y.Z"
规则：
- 只暂存本次发版明确相关的文件。
- 如果用户要求把其他已确认的发版相关文件一起纳入，可额外
git add。
- 不要顺手提交无关改动。
- 提交完成后，必须单独执行
git rev-parse --short HEAD 或 git log --oneline -1，确认 bump commit 已成为当前 HEAD。
6. 创建 tag
先创建：
git tag vX.Y.Z
规则：
git tag 必须在 bump commit 成功后单独执行，不能与 git commit 放在同一个并行批次里。- 创建 tag 后，必须单独执行
git show --no-patch --oneline vX.Y.Z，确认 tag 指向当前 bump commit。
7. 推送到 origin 和本地备份 remote
先获取 remote：
git remote
规则：
origin 必须存在；如果不存在则停止。- 所有 remote 都不要使用
--tags，避免历史 tag 差异导致整次推送报错。
- 镜像/备份 remote 如需同步发布 tag，只推当前版本对应的单个 tag。
- 推送顺序必须串行，且必须先完成
origin/master，再完成 origin 的单个版本 tag，最后才处理 local 等其他 remote。
git push origin master 与 git push origin vX.Y.Z 之间必须插入状态确认：重新读取 origin/master 或至少确认本地 HEAD 未变化。- 任何 remote 推送都不要和其他 remote 的推送并行执行。
命令规则：
git push origin master
对 origin 额外执行：
git push origin vX.Y.Z
完成 origin 两步后，建议追加核对：
git fetch origin --tags
git show --no-patch --oneline origin/master
git show --no-patch --oneline vX.Y.Z
对于其他 remote（如 local，存在才推）：
- 先
git push <remote> master
- 再
git push <remote> vX.Y.Z
如果某个 remote 推送失败：
- 记录失败信息
- 继续尝试其他 remote
- 在最终摘要中逐个说明状态
8. 确认 CI
默认按“推送并构建”执行，优先检查：
gh run list --limit 3
规则：
- 如果
gh 不存在、未登录、或沙箱限制导致命令无法执行，明确告诉用户未能自动确认 CI。
- 不要因为无法查询
gh 而否定发版结果；只把它当作“未核验”。
最终输出
完成后给出简洁摘要，至少包含：
- 新版本号
- 新增 changelog 条目数
- bump commit 是否成功
- tag 是否成功创建
origin 与本地备份 remote 的推送状态- CI 是否已触发或仅为未核验
异常处理
- 任一关键 Git 步骤失败：立即停止后续依赖步骤
origin 推送失败：报告失败，其他 remote 是否继续由当前步骤依赖关系决定- 无 tag 时：使用最近 20 条 commit 作为 changelog 素材
- 如果生成的 changelog 明显无法概括提交内容，先向用户展示草稿再落盘
