| name | release |
| description | 自动化 MeetCat 完整发布流程：版本号确定、changelog 生成、extension 打包、Tauri app 发布。当用户提到发布新版本、准备 release、bump version、更新 changelog 时触发此 skill。即使用户只是简单地说"发布"或"release"，也应该使用此 skill。 |
MeetCat Release
执行 MeetCat 全量发布（Tauri 桌面端 + Chrome 扩展）。流程分五个阶段，按顺序执行。
前置检查
开始前确认：
- 当前目录是 MeetCat 项目根目录
- 工作区干净或仅有发布相关文件的改动（版本文件、CHANGELOG）
gh CLI 已登录（gh auth status）
如果有未提交的非发布相关改动，提醒用户先处理。
Phase 1: 确定版本号
- 读取 root
package.json 中的当前版本
- 找到最新的 git tag 确认上次发布版本
- 列出自上次 tag 以来的所有 commits：
git log <last-tag>..HEAD --oneline
- 根据变更内容建议版本号（遵循 semver）：
- patch（x.y.Z）：仅 bug 修复
- minor（x.Y.0）：新功能，向后兼容
- major（X.0.0）：破坏性变更
- 将建议版本号和 commit 摘要呈现给用户确认
- 用户确认后：
- 如果 package.json 中的版本已经是目标版本，跳过此步
- 否则执行
pnpm run version:set <version>
- 注意：
version:set 除了改 root / 各 workspace 的 package.json 和 Cargo.toml，还会跑 cargo 同步 Cargo.lock。输出里可能出现 Updating crates.io index / Adding ... 等行，属预期，不是脏改动。
Phase 2: 更新 Changelog
- 读取当前
CHANGELOG.md
- 分析自上次 release tag 以来的所有 commits
- 按 Keep a Changelog 格式分类：
- Added：新功能
- Changed：已有功能的变更
- Fixed：bug 修复
- Deprecated / Removed / Security：按需使用
- 在版本标题下写一行总结，概括本次发布的主题
- 每条 bullet 以过去式动词开头（Added…、Fixed…、Changed…）
- 内容面向用户视角，不写实现细节
- 跨 Tauri 和 extension 的变更要说明涉及的平台
格式要求：
- 版本标题不写日期，使用
## [VERSION] 格式（release 脚本会自动补上日期）
- 新版本条目插入在
## [Unreleased] 之后
将 changelog 草稿呈现给用户审阅。用户确认后写入 CHANGELOG.md。
重要：不要 git commit。 release:app 脚本会自动提交所有发布相关文件。
写入后跑 git status 确认脏文件全部落在白名单内 —— scripts/release-tauri-github.sh 维护了 RELEASE_ALLOWED_DIRTY_FILES（CHANGELOG.md / package.json / 各 workspace package.json / Cargo.toml / Cargo.lock 等），出现其它脏文件会让脚本 abort。意外动到的文件需要先 stash 或 revert 再进 Phase 3。
Phase 3: 打包 Extension
执行：
pnpm run release:extension
这会构建扩展并生成 release/meetcat-extension-<VERSION>.zip。
自动上传 Chrome Web Store： 如果环境变量 CWS_CLIENT_ID / CWS_CLIENT_SECRET / CWS_REFRESH_TOKEN（通常通过 .env）已设置，脚本会调 scripts/publish-extension.sh 自动上传到 Chrome Web Store。
观察脚本输出最后一段，判断走的是哪条路径：
- 看到 "publish complete" 之类的成功输出 → 已自动上传
- 看到 "CWS credentials not set, skipping..." → 凭证缺失，本次没上传，需要后续手动上传
在 Phase 5 汇报中转达这个状态。
Phase 4: 发布 App
这一步需要交互式输入密码（updater 签名密钥密码、Apple 公证凭据），无法自动执行。
告诉用户自行在终端中运行：
pnpm run release:app
并说明此命令会：
- 自动提交版本文件和 CHANGELOG（commit message:
chore(release): prepare <VERSION>）
- 给 CHANGELOG 盖上当天日期
- 构建并公证 macOS app
- 创建 git tag
- 推送并创建 GitHub Release（附带所有构建产物）
等用户报告完成后再进入下一阶段。
Phase 5: 验证与收尾
用户确认 release:app 完成后：
- 确认 release commit 和 tag 都已推到远端：
git log origin/master..HEAD --oneline 应为空（commit 已 push）git ls-remote --tags origin | grep <version> 应能找到 tag- 如果其中任一缺失，再补一次
git push origin master --follow-tags。正常情况下 release-tauri-github.sh 已经替你把 commit + tag 都推上去了，不要无脑跑 git push --tags。
- 验证本地 tag 存在：
git tag --sort=-v:refname | head -3
- 验证 GitHub Release：
gh release view <version>
- 汇报发布结果：
- GitHub Release URL
- Extension zip 路径（
release/meetcat-extension-<VERSION>.zip）
- Chrome Web Store 上传状态（来自 Phase 3 观察）：
- 已自动上传 → 告诉用户在 Chrome Web Store 开发者后台等审核
- 凭证缺失/未上传 → 提醒用户手动上传 zip
部分发布
如果用户只想发布其中一个平台：
- 仅 extension：跳过 Phase 4，只执行 Phase 1-3 + Phase 5 中的 extension 部分
- 仅 app：跳过 Phase 3，Phase 4-5 正常执行
- 仅更新 changelog：只执行 Phase 1-2
