chore(claude): 将 /release 命令转换为 skill

- 新增 .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>

.claude/commands/release.md

@@ -1,53 +0,0 @@
-# 发布流程
-
-刚性流程——严格按顺序执行，每步确认，任何一步失败则停止。
-
-## 前置检查
-
-在执行任何发布步骤之前，必须依次检查：
-
-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
-```
-
-构建前端生产版本。
-
-### 最终确认：提交并推送
-
-所有步骤完成后，通过 `git diff` 和 `git status` 获取所有变更，向用户汇报摘要。
-
-汇报完毕后询问用户是否提交并推送。用户确认后才执行 git add、commit 和 push，否则不执行。
-
-## 失败处理
-
-- 任何步骤失败后立即停止，报告错误信息
-- 不要自动重试或跳过失败步骤
-- 由用户决定如何处理

.claude/skills/release/SKILL.md

@@ -0,0 +1,83 @@
+---
+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 一气呵成" → 必须先让用户确认