chore: add cleanup and release skills for claude and codex
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
rayd1o
120
.claude/commands/cleanup.md
Normal file
120
.claude/commands/cleanup.md
Normal file
@@ -0,0 +1,120 @@
|
||||
---
|
||||
description: 审查当前工作区未提交代码中的垃圾代码，并在不影响逻辑的前提下自动清理
|
||||
argument-hint: 可选：指定要检查的文件或目录（默认检查所有未提交修改）
|
||||
allowed-tools: ["Read", "Edit", "Bash", "Grep", "Glob"]
|
||||
---
|
||||
|
||||
# /cleanup — 垃圾代码审查与清理
|
||||
|
||||
分析当前工作区（git diff）中的未提交代码，找出并修复常见垃圾代码，**不得改变任何运行逻辑**。
|
||||
|
||||
## 检查范围
|
||||
|
||||
若 `$ARGUMENTS` 非空，则只检查指定文件/目录；否则检查所有未提交修改（`git diff HEAD`）。
|
||||
|
||||
## 审查清单
|
||||
|
||||
按优先级检查以下问题（只报告在本次 diff 中**新增或修改**的代码里存在的问题）：
|
||||
|
||||
### 1. 重复逻辑 (Duplicate Logic)
|
||||
- 完全相同或高度相似的代码块在多处出现
|
||||
- 同一函数/方法被多个地方各自实现，已有公共版本未被复用
|
||||
- 相同的 DOM 查询、正则、模板字符串在同一文件重复
|
||||
|
||||
### 2. Magic Numbers / Magic Strings
|
||||
- 裸数字直接参与计算（如偏移量、时间、尺寸、阈值），没有命名常量
|
||||
- 硬编码字符串（如 id 名、状态值、URL 片段）散落在逻辑中
|
||||
- 例外：`0`, `1`, `-1`, `100`, `""` 等语义明确的惯用值不算
|
||||
|
||||
### 3. 命名问题
|
||||
- 含义不明的缩写变量（如 `or_`, `tmp2`, `x2`）
|
||||
- 命名与实际用途不符
|
||||
- 同一概念在不同地方用不同名字表达
|
||||
|
||||
### 4. 死代码 / 无效代码
|
||||
- 注释掉的旧代码块（3行以上）
|
||||
- 声明后从未使用的变量/参数/导入
|
||||
- 永远不会执行的条件分支
|
||||
|
||||
### 5. 代码风格问题
|
||||
- 尾部空白字符（trailing whitespace）
|
||||
- 同一文件内风格不一致（如混用单双引号、缩进不统一）
|
||||
- 空行使用不一致（连续多个空行等）
|
||||
|
||||
### 6. 其他常见问题
|
||||
- 私有辅助函数应被 export 但没有，导致调用方重复实现
|
||||
- 类型/接口重复定义
|
||||
- 过于冗长的条件表达式可以简化（不改逻辑）
|
||||
|
||||
## 执行步骤
|
||||
|
||||
### Step 1 — 获取待检查文件列表
|
||||
|
||||
```bash
|
||||
# 无参数时：获取所有未提交修改
|
||||
git diff HEAD --name-only
|
||||
|
||||
# 有参数时：用 $ARGUMENTS 过滤
|
||||
```
|
||||
|
||||
### Step 2 — 逐文件阅读并分析
|
||||
|
||||
- 用 Read 工具读取完整文件（不只读 diff）
|
||||
- 对照审查清单，记录每个问题：文件名、行号、问题类型、建议修复方式
|
||||
|
||||
### Step 3 — 报告问题清单
|
||||
|
||||
在修改前，先以列表形式输出所有发现的问题：
|
||||
|
||||
```
|
||||
发现 N 个问题：
|
||||
|
||||
[文件] js/foo.js
|
||||
· L34, L78: 重复逻辑 — 两处都实现了相同的 DOM 查询，可提取到 getPanel()
|
||||
· L91: Magic number — 硬编码 14 作为偏移量，应命名为 TOOLTIP_OFFSET
|
||||
|
||||
[文件] js/bar.js
|
||||
· L12: 命名问题 — 变量 `or_` 语义不明，应命名为 outerR/outerG/outerB
|
||||
...
|
||||
```
|
||||
|
||||
如果没有发现问题，直接输出"未发现垃圾代码，当前代码质量良好。"并停止。
|
||||
|
||||
### Step 4 — 执行修复
|
||||
|
||||
对每个问题，使用 Edit 工具进行**最小化修改**：
|
||||
|
||||
- **重复逻辑**：提取为共享常量/函数，更新所有调用点
|
||||
- **Magic number**：在文件顶部或逻辑附近声明 `const NAME = value`，替换所有引用
|
||||
- **命名问题**：重命名变量，更新所有使用处
|
||||
- **死代码**：直接删除
|
||||
- **尾部空白/风格**：修正
|
||||
- **未 export 的函数**：添加 `export`，在调用方改为导入（不重复实现）
|
||||
|
||||
**修复原则：**
|
||||
- 只改在审查清单中发现的问题，不做额外优化
|
||||
- 每次 Edit 只修改确实有问题的行，保持 diff 最小
|
||||
- 改完后用 `grep` 验证旧的坏代码已消失
|
||||
|
||||
### Step 5 — 输出总结
|
||||
|
||||
```
|
||||
清理完成：
|
||||
|
||||
修复了 N 个问题：
|
||||
✓ earth.js — 提取重复 vertexShader 为 ATMOS_VERTEX_SHADER 常量
|
||||
✓ main.js — 提取 TOOLTIP_CURSOR_OFFSET = 14（4处引用）
|
||||
✓ controls.js — export updateLayerButtonState，移除 main.js 中的重复实现
|
||||
...
|
||||
|
||||
未修改的问题（需人工确认）：
|
||||
! foo.js L45 — 注释代码块较长，建议手动确认是否可删除
|
||||
```
|
||||
|
||||
## 约束
|
||||
|
||||
- **禁止**改变函数签名、接口定义、导出 API（除非问题正是私有函数应被 export）
|
||||
- **禁止**添加新功能、新抽象、新参数
|
||||
- **禁止**修改注释内容（只删除注释掉的死代码）
|
||||
- **禁止**修改测试文件逻辑
|
||||
- 如果一个 Magic number 的语义不完全确定，**跳过**，在总结中标记为"需人工确认"
|
||||
145
.claude/commands/release.md
Normal file
145
.claude/commands/release.md
Normal file
@@ -0,0 +1,145 @@
|
||||
---
|
||||
description: 发版工作流：根据变更类型决定版本号，更新所有版本文件和 changelog，运行验证，commit 并 push
|
||||
argument-hint: 可选：feature | bugfix | 或直接描述本次发布内容
|
||||
allowed-tools: ["Read", "Edit", "Bash", "Glob", "Grep"]
|
||||
---
|
||||
|
||||
# /release — Planet 发版工作流
|
||||
|
||||
## 版本号规则
|
||||
|
||||
| 变更类型 | 版本跳动 |
|
||||
|---------|---------|
|
||||
| `feature` | `+0.1.0` |
|
||||
| `bugfix` | `+0.0.1` |
|
||||
| `docs` / `maintenance` / `refactor` | 默认不发版，除非用户明确要求 |
|
||||
|
||||
意图混合时以用户明确描述为准。
|
||||
|
||||
## 必须同步更新的文件
|
||||
|
||||
使用 `git rev-parse --show-toplevel` 获取仓库根目录，以下路径均相对于根目录：
|
||||
|
||||
- `VERSION`
|
||||
- `frontend/package.json`（`"version"` 字段）
|
||||
- `pyproject.toml`（`version =` 字段）
|
||||
- `uv.lock`（**不要手动编辑**，通过 `uv lock` 重新生成）
|
||||
- `docs/CHANGELOG.md`
|
||||
- `docs/version-history.md`
|
||||
|
||||
## 执行步骤
|
||||
|
||||
### Step 1 — 环境检查
|
||||
|
||||
```bash
|
||||
git branch --show-current # 确认在 dev 分支
|
||||
git status --short # 检查是否有无关的未暂存修改
|
||||
cat VERSION # 读取当前版本
|
||||
```
|
||||
|
||||
若当前**不在 `dev` 分支**，停下来告知用户，不要继续。
|
||||
|
||||
若存在无关的未暂存修改，列出并询问用户是否一并提交，或先 stash。
|
||||
|
||||
### Step 2 — 确定发版类型与新版本号
|
||||
|
||||
- 若 `$ARGUMENTS` 提供了明确类型（`feature` / `bugfix`），直接使用
|
||||
- 否则根据当前 `git diff HEAD` 和 `git log` 推断
|
||||
- 计算新版本号（例：`0.26.2` → bugfix → `0.26.3`）
|
||||
- **先输出发版计划供用户确认**：
|
||||
|
||||
```
|
||||
发版计划：
|
||||
类型：bugfix
|
||||
版本：0.26.2 → 0.26.3
|
||||
分支：dev
|
||||
将更新：VERSION, frontend/package.json, pyproject.toml, uv.lock, CHANGELOG.md, version-history.md
|
||||
```
|
||||
|
||||
### Step 3 — 更新版本号文件
|
||||
|
||||
按顺序更新（每步用 Edit 工具，精确替换，不要重写整个文件）：
|
||||
|
||||
1. `VERSION` — 直接替换全部内容为新版本号
|
||||
2. `frontend/package.json` — 替换 `"version": "x.x.x"` 行
|
||||
3. `pyproject.toml` — 替换 `version = "x.x.x"` 行
|
||||
4. 运行 `uv lock` 重新生成 `uv.lock`（在仓库根目录下执行）
|
||||
|
||||
### Step 4 — 更新 CHANGELOG.md
|
||||
|
||||
在文件顶部插入新条目，格式：
|
||||
|
||||
```markdown
|
||||
## [x.x.x] — YYYY-MM-DD
|
||||
|
||||
### ✨ Features / 🐛 Fixes / 🔧 Improvements
|
||||
- ...（只列高信号条目，最多 5 条）
|
||||
- ...
|
||||
|
||||
---
|
||||
```
|
||||
|
||||
日期使用 `date +%Y-%m-%d` 获取今天的日期。
|
||||
|
||||
### Step 5 — 更新 docs/version-history.md
|
||||
|
||||
- 更新文件头部的"当前开发版本"字段
|
||||
- 在时间线表格顶部插入新行：`| vx.x.x | YYYY-MM-DD | 一句话摘要 |`
|
||||
|
||||
### Step 6 — 验证
|
||||
|
||||
针对本次变更范围做最小验证：
|
||||
|
||||
- Python 文件有修改：`python3 -m py_compile <changed_files>`
|
||||
- Frontend 文件有修改：运行项目标准检查（若无则跳过并说明）
|
||||
- 版本号一致性检查：用 grep 确认 VERSION、package.json、pyproject.toml 中的版本号完全一致
|
||||
|
||||
```bash
|
||||
grep -h "version" VERSION frontend/package.json pyproject.toml
|
||||
```
|
||||
|
||||
### Step 7 — 提交前预览
|
||||
|
||||
展示将要提交的文件列表：
|
||||
|
||||
```bash
|
||||
git diff --stat HEAD
|
||||
```
|
||||
|
||||
再次确认所有必须文件都在变更列表中，**不包含**非预期文件（如调试文件、.env 等）。
|
||||
|
||||
### Step 8 — Commit & Push（用户确认后）
|
||||
|
||||
```bash
|
||||
git add VERSION frontend/package.json pyproject.toml uv.lock docs/CHANGELOG.md docs/version-history.md
|
||||
# 若有代码变更也一并 stage
|
||||
git add <code_files>
|
||||
|
||||
git commit -m "release: bump version to x.x.x"
|
||||
git tag vx.x.x
|
||||
git push origin dev
|
||||
git push origin vx.x.x
|
||||
```
|
||||
|
||||
commit message 固定格式：`release: bump version to x.x.x`
|
||||
|
||||
### Step 9 — 完成确认
|
||||
|
||||
输出摘要：
|
||||
|
||||
```
|
||||
✓ 版本号已更新：0.26.2 → 0.26.3
|
||||
✓ CHANGELOG 已更新
|
||||
✓ version-history 已更新
|
||||
✓ uv.lock 已重新生成
|
||||
✓ 验证通过
|
||||
✓ commit: release: bump version to 0.26.3
|
||||
✓ tag: v0.26.3
|
||||
✓ 已 push 到 origin/dev
|
||||
```
|
||||
|
||||
## 注意事项
|
||||
|
||||
- `uv.lock` 只能通过 `uv lock` 生成，绝不手动编辑
|
||||
- 发版 commit 只包含版本文件 + 本次功能代码，不混入无关改动
|
||||
- 若环境中 `uv` 不可用，说明原因并跳过 lockfile 更新，提醒用户手动运行
|
||||
Reference in New Issue
Block a user