mirror of
https://github.com/kuaifan/dootask.git
synced 2026-04-24 02:38:12 +00:00
ddc0046e24
- 新增 .claude/skills/release/SKILL.md：CSO 描述、前置检查、三步发布流程 - 删除 .claude/commands/release.md - 补充基线测试暴露的反模式约束（禁止自动修复脏工作区、禁止 git tag、禁止 git add -A） Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
84 lines
3.2 KiB
Markdown
84 lines
3.2 KiB
Markdown
---
|
||
name: release
|
||
description: Use when releasing a new DooTask frontend version from the `pro` branch. Rigid sequential workflow (translate → version → build → commit → push) with strict pre-checks (branch, clean worktree, Node 20+) and per-step user confirmation. Use when user says "发布新版本", "release", "出新版本", "打版本". Stop on any failure; do NOT auto-fix dirty worktree, do NOT add tag step, do NOT use `git add -A`.
|
||
---
|
||
|
||
# DooTask 发布流程
|
||
|
||
**刚性技能**——严格按顺序执行，每步向用户确认，任何一步失败立即停止。
|
||
|
||
## 核心原则
|
||
|
||
**违反字面规则 = 违反流程精神。** 不要擅自增加、省略、合并或重排步骤。
|
||
|
||
## 前置检查（全部通过才能继续）
|
||
|
||
执行任何发布步骤前，依次检查：
|
||
|
||
1. **分支**：必须是 `pro`，否则停止，提示用户切换
|
||
2. **工作区**：`git status` 必须干净（无未提交变更、无未跟踪文件），否则**停止**并交由用户处理
|
||
3. **Node.js**：必须 ≥ 20，否则停止
|
||
|
||
检查通过后汇报结果，用户确认后再开始执行。
|
||
|
||
## 发布步骤
|
||
|
||
**每步执行前**向用户确认；**每步执行后**报告结果。
|
||
|
||
### Step 1: 翻译
|
||
```shell
|
||
npm run translate
|
||
```
|
||
更新多语言翻译文件。
|
||
|
||
### Step 2: 版本号
|
||
```shell
|
||
npm run version
|
||
```
|
||
更新版本号。
|
||
|
||
### Step 3: 构建前端
|
||
```shell
|
||
npm run build
|
||
```
|
||
构建前端生产版本。
|
||
|
||
## 最终：提交并推送
|
||
|
||
所有步骤完成后：
|
||
|
||
1. 通过 `git diff` + `git status` 汇总所有变更，向用户报告摘要
|
||
2. **询问用户是否提交并推送**
|
||
3. 用户明确确认后才执行 `git add`、`git commit`、`git push`
|
||
4. 未确认一律不执行
|
||
|
||
提交规范：
|
||
- 提交信息使用 `release: v<新版本号>`（与历史提交风格一致，参见 `git log --oneline | grep '^release:'`）
|
||
- **只 add 本次发布相关改动**，按文件名显式添加（例如 `git add package.json public/js/...`），**不要用 `git add -A` 或 `git add .`**，以免卷入未跟踪的本地实验文件
|
||
|
||
## 失败处理
|
||
|
||
- 任何步骤失败立即停止，报告错误信息
|
||
- **不要**自动重试
|
||
- **不要**自动跳过失败步骤
|
||
- 由用户决定如何处理
|
||
|
||
## 禁止项（基线测试暴露的反模式）
|
||
|
||
| 错误做法 | 正确做法 |
|
||
|---------|---------|
|
||
| 遇到脏工作区主动提出修复方案（加 `.gitignore`、先 push 等） | **停下**，报告脏工作区事实，交用户决定 |
|
||
| 增加 `git tag v1.7.xx` 步骤 | DooTask 现行发布流程**不打 tag**，不要擅自添加 |
|
||
| `git add -A` / `git add .` | 按文件名显式添加发布相关改动 |
|
||
| 一次性 add + commit + push，不给确认机会 | 摘要 → 问确认 → 再 add/commit/push 三步分离 |
|
||
| 把 translate/version/build 顺序自作主张调整 | 顺序固定为 translate → version → build |
|
||
| 失败后"我再试一次"或"跳过这步" | 立即停止，交还给用户 |
|
||
|
||
## Red Flags —— 出现这些念头立即停下
|
||
|
||
- "这个脏工作区我来帮 TA 搞定一下" → 停下，交用户
|
||
- "顺便打个 tag 吧" → 不，没有这一步
|
||
- "`git add -A` 省事" → 不，显式 add
|
||
- "翻译这步没改动可以跳" → 不，按顺序执行、执行后报告结果即可
|
||
- "一起 commit + push 一气呵成" → 必须先让用户确认
|