第 01 章

Slash Commands

把重复的对话流程，压缩成一条稳定、可复用、可分享的命令

一个命令文件，不只是快捷键，更是团队工作流的入口

重复的对话

你有没有发现，每天都在对 Claude Code 说几乎一样的话？

每次提交代码

都要重新解释一遍："请根据 diff 生成 conventional commit 格式的提交信息，不要超过 72 个字符……"

每次审查代码

都要重新描述一遍："请从安全性、可维护性、代码质量三个维度审查，按严重程度排列……"

每次准备 PR

都要重新回忆一遍："先跑 lint，再跑测试，然后生成变更摘要……"

一周下来，同样的提示词你敲了不下二十遍——而且每次结果还不一样。

Slash Command 就是为这个设计的：把重复的对话流程，压缩成一条稳定、可复用、可分享的命令。一次写好，全团队受益。

开始之前

适合谁

刚开始用 Claude Code，还在重复敲同样提示词的人
想把个人经验沉淀成团队可复用流程的人
知道 Markdown 和基本命令行，但还没写过 Skill 的人

读完后你应该已经能

分清内置命令、Skill、旧式 command、插件命令、MCP prompts
写出一个最小可运行的 slash command
给命令加参数、上下文注入、文件引用和安全边界
判断哪些命令适合做成教程，哪些已经太重了

这些内容暂时先不碰

复杂插件打包与发布
多 agent 编排与 context: fork 的高级用法
大型 Skill 的 references、assets、scripts 设计
生产环境自动部署细节

环境与版本：基于 Claude Code 2.1.97 附近的命令体系编写。文中优先使用 .claude/skills/，因为自定义 slash command 已经逐步并入 Skills。如果你曾用过 .claude/commands/，两者仍然共存，但 Skill 同名时优先。

重复变命令

把"我每次都要重复说一遍"的操作，变成"以后只要输入一条命令"

学之前，常见困难

每次提交代码，都要重复解释"请根据 diff 生成 commit message"
每次准备 PR，都得自己想起 lint、test、summary 这些步骤
团队成员各写各的 prompt，结果风格不一致
危险操作没有统一防护，容易把"方便"写成"事故"

学之后，可以直接做到

/commit 自动读取 diff，生成合适的提交说明
/pr 按固定清单准备 Pull Request
/push-all 在安全检查后批量暂存、提交、推送
把"隐性经验"变成"显式流程"，让自己和团队都更稳

这章要做的事：把"我每次都要重复说一遍"的操作，变成"以后只要输入一条命令"。

四类命令

Slash Command 就是你在 Claude Code 里敲 `/` 开头的东西。说白了，它就是一个快捷方式的入口——你敲一个 `/命令名`，Claude Code 就去执行一段预设好的操作。

这些命令有四种来源。别急，你只需要先记住前两种，后两种知道它们存在就行。

内置命令

Claude Code 自带，解决通用交互问题。55+ 个内置命令 + 5 个内置 Skill。

/help /clear /model /compact /config

Skills（推荐）

现在最推荐的自定义方式，本质是一个带说明的目录，可打包脚本和模板。

.claude/skills/commit/SKILL.md

旧式 command（仍可用）

单个 Markdown 文件，直接放在 commands 目录。若与 Skill 同名，Skill 优先。

.claude/commands/commit.md

插件与 MCP prompts

来自插件或 MCP server，通常用于外部能力接入。

/plugin:command 或 /mcp__github__list_prs

先抓主线：先学自定义 Skill 的最小闭环，再看参数、上下文、目录位置和安全边界；插件与 MCP 先认识入口，不急着深挖。

内置命令速查

以下是最常用的内置命令。在 Claude Code 中输入 / 可查看完整列表，继续键入字母可筛选。

命令	用途	别名
会话与对话管理
`/clear`	清空对话	`/reset` `/new`
`/branch [name]`	分支对话到新会话	`/fork`
`/resume [session]`	恢复对话	`/continue`
`/rewind`	回退对话和/或代码	`/checkpoint`
`/rename [name]`	重命名会话	—
`/exit`	退出 REPL	`/quit`
`/compact [instructions]`	压缩对话，可附带聚焦指令	—
`/export [filename]`	导出对话到文件或剪贴板	—
模型与推理
`/model [model]`	选择模型，可用左右箭头调整 effort	—
`/effort [low\|medium\|high\|max\|auto]`	设置推理强度；max 需 Opus 4.6	—
`/fast [on\|off]`	切换快速模式	—
配置与环境
`/config`	打开设置	`/settings`
`/init`	初始化 CLAUDE.md（可设 `CLAUDE_CODE_NEW_INIT=1` 启用交互式流程）	—
`/memory`	编辑 CLAUDE.md / 切换自动记忆	—
`/permissions`	查看或更新权限	`/allowed-tools`
`/add-dir <path>`	添加工作目录	—
`/color [color\|default]`	设置提示栏颜色	—
`/theme`	更改颜色主题	—
`/statusline`	配置状态栏	—
`/terminal-setup`	配置终端快捷键	—
`/keybindings`	打开快捷键配置	—
`/sandbox`	切换沙盒模式	—
`/hooks`	查看 hook 配置	—
`/context`	用彩色网格可视化上下文占用	—
`/privacy-settings`	隐私设置（仅 Pro/Max）	—
诊断与统计
`/status`	显示版本、模型、账号	—
`/cost`	查看 token 使用统计	—
`/doctor`	检查安装健康状态	—
`/stats`	可视化每日使用量、会话和连续天数	—
`/insights`	生成会话分析报告	—
`/diff`	查看未提交变更的交互式 diff	—
扩展能力
`/mcp`	管理 MCP servers 和 OAuth	—
`/plugin`	管理插件	—
`/reload-plugins`	重新加载当前插件	—
`/skills`	列出可用 Skills	—
`/agents`	管理 agent 配置	—
`/ide`	管理 IDE 集成	—
`/chrome`	配置 Chrome 浏览器集成	—
工作流与自动化
`/plan [desc]`	进入规划模式	—
`/goal [condition]`	设置完成条件，Claude 跨 turn 自走直到条件被评估器确认	—
`/schedule [desc]`	创建/管理定时任务	—
`/voice`	按住说话语音输入	—
`/tasks`	列出/管理后台任务	—
`/copy [N]`	将回复复制到剪贴板；`w` 写入文件	—
`/security-review`	分析分支中的安全漏洞	—
`/pr-comments [PR]`	获取 GitHub PR 评论	—
账号与远程
`/login`	切换 Anthropic 账号	—
`/logout`	退出当前 Anthropic 账号	—
`/extra-usage`	配置额外用量以应对速率限制	—
`/desktop`	继续在桌面应用中处理	`/app`
`/mobile`	生成移动端扫码二维码	`/ios` `/android`
`/remote-control`	从 claude.ai 进行远程控制	`/rc`
`/remote-env`	配置默认远程环境	—
帮助与反馈
`/help`	显示帮助	—
`/btw <question>`	额外问题，不写入历史	—
`/feedback`	提交反馈	`/bug`
`/release-notes`	查看更新日志	—
`/passes`	分享一周免费 Claude Code 使用权	—
`/install-github-app`	配置 GitHub Actions app	—
`/install-slack-app`	安装 Slack app	—

内置 Skills：/batch（并行批量修改）、/debug（调试日志）、/loop（定时重复）、/simplify（代码质量审查）、/claude-api（API 参考）。调用方式和 slash command 一样。

已弃用命令：/review 已弃用，请改用 code-review 插件；/output-style 自 v2.1.73 起弃用；/fork 已更名为 /branch（别名仍可用，v2.1.77）；/vim 已移除，改用 /config → Editor mode。

版本演进

命令体系最近的变更——哪些命令变了、哪些是新加的

更名与弃用

/fork → 更名为 /branch，别名仍可用（v2.1.77）
/output-style → 自 v2.1.73 起弃用
/review → 已弃用，推荐改用 code-review 插件
/vim → 自 v2.1.92 起移除，改用 /config → Editor mode

新增命令

/goal — 设置完成条件，让 Claude 跨 turn 自走直到达成（自走模式）
/effort — 设置推理强度，max 级别需 Opus 4.6
/voice — 按住说话语音输入
/schedule — 创建和管理定时任务
/color — 自定义提示栏颜色

变更	版本	影响
新增 `/goal` 自走模式	v2.1.139	设置完成条件后跨 turn 持续工作，支持交互式、`-p` 与 Remote Control
`/model` 选择器显示可读标签	近期	现在显示 "Sonnet 4.6" 等人类可读名称
`/resume` 支持 `/continue` 别名	近期	恢复对话时可用更直觉的别名
MCP prompts 可作为命令使用	近期	格式为 `/mcp__server__prompt`

查看最新变化：在 Claude Code 中运行 /release-notes 可随时查看完整更新日志。

第一个命令

先做一个能跑起来的命令，再逐步加参数和安全边界

好，现在来动手。先不要上来就做 /commit 或 /push-all——那些太复杂。

我们第一步只追求一件事：命令能被 Claude Code 发现并执行。

# 文件：.claude/skills/explain-file/SKILL.md
---
name: explain-file
description: 用初学者能看懂的语言解释一个文件
---

请解释 $ARGUMENTS 这个文件。
先用一句话总结，再列出 3 个关键点。

输入

$ /explain-file src/auth.ts

输出

这个文件负责用户认证流程。

1. 它定义了登录和登出逻辑
2. 它会读取 token 并校验过期时间
3. 它向外暴露了当前登录状态

这个例子已经包含两个最重要的事实：name 决定命令名（会变成 /explain-file），正文决定 Claude 实际执行的提示词。

如果你在这一步发现命令找不到：大概率是文件路径不对。确认文件在 .claude/skills/explain-file/SKILL.md，并且 frontmatter 里 name 写的是 explain-file。改对了之后，重启 Claude Code 会话再试。

命令三要素

name、description 和正文——一个最小命令至少要有这三样

必须有的部分

name：决定会变成哪个 /命令名（省略时用目录名）
description：帮助 Claude 判断什么时候该自动用它
正文：真正的工作指令，写清楚干什么、怎么输出

为什么先只学这三个

足以做出第一个可运行结果
能先建立"命令文件 = 可执行工作流入口"的直觉
还不会把初学者拖进权限、脚本和复杂上下文里

---
name: explain-file
description: 用初学者能看懂的语言解释一个文件
---

请解释 $ARGUMENTS 这个文件。
先用一句话总结，再列出 3 个关键点。

现在停一下：把上面的命令名改成 summarize-note，并让它改为 "总结一个 Markdown 文档的核心结论"。不要往下看，先自己改一遍。

命令参数

用 $ARGUMENTS 和 $0 $1 让同一条命令接住不同输入

上一个命令很爽，但它有个问题：解释的文件名写死了。换个文件就得改命令内容，那又回到老路上了。

别急。接下来的问题就是：同一条命令，如何接受不同对象？这时候就该参数上场了。

# 用 $ARGUMENTS 接收全部参数（适合传给单个对象）
---
name: fix-issue
description: 根据编号修复一个 GitHub issue
---
按团队规范修复 issue #$ARGUMENTS

# 用 $0 和 $1 接收位置参数（适合参数角色不同）
---
name: review-pr
description: 按优先级审查 PR
argument-hint: "[PR编号] [优先级: low|medium|high]"
---
审查 PR #$0，最低报告级别是 $1

用 `$ARGUMENTS`

整段参数原样交给命令：文件名、issue 编号、自然语言补充说明。调用 /fix-issue 123 时 $ARGUMENTS 变成 123。

用 `$0`、`$1` ...

参数角色不同，必须分别解释。调用 /review-pr 456 high 时 $0="456"，$1="high"。

argument-hint：在 frontmatter 里写 argument-hint: "[severity: low|medium|high]"，输入 / 时会出现自动补全提示。

上下文注入

用 !`cmd` 让命令先读取环境状态，再替你做出判断

参数解决了"换对象"的问题，但还有一个更麻烦的事。你看——真正实用的命令，往往不是"写死一段话"，而是"先看看现在什么情况，再决定怎么做"。

比如 /commit：你得先知道当前改了什么文件、diff 长什么样、分支叫什么，才能生成靠谱的提交信息。这时候就要用 !`cmd` 注入动态上下文。

---
description: 创建带上下文的 Git 提交
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*)
argument-hint: [message]
---

## 上下文
- 当前 git 状态：!`git status`
- 当前 git diff：!`git diff HEAD`
- 当前分支：!`git branch --show-current`
- 最近提交：!`git log --oneline -10`

## 你的任务
根据上面的变更创建一个单独的 Git 提交。
若传入了 message 参数则直接使用：$ARGUMENTS
否则按 conventional commits 格式生成提交信息。

没有上下文注入

Claude 不知道你改了什么
commit message 只能靠你手动解释
结果风格容易飘

有上下文注入

命令能直接看到当前 diff 和 git 状态
提示词和仓库状态自动绑定
更适合做成团队标准流程

别忘了 allowed-tools：用了 !`git ...` 就得在 frontmatter 中声明 allowed-tools: Bash(git *)，否则命令执行时会因权限不足而失败。

文件引用

用 @ 引用文件内容，省去手动复制粘贴

!`cmd` 适合"会变的东西"——git 状态、环境变量、构建输出。但有时候你需要的是"一个文件的内容本身"——源码、配置、文档。这些相对固定的内容，用 @ 更直接。

审查 @src/utils/helpers.js 中的实现。
比较 @src/old-version.js 和 @src/new-version.js。
参考 @package.json 中的依赖版本。

# 也支持 glob 模式
检查 @src/**/*.ts 中是否有未处理的 Promise。

适合 !`cmd`

需要运行时状态：git 状态、当前分支、环境变量、构建输出等会变化的信息。

适合 `@path`

需要文件内容本身：源码、配置、文档等相对静态的内容。支持 glob 批量引用。

组合使用：真正实用的命令往往两者都用——!`git diff --name-only` 找出变更的文件名，再用 @ 引用这些文件的完整内容做审查。

字段参考

SKILL.md Frontmatter 完整字段一览

以下是 SKILL.md 中可用的全部 frontmatter 字段。先掌握前三行，其余的按需取用。

字段	作用	默认值
`name`	命令名（变成 `/name`）	目录名
`description`	简短说明，帮助 Claude 判断何时自动调用	正文首段
`argument-hint`	`/` 菜单中的参数补全提示	无
`allowed-tools`	命令可无权限使用的工具，逗号分隔	继承
`model`	指定要使用的模型	继承
`disable-model-invocation`	`true` 时仅用户可调用，Claude 不自动触发	`false`
`user-invocable`	`false` 时不出现在 `/` 菜单	`true`
`context`	设为 `fork` 时在隔离 subagent 中运行	无
`agent`	`context: fork` 时使用的 agent 类型	`general-purpose`
`hooks`	Skill 级别的 hooks（PreToolUse、PostToolUse、Stop）	无

先收在这里：context: fork、agent、hooks 属于进阶话题，应该放到后续 Skill 章节，而不是塞进这一章。

命令放哪里

.claude/skills/ vs .claude/commands/ — 为什么现在推荐 Skills

现在你已经会写命令了。但写好的文件放哪里，Claude Code 才能找到它？换句话说：你把命令存在哪个目录？

project/
└── .claude/
    ├── commands/          [旧式写法，仍可用]
    │   └── optimize.md
    └── skills/            [当前推荐]
        ├── commit/
        │   └── SKILL.md
        └── pr/
            └── SKILL.md

位置	作用范围	适合什么场景
`.claude/skills/`	项目级	团队共用工作流，跟仓库一起版本化
`~/.claude/skills/`	个人级	你自己常用，但不想跟项目绑定的命令
`.claude/commands/`	兼容旧写法	已有存量命令还在继续跑；新命令建议迁移到 skills

为什么推荐 Skills

目录结构：脚本、模板、参考文件可打包在一起
渐进披露：只在需要时加载额外文件
自动触发：相关场景下 Claude 可自动调用
调用控制：可决定由用户、Claude 或两者共同调用
子 agent 执行：可在隔离上下文中运行 skill
优先级：同名时 Skill 覆盖旧式 command

安装命令

# 推荐：安装为 Skill
mkdir -p .claude/skills/commit
cp commit.md .claude/skills/commit/SKILL.md

# 兼容：安装为旧式命令
mkdir -p .claude/commands
cp optimize.md .claude/commands/

迁移前（旧式 Command）

.claude/commands/optimize.md

单个 Markdown 文件，直接放在 commands 目录。

迁移后（Skill）

.claude/skills/optimize/SKILL.md

打包进独立目录，可附带脚本、模板等资源文件。同名时 Skill 优先。

迁移很简单：旧的 .claude/commands/ 文件可以继续直接使用，无需立即迁移。新建命令建议直接放在 .claude/skills/ 下。

执行流水线

`/commit` 背后发生了什么：从输入到输出的完整流程

这张图在解释什么

你可以把 Slash Command 想象成一台自动售货机：你按下 B3（输入 /commit），机器内部的一系列齿轮就开始转动——先找到对应的商品（定位文件），读取配料表（解析 frontmatter），注入实时信息（替换变量），最后把成品送到你手上。

这个比喻只是为了帮你建立直观感受。实际上，Slash Command 并不是什么"黑盒机器"——它做的事情本质上就是文件解析 + 变量替换 + 上下文注入 + 模型执行。大多数行为仍然来自你写进文件里的说明和注入进去的环境信息，没有魔法。

关键细节

Skill 和旧式 command 的解析顺序：先查 skills 目录，再查 commands 目录。如果两边有同名文件，Skill 优先。

生命周期

从用户输入到返回结果——一次命令调用的完整序列

序列的关键节点

文件搜索：先查 .claude/skills/，再查 .claude/commands/，Skill 优先
Frontmatter 解析：提取 name、description、allowed-tools 等元数据
Shell 命令执行：先运行 !`cmd`，将输出注入上下文
变量替换：将 $ARGUMENTS、$0、$1 替换为实际值
提示词组装：上下文 + 正文 + 参数合成为完整 prompt

与执行流水线的区别

上一张"执行流水线"关注的是单条命令内部的数据变换（输入 → 定位 → 解析 → 替换 → 拼接 → 输出）。

这张"生命周期"关注的是多个参与者之间的协作顺序——谁在什么时候做了什么，信息是如何在用户、Claude Code、文件系统和 Shell 之间流转的。

解析流程

内置 → Skill → Command → 插件/MCP：四种入口，一条流水线

命令类型	格式	示例
内置命令	`/command`	`/help` `/clear`
Skill	`/skill-name`	`/commit` `/pr`
旧式 command	`/command-name`	`/optimize`
插件命令	`/plugin:command`	`/frontend-design:frontend-design`
MCP prompt	`/mcp__server__prompt`	`/mcp__github__list_prs`

MCP 权限语法：在权限中控制 MCP 访问 — mcp__github（整个 server）、mcp__github__*（全部工具）、mcp__github__get_issue（单个工具）。

插件与MCP

两种外部命令入口：插件命令和 MCP prompts

插件命令

插件可以提供自定义命令，格式为 /plugin-name:command-name。

# 完整格式（总有命名空间）
/frontend-design:frontend-design
/commit-commands:commit

# 无冲突时可直接使用
/commit   ← 如果只有 commit-commands 提供了 /commit

安装插件后用 /reload-plugins 刷新，输入 / 即可看到新增命令。

MCP Prompts

MCP servers 可以把 prompt 暴露成 slash command，格式为 /mcp__server__prompt。

# 列出 GitHub PR
/mcp__github__list_prs

# 审查指定 PR
/mcp__github__pr_review 456

# 创建 Jira Issue
/mcp__jira__create_issue "Bug title" high

用 /mcp 管理 servers，支持 OAuth 认证。

插件命令的关键特性

命名空间隔离：plugin-name: 前缀防止冲突
无冲突简写：只有一个插件提供该命令时可省略前缀
用 /plugin 管理已安装插件
用 /reload-plugins 热重载

MCP 命令的权限控制

mcp__github — 访问整个 GitHub MCP server
mcp__github__* — 通配符访问全部工具
mcp__github__get_issue — 访问某个特定工具
在 /permissions 中统一管理

四种模式

分析、流程、上下文、安全——本章示例库的四种命令模式

这四种模式对应一条递进的学习曲线：从纯文本封装，到参数化，再到读环境，最后到安全防护。

`/optimize` — 分析模板

展示"分析类命令"的写法：强调输出结构、问题分级和修复建议。

纯提示词封装

`/pr` — 流程模板

展示"流程清单类命令"的写法：把顺序、检查项和结果摘要写死。

流程清单

`/commit` — 上下文模板

展示"上下文注入类命令"的写法：读取 git 状态后生成更稳的提交信息。

上下文注入

`/push-all` — 安全模板

展示"高副作用命令"的写法：执行前做安全检查、展示摘要、要求用户确认。

安全防护

换个角度看：从"纯文本"→"参数化"→"读取环境"→"带风险控制的自动化"，就是你这一章应该掌握的递进关系。

安全设计

深入 `/push-all`：把安全检查写进命令本身

高副作用的命令（提交、推送、部署），必须把"先检查、再确认、后执行"写进命令本身。

必须拦截的危险项

密钥文件：.env*、*.key、*.pem、credentials.json
真实 API Key：sk-proj-xxx、AKIA...、sk_live_...
大文件：>10MB 且未使用 Git LFS
构建产物：node_modules/、dist/、__pycache__/
临时文件：.DS_Store、*.swp、*.tmp

安全流程三步

分析变更：并行运行 git status、git diff --stat、git log -1
展示摘要 + 请求确认：列出变更文件数、行数、安全检查结果
逐个执行：git add → git status（验证）→ git commit → git push

关键防线：对高副作用命令设置 disable-model-invocation: true，确保只有用户主动输入 /push-all 时才会执行，Claude 不会在任何对话中自动触发它。

出错时怎么办

git add 失败：检查权限、锁定文件，确认仓库已初始化
git commit 失败：修复 pre-commit hooks，检查 git 配置（user.name/email）
git push 失败：非快进时 git pull --rebase && git push；无远程分支时 git push -u origin [branch]

什么时候不该用

不确定要提交哪些内容时
包含 secrets 或敏感数据时
受保护分支且未经过审核时
想保留更细粒度的提交历史时

替代方案：拿不准时，用 git add -p 逐块选择，或走 PR 工作流（创建分支 → 推送 → 发起 PR，可以用 /pr 命令）。

排错指南

常见错误诊断与修复方案

找不到命令

原因：文件路径不对，name 跟预期不一致，或会话缓存未刷新。

修复：确认文件位于 .claude/skills/<name>/SKILL.md 或 .claude/commands/<name>.md；重开 Claude Code 会话；运行 /help 查看可用命令。

命令能触发，但结果很空或跑偏

原因：description 太模糊，正文没有明确输出格式和成功标准。

修复：把 "做点 review" 改成 "按严重程度列出问题，每条包含文件路径、问题描述、风险说明、修复建议"。在正文中写清输出格式。

命令要读 git / 跑 shell，但读不到

原因：缺少 allowed-tools 声明，或 shell 命令写法不对。

修复：在 frontmatter 中补上 allowed-tools: Bash(git *)；确认 !`cmd` 用的是反引号而非单引号。

Skill 和 command 同名冲突

原因：同时存在 .claude/skills/review/SKILL.md 和 .claude/commands/review.md。

修复：Skill 优先。删除不需要的那个，或重命名其中一个。

命令能触发，但输出不符合预期

原因：正文指令不够具体，缺少输出格式和成功标准。

修复：在命令正文中加入示例输出；拆分复杂步骤为带编号的子任务；用简单输入先测试一遍。

快速自检清单：路径对了吗？frontmatter 中 name 跟预期一致吗？命令有副作用时是否设置了 allowed-tools？正文是否指定了输出格式？shell 命令是否用了反引号？

最佳实践

写命令时容易忽略的事——一张表帮你避开常见坑

应该做	不要做
使用清晰、以动作导向的命名	为一次性任务创建命令
在 `description` 中写清触发条件	在命令里写太复杂的逻辑
保持命令聚焦于单一任务	硬编码敏感信息
有副作用时使用 `disable-model-invocation`	跳过 `description` 字段
用 !`cmd` 注入动态上下文	假设 Claude 知道当前状态
把相关文件组织进 skill 目录	所有内容都塞进一个文件

判断标准：一个操作如果你一周内重复了 3 次以上，它就值得被写成一条命令。但不要把"偶尔做一次的事"也写成命令——那只会增加维护负担。

动手练习

自己做一个 `/code-review` 命令

读到这里，你已经掌握了命令的骨架。停下来，自己动手做一遍——只有自己敲出来的命令，才是你的。

练习 1：最小版本

让命令自动读取当前分支相对于 main 的 diff
至少从代码质量、安全性、可维护性三个维度审查
输出必须按严重程度排序

练习 2：加参数

增加一个 severity 参数
支持 low、medium、high
思考：这个命令是否需要 disable-model-invocation？

提示：从最小骨架开始，先只写 name + description + 正文。跑通之后再逐步加 $ARGUMENTS、!`git diff main...HEAD` 和 allowed-tools。不要一口气把所有能力写进去。

参考答案

一种可参考的 code-review 命令写法

# 文件：.claude/skills/code-review/SKILL.md
---
name: code-review
description: 对当前分支的改动进行结构化代码审查
argument-hint: "[severity: low|medium|high]"
allowed-tools: Bash(git *), Read, Grep
---

## 上下文
- 当前分支：!`git branch --show-current`
- 变更统计：!`git diff main...HEAD --stat`
- 完整 diff：!`git diff main...HEAD`
- 最近提交：!`git log --oneline -10`

## 任务
审查以上改动，最低报告级别是 $ARGUMENTS，默认按 medium 处理。

## 审查维度
1. 代码质量
2. 安全性
3. 可维护性

## 输出格式
按严重程度列出发现，每条包含：
- 文件路径
- 问题描述
- 风险说明
- 修复建议

别直接照抄：真正重要的不是这段文本，而是你能不能解释清楚每一块为什么存在。尤其是 allowed-tools（没有它读不到 git 信息）和 ## 输出格式（没有它 Claude 不知道你想要什么结构）。

自走模式

`/goal`——内置命令里的高级工作流：给一个完成条件，Claude 跨 turn 自走直到达成

前面讲的命令，无论内置还是自定义，都是"敲一下、做一步"——你每次都得回来催下一轮。/goal 是个例外：它是内置命令里的自走模式，给一个完成条件，Claude 就会自己一轮轮跑下去，不用你守着。

它怎么知道做完了

每完成一个 turn，一个独立的轻量评估模型（默认 Claude Haiku）会判定你的条件是否成立：

不成立 → 评估器给出简短原因，Claude 接着跑下一个 turn
成立 → goal 自动清除，Claude 把控制权交还给你

关键在于：判定的人不是干活的人。这就是它和"让 Claude 自己判断做没做完"的根本区别——完成与否由一个独立的模型重新裁决，而不是让正在工作的那个模型自己说了算。

三种用法，都是 `/goal`

# 设置目标（设置后立即开始一个 turn）
/goal all tests in test/auth pass and the lint step is clean

# 查看状态（条件、运行时长、已评估 turn 数、token 花费、最近原因）
/goal

# 提前清除（stop / off / reset / none / cancel 都是别名）
/goal clear

同一会话只能有一个活动 goal。设置新的会替换旧的；状态栏会显示 ◎ /goal active 表示正在自走。

写好条件的三原则

评估器只读对话记录，不会自己跑命令或读文件。所以条件要写成"Claude 的输出能证明的东西"——"所有测试通过"之所以有效，是因为 Claude 会去跑测试，结果会落到对话里让评估器读到。

原则	说明	示例
一个可测量终态	测试结果、构建退出码、文件数、空队列	`npm test exits 0`
一个明确检查	写清怎么证明，别留给评估器猜	`git status is clean`
关键约束	过程中不许动的东西	`no other test file is modified`

条件最多 4000 字符。想限制时长，加个 turn 或时间子句：... or stop after 20 turns。

和 `/loop`、Stop hook、Auto mode 的区别

这四个都能让会话在 prompt 之间继续跑，但触发下一个 turn 的时机和停止条件不同：

方式	下个 turn 何时开始	何时停止
`/goal`	上一个 turn 结束后	评估模型确认条件满足
`/loop`	时间间隔流逝后	你停止它，或 Claude 判断完成
Stop hook	上一个 turn 结束后	你的脚本或 prompt 决定
Auto mode	不开始新 turn（只在单 turn 内免确认工具）	Claude 判断本 turn 工作完成

它们也可以互补：Auto mode 免掉单 turn 内的工具确认，/goal 免掉每 turn 的提示。

适合 /goal 的场景：把模块迁移到新 API 直到所有调用点都能编译且测试通过、实现设计文档直到所有验收标准成立、把大文件拆成聚焦小模块直到每个低于尺寸预算、清空一个 issue backlog 队列。共同点是：有可验证的终态。

别忘加边界：条件里务必加 turn 或时间上限（如 stop after 20 turns）。否则一旦评估器持续判"没完成"，会一直烧 token 直到周额度耗尽。

本章回顾

把经验收成命令，然后继续往前

到这里，你已经能

分清内置命令、Skill、旧式 command、插件命令、MCP prompts
写出一个最小可运行的 Skill 命令
用 $ARGUMENTS 和 $0 $1 给命令加参数
用 !`cmd` 注入动态上下文，用 @path 引用文件
为高副作用命令添加安全检查和确认机制
诊断命令找不到、结果空、权限不足等常见问题

它和后面几章的关系

Slash Commands 负责"怎么触发一个工作流"
Memory 负责"默认遵守哪些长期规则"
Skills 负责"把工作流升级成能力包"
Subagents 负责"把工作分给谁做"

核心结论：Slash command 的本质不是"省几次输入"，而是把零散经验压缩成稳定流程。你写下的每一条命令，都是未来自己和团队少踩一次坑的机会。

别小看这一步。你今天封装的第一个 /code-review，可能就是明天团队新同事少走三天弯路的起点。

延伸阅读

继续本课程

下一章：Skills — 把命令打包成带脚本和模板的目录化能力包
Memory — 用 CLAUDE.md 设定长期生效的默认规则
Subagents — 委派式 AI agents
Plugins — 打包好的命令集合
Hooks — 事件驱动自动化

官方文档

Interactive Mode 文档 — 内置命令完整参考
Skills 文档 — references、assets、自动触发等进阶用法
CLI Reference — 命令行选项参考

本章源文件

README.md — 完整的命令参考指南
01-slash-commands/ 目录 — 所有示例命令的源文件

Slash Commands

重复的对话

你有没有发现，每天都在对 Claude Code 说几乎一样的话？

每次提交代码

每次审查代码

每次准备 PR

开始之前

适合谁

读完后你应该已经能

这些内容暂时先不碰

重复变命令

把"我每次都要重复说一遍"的操作，变成"以后只要输入一条命令"

学之前，常见困难

学之后，可以直接做到

四类命令

Slash Command 就是你在 Claude Code 里敲 / 开头的东西。说白了，它就是一个快捷方式的入口——你敲一个 /命令名，Claude Code 就去执行一段预设好的操作。

内置命令

Skills（推荐）

旧式 command（仍可用）

插件与 MCP prompts

内置命令速查

版本演进

命令体系最近的变更——哪些命令变了、哪些是新加的

更名与弃用

新增命令

第一个命令

先做一个能跑起来的命令，再逐步加参数和安全边界

输入

输出

命令三要素

name、description 和正文——一个最小命令至少要有这三样

必须有的部分

为什么先只学这三个

命令参数

用 $ARGUMENTS 和 $0 $1 让同一条命令接住不同输入

用 $ARGUMENTS

用 $0、$1 ...

上下文注入

用 !`cmd` 让命令先读取环境状态，再替你做出判断

没有上下文注入

有上下文注入

文件引用

用 @ 引用文件内容，省去手动复制粘贴

适合 !`cmd`

适合 @path

字段参考

SKILL.md Frontmatter 完整字段一览

命令放哪里

.claude/skills/ vs .claude/commands/ — 为什么现在推荐 Skills

为什么推荐 Skills

安装命令

迁移前（旧式 Command）

迁移后（Skill）

执行流水线

/commit 背后发生了什么：从输入到输出的完整流程

这张图在解释什么

关键细节

生命周期

从用户输入到返回结果——一次命令调用的完整序列

序列的关键节点

与执行流水线的区别

解析流程

内置 → Skill → Command → 插件/MCP：四种入口，一条流水线

插件与MCP

两种外部命令入口：插件命令和 MCP prompts

插件命令

MCP Prompts

插件命令的关键特性

MCP 命令的权限控制

四种模式

分析、流程、上下文、安全——本章示例库的四种命令模式

/optimize — 分析模板

/pr — 流程模板

/commit — 上下文模板

/push-all — 安全模板

安全设计

深入 /push-all：把安全检查写进命令本身

必须拦截的危险项

安全流程三步

出错时怎么办

Slash Command 就是你在 Claude Code 里敲 `/` 开头的东西。说白了，它就是一个快捷方式的入口——你敲一个 `/命令名`，Claude Code 就去执行一段预设好的操作。

用 `$ARGUMENTS`

用 `$0`、`$1` ...

适合 `@path`

`/commit` 背后发生了什么：从输入到输出的完整流程

`/optimize` — 分析模板

`/pr` — 流程模板

`/commit` — 上下文模板

`/push-all` — 安全模板

深入 `/push-all`：把安全检查写进命令本身

自己做一个 `/code-review` 命令

`/optimize` — 代码优化

`/pr` — PR 准备

`/generate-api-docs`

`/commit` — 带上下文的提交

`/push-all` — 安全推送

`/unit-test-expand`

`/setup-ci-cd`

`/doc-refactor`

自定义命令文件（点击文件名查看命令定义）

`/goal`——内置命令里的高级工作流：给一个完成条件，Claude 跨 turn 自走直到达成

三种用法，都是 `/goal`

和 `/loop`、Stop hook、Auto mode 的区别