用 Markdown 文件定义可复用的 slash command，通过 git 让团队共享提示词资产，覆盖代码审查、测试、PR 等高频场景。
Claude Code 内置了一批 slash command——/help、/clear、/compact。但真正让工作流提速的，是你自己写的那些。
本文讲的是如何设计一套可复用的 slash command 体系，让团队里每个人都能用上同一套提示词，而不是每次靠记忆重新描述任务。
在 Claude Code 里，自定义 slash command 就是一个 Markdown 文件。你把它放在指定目录，Claude Code 启动时自动识别，输入 /文件名 即可触发。
文件内容就是发给 Claude 的提示词。仅此而已。
没有特殊语法，没有配置格式，一个 .md 文件就是一个 command。
两个位置，职责不同：
| 位置 | 路径 | 作用域 |
|---|---|---|
| 项目级 | .claude/commands/ |
仅当前项目，可随代码提交 git |
| 用户级 | ~/.claude/commands/ |
所有项目，个人私有 |
项目级是团队共享的核心。把 .claude/commands/ 提交进 git，clone 仓库的每个人都自动拥有这套 commands。
用户级适合放个人习惯类的指令，比如你自己偏好的代码风格检查方式，或者只有你在用的工具集成。
在项目根目录：
mkdir -p .claude/commands
新建 .claude/commands/review.md：
审查当前改动的代码质量。重点检查：
1. 逻辑错误和边界条件
2. 命名是否清晰
3. 有没有重复代码可以提取
4. 安全问题（SQL 注入、XSS、敏感信息暴露）
给出具体的修改建议，不要泛泛而谈。
重启 Claude Code，输入 /review 即可触发。
固定内容的 command 用途有限。$ARGUMENTS 让 command 变得灵活——用户在 /command 后面输入的内容，会替换进提示词里。
例如 .claude/commands/test.md：
为以下内容编写测试：$ARGUMENTS
要求：
- 覆盖正常路径和边界情况
- 测试命名要能自解释
- 不要 mock 能用真实数据的地方
使用时：
/test UserAuthentication 类的 login 方法
Claude 收到的实际提示词是：
为以下内容编写测试：UserAuthentication 类的 login 方法
要求：
- 覆盖正常路径和边界情况
...
$ARGUMENTS 可以出现在提示词的任何位置，也可以出现多次。
一个 command，一个职责
不要写一个"万能助手"command，把所有任务塞进去。/review 只管代码审查，/test 只管写测试，/pr 只管生成 PR 描述。粒度细的 command 更容易记忆，也更容易复用。
提示词写具体，不写抽象
坏的写法：
帮我优化这段代码
好的写法：
```
优化以下代码的性能。优先考虑：
1. 减少不必要的数据库查询（N+1 问题）
2. 避免在循环里做重复计算
3. 用更高效的数据结构替换线性查找
保持接口不变，只改内部实现。
```
具体的约束条件，才能让 Claude 给出有针对性的结果。
给 command 加 frontmatter
在文件开头加上元数据，Claude Code 在命令列表里会展示 description，方便团队成员快速了解用途：
---
description: 审查当前改动，给出代码质量反馈
---
审查当前改动的代码质量...
以 Rails 项目为例，这几个 command 覆盖了日常开发的高频场景：
.claude/commands/review.md — 代码审查
审查 git diff 里的改动。检查：
- 逻辑错误和边界条件处理
- SQL 注入、权限校验等安全问题
- 命名可读性
- 是否有重复逻辑可以提取
每条问题给出具体位置和修改建议。
```
.claude/commands/test.md — 生成测试
为这段代码写测试：$ARGUMENTS
使用 RSpec。覆盖：正常路径、边界值、异常情况。
测试命名格式：describe ... context ... it ...
优先用真实对象，只在必要时 mock 外部依赖。
```
.claude/commands/pr.md — PR 描述
根据 git diff 和 commit log，生成 PR 描述。
格式：
（简述做了什么，2-3 句）
（背景和动机）
（如何验证这次改动）
语气简洁，面向 code reviewer。
```
.claude/commands/explain.md — 解释代码
解释 $ARGUMENTS 的作用：
- 整体职责是什么
- 关键逻辑怎么运作
- 有哪些值得注意的边界情况
面向刚接手这部分代码的开发者，说清楚"为什么"而不只是"做了什么"。
```
有些习惯是个人的，不适合强加给整个团队。放在 ~/.claude/commands/ 里：
~/.claude/commands/standup.md — 晨会准备
```markdown
根据今天的 git log 和未关闭的 TODO，整理一份晨会摘要：
- 昨天完成了什么
- 今天计划做什么
- 有没有阻塞项
控制在 5 句话以内。
```
~/.claude/commands/refactor.md — 重构建议
```markdown
分析 $ARGUMENTS，给出重构建议。
只提真正有价值的改动，不要为了重构而重构。
每条建议说明：能解决什么问题、改动量大不大、风险如何。
```
自定义 command 最大的价值不在于个人提效，而在于让团队形成共同语言。
把 .claude/commands/ 提交进代码库，在 README 或 CLAUDE.md 里列出可用的 commands 和用途。新人 clone 仓库后，直接就有了团队积累的提示词资产，不需要各自摸索。
随着项目演进，commands 也会迭代——发现某个提示词效果不好，改一行提交上去，全团队生效。这是提示词工程在团队层面落地的最低成本方式。
.claude/
├── commands/
│ ├── review.md # 代码审查
│ ├── test.md # 生成测试
│ ├── pr.md # PR 描述
│ └── explain.md # 代码解释
└── settings.json