把常用请求写成 Claude Code 斜杠命令

回想一下你这周做过的几次代码审查：周一你特意叮嘱“重点查查漏测”，周三赶进度随手敲了句“帮我瞅瞅这段”，到了周五线上报警，你又要求“重点查并发性能”。

三次给出的审查要求不同，Claude 返回的报告在风格和侧重点上也各不一样。下次想对比两份报告，或者让同事照着做一遍，才发现连“审查”这件事本身都没有固定标准。

这种飘忽感，靠每次多写几句提示词很难消除。更管用的办法，是把无论何时都该坚守的共性规矩沉淀下来，做成一个斜杠命令：

• 拿到 diff 先检查哪些部分；
• 按哪些固定标准排查；
• 最终按什么结构输出发现，缺少输入时在哪里停下。

下次再调它，你只需要补充本次独有的变量，比如 PR 编号或者这次改动的目的。命令固化的是你的评判基准；它每一次有没有严格照办，还要拿实际报告逐项核验。

01 一份命令说明要回答五个问题

Slash Command 给常用任务一个固定入口。配置好以后，输入 /commit、/pr 或 /optimize，Claude Code 就读取对应说明。这些是自定义示例名，使用前需要创建。文件里写清目标、步骤、参数、当前状态、工具许可和输出，就能反复使用同一套要求。

一份可用的命令说明应回答：

02 先分清 / 菜单里的四种入口

Claude Code 的 / 菜单汇集了多种入口，先认识它们的来源：

如果一个 / 命令没出现，先查它来自哪里。内置命令、项目 Skill、插件和外部 MCP，加载来源不同；同样的菜单现象，原因也可能不同。认清来源之后，才知道该检查项目文件、插件状态，还是外部连接。

新建自定义命令时，优先放进 Skills。Claude Code 的 Skills 文档 写明自定义命令已经并入 Skill：旧式 .claude/commands/<name>.md 仍可用，但 Skill 结构更完整，能携带参考资料、模板和脚本，frontmatter 还能控制 Claude 是否可以自动调用。

迁移时尤其要留意同名实现。若 .claude/commands/review.md 和 .claude/skills/review/SKILL.md 同时存在，运行的是 Skill。于是你修改旧文件，再次调用却没有变化。先确认实际读取哪一份，再决定移除旧实现；一个入口只维护一套方法，后续才查得清。

内置命令很多，不同版本和账号的菜单也可能不同。第一次学习只需认识 /help、/permissions 和 /skills，再动手写出一个命令，其余条目遇到对应问题时回来查。上下文太满时先用 /context 查占用，再决定是否 /compact；找不到命令，就按来源查 /skills、/plugin 或 /mcp。完整清单见官方的内置命令参考。

03 用 Skill 写一个自定义命令

推荐目录结构是：

.claude/
  skills/
    my-command/
      SKILL.md

最小模板如下：

---
name: my-command
description: 说明这个命令做什么，以及什么时候使用它
---

# My Command

当这个命令被触发时，请按下面步骤处理：

1. 先读取必要上下文。
2. 再判断任务范围。
3. 最后按指定格式输出结果。

name 决定命令名，上面的例子会变成 /my-command。description 要写清触发场景，因为 Claude Code 据此判断何时使用这个 Skill，你也能在命令列表里快速识别它。

真实工作中的命令还要补上参数提示、工具权限和动态上下文：

---
name: commit
description: 根据当前改动生成一次清楚的提交
disable-model-invocation: true
argument-hint: "[optional message]"
allowed-tools: Bash(git status *) Bash(git diff *) Bash(git log *) Bash(git branch --show-current) Bash(git add *) Bash(git commit *)
---

# Commit Current Changes

## Context

- Current status: !`git status`
- Current diff: !`git diff HEAD`
- Current branch: !`git branch --show-current`
- Recent commits: !`git log --oneline -10`

## Task

Create one git commit containing only the changes authorized for this task.
Inspect staged and unstaged changes. Exclude unrelated files and secrets.
If the intended file scope is unclear, ask before staging. Do not push.
After committing, report the commit ID and included files.

If the user passed a message, use it as guidance: $ARGUMENTS

Otherwise, analyze the changes and write a conventional commit message:

- `feat:` for a new feature
- `fix:` for a bug fix
- `docs:` for documentation
- `refactor:` for refactoring
- `test:` for tests
- `chore:` for maintenance

现在输入 /commit 修复登录超时。顺着这次输入核对完整流程：

• 当前改动了哪些文件，由那几条预执行的 Git 查询作答。
• 这次为什么而改，由你敲下的参数实时补充。
• 它在本次调用里能免确认地调用哪些工具，看工具授权；做什么、不做什么，看正文里的任务说明。

下面这四项配置各管一摊：

再回过头看提示词正文。“Do not push”明确了这次任务的安全边界，conventional commit 的格式说明则规定了输出格式。allowed-tools 只负责免确认、拦不住其他工具，这一点对有副作用的命令尤其要紧，Claude Code 只读命令为什么还能改文件 专门讲了这几道边界怎样分开设。

04 参数、文件引用和动态上下文

参数让同一个命令处理不同输入。最简单的 $ARGUMENTS 代表用户在命令后输入的全部内容。

---
name: fix-issue
description: 根据问题编号修复一个已知问题
argument-hint: "[issue-number]"
---

根据编号 #$ARGUMENTS 分析问题，先说明修复思路，再修改代码。

调用方式：

/fix-issue 123

需要分别使用多个参数时，用 $0、$1 按位置读取（等同于 $ARGUMENTS[0]、$ARGUMENTS[1]）：

---
name: review-pr
description: 按优先级审查一个 PR
argument-hint: "[pr-number] [priority]"
---

审查编号 #$0，优先级为 $1。
缺少编号或优先级时，先请求补充，不猜测目标 PR。

调用：

/review-pr 456 high

用 @ 引用文件，让命令直接获得指定文件的上下文。你可以在用户输入或命令正文里写路径引用。

审查 @src/utils/helpers.ts 中的实现。
比较 @src/old-version.ts 和 @src/new-version.ts 的差异。

用 !`command` 注入动态上下文。Claude Code 会在发送 prompt 前运行 shell 命令，再把结果填进命令内容。

## Context

- Current branch: !`git branch --show-current`
- Current status: !`git status --short`
- Current diff: !`git diff HEAD`

动态命令在模型看到 Skill 正文前运行。注入区只放短小的只读查询，提交、删除等动作留在正式步骤中。

取上下文的体量也是同理，动手前先问问自己这份输出抓回来是干什么用的：

• 做代码审查，抓 diff 就够了。
• 做 commit，需要的是 status 和短 log。
• 普通整理文档，用不着把几千行的测试日志塞进去。

05 顺着执行链排查命令

先理解命令的执行顺序，出错时才能快速定位环节。

用户输入 /command-name
  |
  v
Claude Code 搜索 Skills、旧式 commands、插件命令和 MCP prompts
  |
  v
找到匹配命令
  |
  v
读取 SKILL.md 或命令文件
  |
  v
解析 frontmatter
  |
  v
替换参数，如 $ARGUMENTS、$0、$1
  |
  v
执行动态上下文命令，如 !`git status`
  |
  v
把补全后的指令发给 Claude
  |
  v
Claude 按命令说明处理并返回结果

有了这条链，排查时先看异常出现在哪一步，再调整对应的文件名、参数或正文。

比如 /review-pr 456 high 能启动，却一直问编号，入口至少已被找到。接着读正文：若只用 #$ARGUMENTS，取得的是“456 high”整串，编号与优先级没有分别说明。它可能理解，也可能误会，所以先把这当作待验证原因。

改成 $0 接编号、$1 接优先级，再用同一次调用比较。目标是否成了 #456，是否按 high 标准审查？两项都对，才说明这次调整起了作用。若仍追问，再看动态查询有没有取得目标 PR。这样每一步都沿现有证据缩小问题。

找不到命令时，先检查文件位置：

• Skill 形式：.claude/skills/<name>/SKILL.md
• 旧式形式：.claude/commands/<name>.md

再检查 name 是否和你输入的 /name 一致。修改命令文件后，如果当前会话没有刷新，可以重启 Claude Code 或重新加载相关配置。要是动态上下文出不来，先排查两处：一是语法有没有写成 !`command`，二是 allowed-tools 有没有给对应的 shell 命令放行。

命令能启动，下一步就看做的是否正确。选一个小 diff，对照报告：它指向的是本次变化吗，要求的检查项有没有出现，未运行的验证有没有说明？缺少输入时，先说明缺什么并停下来，才符合约定。

06 哪些流程值得做成命令

下面这些任务高频、流程稳定，也容易检查结果，适合直接做成命令。

第三列是执行时要核对的内容。把它们写进命令文件，让 Claude Code 知道做到哪一步、结果要满足什么要求。

保存前再分一次“方法”和“材料”。范围怎样确定、严重性怎样判断、报告怎样组织，可以固定；PR 编号、基准分支和实际 diff，每次都要取得。上次 diff 留进模板，入口看似复用成功，报告却可能仍在回答旧问题。为当前输入留出位置，才能真正复用方法。

各类命令还应补齐自己的标准：

• 优化：解释性能、内存、算法、缓存或并发问题。
• PR 准备：交代为什么改、测了什么、影响哪里。
• API 文档：核对签名、注释、请求响应和错误示例。
• 文档重组：保留入口、交叉引用和内容关系。
• CI 配置：先识别已有语言、框架和工具链。
• 补测试：查未测分支、边界、错误路径与关键业务。

文件准备好后，再看谁需要使用它。团队共同遵守的流程，放项目 .claude/ 并随代码维护；个人跨项目习惯，放用户目录。这样改团队规则时，大家能取得同一版本，也不会误把个人习惯分发给全组。

从旧式命令迁移到 Skill 时，把 .claude/commands/optimize.md 移到 .claude/skills/optimize/SKILL.md。文件移好，再从一次实际调用往回看，按三项核对：

1. name 是否等于预期命令名。
2. description 是否写清触发场景。
3. 旧命令文件是否需要删除，避免同名冲突。

最后用下面几种现象检查自己的命令：

一个命令写得好不好，最终看的是一次真实调用。找到入口、收到回复只是第一步；它有没有根据这次输入完成约定的工作，决定了这个入口值不值得留下。