happy-next: Skill for Claude Code

Happy Next 发布流程

总则

流程分四段：自动检查 → 确认发布计划 → 执行 → 失败处理。

• 根据审计结果推荐发布线组合，写进发布计划。
• 用户在调用时用自然语言说明了要发什么（如"只发 Docker"、"这次不发 CLI"、"把 v2.15.1 提交到 App Store"），按用户的意思确定发布线，其余流程相同；意思不明确时在发布计划里写出你的理解。
• 只确认一次：发布计划。用户确认（或修改后确认）即授权执行计划内的全部操作，包括推送 main、合并 PR、npm 发布、创建 tag、GitHub Release、Docker、iOS 提审和 OTA 发布。确认后直接执行，直到完成或遇到停止条件。
• 计划外的操作（计划外的改动、覆盖、重建、删除）需单独确认。

五条发布线：

• Release、Docker、iOS 同一次发布共用同一个不可变 tag 和 commit。
• iOS 只提交 Release 已发布的 IPA，必须在 Release 验证通过之后。
• 推送 tag 不会发布任何东西；每条线都要显式触发 workflow。
• OTA 不需要 tag，也不经过商店审核，发布后用户的 App 会自动下载，所以 App 的改动能比 Release / iOS 早几天到达用户手里。

每条线的基准

每条线以自己上一次成功发布的版本为基准审计改动：

# CLI：最近一个 CLI 版本提交
BASE_CLI=$(git log --format=%h --grep='^release: happy-next-cli' -1)

# Release：最近一个正式 GitHub Release 的 tag
BASE_APP=$(gh release list --limit 50 --exclude-drafts --exclude-pre-releases \
  --json tagName -q '.[].tagName' | grep '^v[0-9]' | sort -V | tail -1)

# Docker：最近一次成功的 Docker workflow（run-name 为 "Docker vX.Y.Z"）
BASE_DOCKER=$(gh run list --workflow=docker-publish.yml --status success --limit 50 \
  --json displayTitle -q '.[].displayTitle' | sed -n 's/^Docker //p' | sort -V | tail -1)

# iOS：最近一次成功的提审（run-name 为 "iOS App Store vX.Y.Z"）
BASE_IOS=$(gh run list --workflow=ios-submit.yml --status success --limit 50 \
  --json displayTitle -q '.[].displayTitle' | sed -n 's/^iOS App Store //p' | sort -V | tail -1)

# 全局最高的 v tag
TOP_TAG=$(git tag --sort=-version:refname | grep '^v[0-9]' | head -1)