jiu/.claude/commands/release.md

description, argument-hint, model, allowed-tools

description	argument-hint	model	allowed-tools
执行本地发版流程（build → test → CHANGELOG → commit → tag → push）	<version> 如 1.0.22	claude-sonnet-4-6	Bash, Read, Edit, Write

执行本地发版流程。

确定版本号：

• 如果 $ARGUMENTS 非空，使用它作为版本号（VERSION）。
• 如果 $ARGUMENTS 为空，运行 git describe --tags --abbrev=0 获取最新 tag（如 v1.0.20），去掉 v 前缀后将 patch 号加 1（如 1.0.21），作为版本号（VERSION）。将自动确定的版本号告知用户。

后续所有步骤中，将确定好的版本号记为 VERSION。

按以下步骤顺序执行，任意步骤失败立即停止并报告错误。

1. 检查工作区

检查是否有未提交的改动（git status）。如果有，列出文件并询问用户是否继续。

2. 本地构建

export PATH="/opt/homebrew/bin:$PATH"
cd backend && go build ./...

3. 运行测试

export PATH="/opt/homebrew/bin:$PATH"
cd backend && go test ./...
cd client && flutter analyze --no-fatal-infos --no-fatal-warnings

4. 更新 CHANGELOG.md

检查 CHANGELOG.md 中是否已有 ## [VERSION] 版本节。

• 已有：直接使用，不修改。
• 没有：读取 git log 从上一个 tag 到 HEAD 的提交记录，自动生成一个版本节插入到文件顶部（位于已有版本节之前），格式如下：

## [VERSION] - <今天日期>

### 新功能
- ...

### 改进
- ...

### 修复
- ...

只保留有内容的分类（新功能/改进/修复），根据 commit message 的类型（feat/fix/refactor 等）归类。

CHANGELOG 撰写原则：

• 站在用户视角总结，描述对使用体验的实际影响，而非技术实现
• 忽略以下类型的提交（产品感知弱）：
  • 发版工具、CI/CD、部署脚本相关（chore: release、ci:、devops:）
  • 内部文档、开发规范、CLAUDE.md 更新（docs(claude):、docs(internal):）
  • 代码格式、lint、重构（style:、refactor: 纯内部）
  • 依赖升级、版本号 bump（chore: bump、chore: upgrade）
• 保留并重点描述：feat、fix、perf 类，以及用户能感知到的 refactor（如界面改版、交互优化）
• 每条描述用一句话说清楚"用户能做什么"或"修了什么问题"，不堆砌技术术语

5. 提交代码

将所有改动（包括 CHANGELOG.md）用以下格式提交到 main：

chore: release vVERSION

6. 打 tag

git tag vVERSION

7. 推送

git push ssh://git@git.51yanmei.com:2222/wangjia/jiu.git main vVERSION

推送成功后提示用户：CI/CD 已触发，等待 Telegram 通知。