用途
该技能用于端到端地发布 sim-use 的新版本。当用户运行 /release，或要求「ship a release」「publish a version」「cut a release」等时使用。用户只需输入命令，技能负责版本号、CHANGELOG、一次确认，随后驱动每个命令直至 homebrew-tap 提交完成。
运行位置为 sim-use 仓库根目录（git rev-parse --show-toplevel）。构建、签名、tarball 与 formula 逻辑位于 scripts/local-release.sh 中，技能不重复实现，其职责是编排：状态检查、版本号运算、CHANGELOG 渲染、用户确认、git/tap 操作与错误恢复。
主要流程
Step 1 预检：检查当前分支为 main、工作区干净、本地 main 与 origin 同步、gh auth status 成功、build_products/Frameworks/ 存在、homebrew-tap 克隆存在于 ../lycorp-jp-homebrew-tap（不存在则克隆）、Android bridge 工具链通过 scripts/build-bridge.sh --check、E2E 置信套件为绿（make e2e 等，iOS 全绿约 15 分钟，预算 20 分钟以上，任一红色套件阻断发布，除非用户在 Step 3 明确豁免）、签名与公证就绪（security find-identity 与 xcrun notarytool history）。任何检查失败则以清晰错误中止。
Step 2 确定版本并起草 CHANGELOG：查找最新 tag，读取自上一 tag 以来的提交，依据 conventional commits 自动升位（feat!: / BREAKING CHANGE 为 major；feat: 为 minor；仅 fix:/chore:/docs: 为 patch）。按 Added / Changed / Fixed / Removed 分组起草，省略纯 refactor/chore/test 提交。每条目回链其 PR 并感谢外部贡献者，格式如 (#NN) 或 (#NN — thanks @user!)。同时准备 bridge/app/build.gradle.kts 的 versionName 与 versionCode 递增。用户指定版本时按原样使用。
Step 3 与用户确认（唯一闸口）：展示上一 tag 到下一版本、提交列表、拟议的 CHANGELOG diff、发布形态（默认公证，若 Step 1.8 失败则为 ad-hoc 回退），并询问是否以此 CHANGELOG 发布。
Step 4 应用更改并提交：编辑 CHANGELOG.md，插入新版本小节；编辑 bridge/app/build.gradle.kts；提交并推送 main。
Step 5 打 tag：git tag 并推送。
Step 6 运行发布流水线：默认使用公证模式调用 scripts/local-release.sh（带 --codesign-identity、--notarize、--notary-profile、--gh-release、--tap-dir）；ad-hoc 回退仅在用户明确选择时使用。脚本中途失败时提供对应排查（bridge 构建失败、公证被拒、GitHub release 失败、冒烟测试失败）。
Step 7 提交并推送 tap：进入 ../lycorp-jp-homebrew-tap，添加 Formula/sim-use.rb，提交并推送。
Step 8 报告：展示发布的版本、GitHub release URL、tap 提交以及安装命令（brew tap lycorp-jp/tap；brew install sim-use）。
试运行与限制
用户传入 dry-run 或「preview」时，仅运行 Step 1-3，展示将要发生的操作后停止。
不应做的事：发布过程中不修改构建脚本（构建行为变更走独立提交）；不自动解决 CHANGELOG.md 的 git 冲突；不强制推送 tag；不在开发者机器上 brew install 新 formula。
适用场景
适用于 sim-use 项目的正式版本发布，要求已具备 main 分支干净、gh 认证、Go/Android bridge 工具链、签名与公证配置、E2E 套件等前置条件。
暂未提供
该技能的具体价格、收费模式、许可条款、支持平台范围等信息资料中暂未提供。