happy-next: Skill for Claude Code

Happy Next 发布流程

总则

每次调用先让用户选择一条发布线，只展开对应 checklist：

• A. 仅 CLI
• B. GitHub Release（App + Desktop）
• C. Docker
• D. iOS App Store
• E. 全部

版本关系：

• CLI 使用 packages/happy-cli/package.json 中的独立 npm 版本。
• B、C、D 使用同一个不可变的 vX.Y.Z git tag 和同一个源代码 commit。
• B 包含 Android APK/AAB、iOS IPA、macOS Universal、Windows x64、Windows ARM64 和 latest.json。
• D 不重新构建 IPA，只提交 B 已发布的同一份 IPA。
• 推送 tag 本身不会发布 GitHub Release 或 Docker；必须显式触发相应 workflow。
• 不再提供“仅桌面追加到既有 Release”入口。

不要默认发布全部。任何会真实发布、提交 App Store、创建 tag、覆盖 Secret 或修改 Release 的操作，都必须先展示目标版本和完整命令并等待用户确认。

共用前置检查

git status --short --branch
git branch --show-current
git fetch origin --tags
git pull --ff-only origin main

要求：

• 工作区干净；
• 当前分支为 main；
• 本地 main 与远端同步；
• 不得自行 stash、覆盖用户修改或强制推送。

如果不干净，提供“先提交指定改动 / 用户自行处理”选项，不要自作主张。

发布前更新

进入发布流程前：

1. 查询 @openai/codex 最新稳定版，更新 packages/happy-cli/src/codex/package.ts 及相关版本引用。
2. 根据官方最新资料，更新 packages/happy-wire/src/modelCatalog.ts 中 Codex、Claude Code、Gemini 的模型，以及对应的 reasoning effort、上下文窗口、Fast Mode 和定价等关联配置。
3. 更新相关测试；修改 happy-wire 后先运行 yarn build，并运行受影响包规定的类型检查和测试。
4. 展示改动和验证结果。有改动时先让用户确认提交并推送，重新通过共用前置检查后再继续发布；没有改动则直接继续。

发布入口选择

询问用户：

• A. 仅 CLI
• B. GitHub Release（App + Desktop）
• C. Docker
• D. iOS App Store
• E. 全部

选择后只执行对应分支。

A. 仅 CLI

A1. 审计 CLI 改动

LAST_CLI=$(git log --oneline --grep='^release: happy-next-cli' | head -1 | awk '{print $1}')
RANGE="${LAST_CLI:+${LAST_CLI}..HEAD}"
git log ${RANGE:--30} --oneline --no-merges -- packages/happy-cli packages/happy-wire

展示 CLI/wire 改动。如果没有需要发布的 CLI 改动，建议取消。

A2. 校验

cd packages/happy-cli
yarn build

修改过 happy-wire 时还必须：

cd packages/happy-wire
yarn build

A3. 决定 CLI 版本

node -e "
const v = require('./packages/happy-cli/package.json').version.split('.').map(Number);
console.log('当前: ' + v.join('.'));
console.log('patch: ' + v[0] + '.' + v[1] + '.' + (v[2] + 1));
console.log('minor: ' + v[0] + '.' + (v[1] + 1) + '.0');
console.log('major: ' + (v[0] + 1) + '.0.0');
"