wangjia
e550b73d6d
- release.md 补 frontmatter（model: claude-sonnet-4-6） - 新增 /build：go build/vet + flutter analyze 编译静态检查 - 新增 /test：go test + flutter test - 三者均通过 frontmatter 指定 sonnet 4.6 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.3 KiB
2.3 KiB
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。
按以下步骤顺序执行，任意步骤失败立即停止并报告错误。
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 中是否已有 ## [$ARGUMENTS] 版本节。
- 已有：直接使用，不修改。
- 没有：读取
git log从上一个 tag 到 HEAD 的提交记录，自动生成一个版本节插入到文件顶部（位于已有版本节之前），格式如下：
## [$ARGUMENTS] - <今天日期>
### 新功能
- ...
### 改进
- ...
### 修复
- ...
只保留有内容的分类（新功能/改进/修复），根据 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 v$ARGUMENTS
6. 打 tag
git tag v$ARGUMENTS
7. 推送
git push ssh://git@git.51yanmei.com:2222/wangjia/jiu.git main v$ARGUMENTS
推送成功后提示用户：CI/CD 已触发，等待 Telegram 通知。