Claude Code 实战（三）：自定义斜杠命令与对话控制

1
2
3
4

运行 `npm audit` 查找已安装包中的安全漏洞。
运行 `npm audit fix` 应用非破坏性修复。
运行 `npm test` 确认修复未引入新问题。
报告哪些 CVE 已被修复、哪些仍待处理。

1

/audit

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

.claude/
├── commands/               # 项目级命令（提交至 Git）
│   ├── audit.md
│   ├── review.md
│   ├── test.md
│   ├── deploy.md
│   ├── explain.md
│   ├── document.md
│   ├── onboard.md
│   └── debug.md
├── settings.json           # 项目配置（提交至 Git）
├── settings.local.json     # 个人配置（.gitignore 排除）
└── CLAUDE.md               # 项目记忆文件（建议提交至 Git，或置于仓库根目录）

1
2
3
4
5
6
7

~/.claude/
├── commands/               # 个人全局命令
│   ├── standup.md
│   ├── changelog.md
│   └── quicktest.md
├── settings.json           # 全局配置
└── auth.json               # 认证 token

1
2
3
4
5
6
7

请从三个层面解释 $ARGUMENTS：

1. **一句话定义**：用大白话说明它是什么，禁用术语。
2. **一段原理**：它如何工作？核心组件有哪些？为何存在？可辅以类比。
3. **代码级定位**：指出它在本仓库中的具体实现位置（含文件路径与行号）。

若该术语在本代码库中存在歧义，请先列出可能含义，并询问我具体想了解哪一种。

1

/explain rate limiter

1
2
3
4
5
6
7
8

<!-- .claude/commands/find.md -->
在代码库中查找所有对 $ARGUMENTS 的引用。
按以下三类分组呈现：
- 直接调用
- 重新导出（re-export）
- 测试中使用

每处引用均标注文件路径与行号。

1

/find UserService

1
2
3
4
5
6
7

<!-- .claude/commands/compare.md -->
对比 $ARGUMENTS。
以表格形式呈现关键差异，包含：
- API 表面（API surface）
- 性能影响（perf impact）

最后给出建议：针对本项目，应选用哪一个？为什么？

1

/compare axios vs fetch vs ky for HTTP requests

1
2
3
4
5
6
7
8
9

<!-- .claude/commands/coverage.md -->
分析 $ARGUMENTS 模块的测试覆盖率。

1. 找出测试该模块的测试文件；
2. 列出该模块导出的所有函数/类；
3. 对每个导出项，标明是否已有测试覆盖；
4. 对未覆盖的函数，生成测试桩（stub）。

⚠️ 不得修改现有测试，仅允许新增。

1

/coverage src/services/payment.ts

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

<!-- .claude/commands/status.md -->
展示项目当前状态。

若指定了具体领域：$ARGUMENTS → 聚焦该领域分析；
否则 → 提供全局概览：
1. Git 状态（未提交变更、当前分支、落后/超前提交数）
2. 最近 5 条提交（每条一行）
3. 是否存在失败的测试
4. 是否存在 lint 错误
5. 近一周新增的 TODO 注释

1
2

/status                    # 全局概览
/status authentication     # 聚焦鉴权模块

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

运行 `npm audit`（或本项目实际包管理器的等效命令），
查找已安装依赖中的安全漏洞。

输出报告需包含：
1. 按严重等级（critical / high / moderate / low）统计漏洞总数；
2. 对每个 critical/high 级别漏洞：列出包名、CVE 编号、是否存在可用修复；
3. 对非破坏性更新，自动执行修复命令；
4. 运行测试确认修复未引发回归；
5. 列出仍需人工干预的剩余漏洞。

若项目不使用 npm，请根据 `CLAUDE.md` 中的指引，适配 pip / cargo 等对应工具。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

运行项目测试套件（具体命令见 `CLAUDE.md`）。

对每个失败用例：
  - 引用失败的测试名及断言；
  - 展示相关代码（含测试代码与被测代码）；
  - 提出最小可行修复方案；
  - 明确标注应修改测试还是业务代码；
  - 给出置信度评级：high / medium / low。

最终汇总：
  - 总计：X 通过，Y 失败，Z 跳过；
  - 若全部通过，仅输出 “All tests pass” —— 无需冗余格式。

⚠️ 本命令仅作诊断报告，禁止实际修改代码。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

评审暂存区变更（`git diff --staged`）。

若暂存区为空，则评审工作区变更（`git diff`）；
若无任何变更，则直接说明并终止。

评审重点（按优先级排序）：
1. **正确性**：是否会引发崩溃或逻辑错误？
2. **边界情况**：哪些输入/状态未被处理？
3. **命名规范**：变量/函数名是否清晰、一致？
4. **`CLAUDE.md` 约定**：是否遵循项目约定？
5. **性能**：是否存在明显 N+1 查询、冗余循环等？
6. **安全**：是否有注入、权限绕过、数据泄露风险？

输出格式要求：
- 编号条目式呈现；
- 每条标注严重等级：🔴 必须修复 / 🟡 建议修复 / 🟢 微小建议 / 👍 值得表扬；
- 结尾附一段总结：此 PR 是否可直接合并？

Think a lot before responding.

1
2
3
4
5
6
7
8

请从三个层面解释 $ARGUMENTS：

1. **一句话定义**：用大白话说明它是什么，禁用术语。
2. **一段原理**：它如何工作？核心组件有哪些？为何存在？可辅以类比。
3. **代码级定位**：指出它在本仓库中的具体实现位置（含文件路径与行号），并梳理关键逻辑。

若该术语在本代码库中存在歧义，请先列出可能含义，并询问我具体想了解哪一种。
若代码库中未实现该概念，请作通用解释，并注明 “未在本项目中找到实现”。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

为即将加入本仓库的新工程师撰写一份一页纸的入职文档。

以 `CLAUDE.md` 为唯一权威来源，辅以关键文件阅读。

必须包含：
1. **功能定位**：一句话讲清本项目是做什么的（禁用黑话）；
2. **本地搭建**：从 clone 到成功运行的完整步骤；
3. **运行测试**：精确命令与预期输出；
4. **架构概览**：最重要的 3–5 个目录及其职责；
5. **高频雷区**：新人最容易踩坑的三件事；
6. **调试起点**：遇到问题时，第一步该看哪里？
7. **关键联系人**：各模块负责人（若 `CLAUDE.md` 中有记录）。

严格控制在一页内，拒绝注水。目标：新人 10 分钟内通读，即可上手开发。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

准备部署至 $ARGUMENTS（默认为 staging）。

检查清单：
1. 测试全部通过；
2. Lint 无错误（警告可接受）；
3. 无未提交变更（如有则预警）；
4. 当前分支为 main/master（否则预警）；
5. 展示本次将部署的提交（对比上次部署 tag）；
6. 检查变更文件中是否存在 TODO / FIXME 注释；
7. 核对环境变量是否完备（对比 `.env.example` 与 `.env`）。

结尾输出明确的 “Go / No-Go” 决策摘要。

⚠️ 本命令仅为预检，禁止实际执行部署。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

请结构化调试以下问题：

$ARGUMENTS

执行流程：
1. **复现**：明确触发该问题的精确步骤或条件；
2. **定位**：找出相关代码。从报错信息、堆栈追踪或描述中提到的模块名入手；
3. **假设**：列出 2–3 种可能原因，按可能性排序；
4. **验证**：对最可能原因，追踪代码路径并确认；
5. **修复**：提出最小改动方案，以 diff 形式呈现；
6. **验证**：说明如何测试该修复是否生效。

⚠️ 禁止实际应用修复，仅提供待审阅方案。
Think a lot before responding.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

为 $ARGUMENTS 生成文档。

若为文件路径 → 文档化该文件的导出项（函数/类/类型）；  
若为模块名 → 文档化该模块的公共 API；  
若为概念 → 解释其在本代码库中的实现方式。

对每个函数/方法，需包含：
- 一句话简介（单行）；
- 参数（含类型与说明）；
- 返回值；
- 示例用法；
- 边界情况或注意事项。

输出格式为可直接粘贴到代码中的 JSDoc/docstring 注释，风格需与项目现有文档保持一致。

1
2
3
4
5
6
7

帮我准备每日站会发言。

1. 昨日工作：执行 `git log --author="$(git config user.name)" --since="yesterday" --oneline`  
2. 今日计划：检查近期添加的 TODO 注释及当前打开的分支  
3. 阻塞问题：检查失败的测试或 lint 错误  

输出格式：三个项目符号，分别对应「昨日」「今日」「阻塞」。

1
2
3
4
5
6
7
8
9

为上次 tag 至今的变更生成符合规范的更新日志。

1. 查找最近 git tag  
2. 列出该 tag 后的所有提交  
3. 按类别分组：Features / Fixes / Breaking Changes / Other  
4. 采用 keepachangelog.com 格式书写 
5. 基于变更内容建议下一个版本号（遵循 SemVer）

⚠️ 仅输出日志内容，禁止修改任何文件。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

<!-- .claude/commands/morning.md -->
按顺序执行以下晨间检查：

1. 检查 Git 状态，确认昨日无未提交变更  
2. 从 main 分支拉取最新代码  
3. 运行测试套件（同 `/test` 行为）  
4. 列出昨日至今 main 分支新增的 TODO / FIXME 注释  
5. 总结：有何变更？有何问题？需关注什么？

这是我每日启动工作的完整快照，请一次性返回全部信息。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

<!-- .claude/commands/deps.md -->
分析 $ARGUMENTS 的依赖图谱。

输出结构化报告：

## 直接依赖
| 包名 | 版本 | 使用位置 | 用途 |
|------|------|----------|------|

## 重要传递依赖（需关注）
列出满足任一条件的传递依赖：
- 已知存在安全漏洞  
- 体积过大（>1MB）  
- 多版本共存（duplicated at different versions）

## 优化建议
- 哪些包可移除？  
- 哪些包应升级？  
- 哪些包有更优替代方案？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

<!-- .claude/commands/pre-pr.md -->
我即将提交 PR，请执行以下检查：

1. [ ] 所有测试通过  
2. [ ] 无 lint 错误  
3. [ ] 无 TypeScript 错误（`npx tsc --noEmit`）  
4. [ ] 生产代码中无 `console.log`  
5. [ ] 所有新函数均有 docstring/JSDoc  
6. [ ] 无硬编码密钥或 API Key  
7. [ ] 若架构变更，`CLAUDE.md` 已同步更新  
8. [ ] 提交信息清晰明确  

对每项检查，明确标注通过/失败。  
若全部通过，基于提交信息草拟 PR 标题与描述。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

<!-- .claude/commands/migration-check.md -->
审查待执行的数据库迁移脚本。

检查要点：
1. **可逆性**：是否存在 down 迁移？能否正常执行？  
2. **数据丢失**：是否有步骤会删除含数据的列或表？  
3. **锁表风险**：是否有步骤会在大表上执行耗时操作（如 `ALTER TABLE`）？  
4. **索引影响**：新索引是否并发创建？  
5. **默认值**：新增的 `NOT NULL` 列是否为历史数据提供了默认值？  
6. **外键约束**：新增外键是否启用校验（validated）？

Think a lot. 数据库迁移不可逆。

1
2
3
4
5

<!-- .claude/commands/explain.md -->
<!-- 用法：/explain <术语或概念> -->

Explain $ARGUMENTS at three levels:
...

1
2
3
4
5
6

由简至繁：

1. CLAUDE.md 约定    （被动）→ Claude 自动遵循  
2. 斜杠命令          （单次）→ 输入 `/name`，立即获得结果  
3. Shell 脚本 + Claude（混合）→ 脚本调用 Claude，或 Claude 调用脚本  
4. Claude Code SDK   （编程）→ 全面可控、支持状态、可测试  

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

.claude/commands/
├── audit.md          # 安全审计
├── debug.md          # 结构化调试
├── deploy.md         # 部署前检查
├── deps.md           # 依赖分析
├── document.md       # 生成文档注释
├── explain.md        # 三层解释
├── migration-check.md # 数据库迁移审查
├── onboard.md        # 新人入职指南
├── pre-pr.md         # PR 提交前检查
├── review.md         # 代码评审
└── test.md           # 测试运行与分析