Claude Code 自定义斜杠命令入门：把 /review、/handoff、/release 变成团队规范

你又一次复制同一份代码审查清单。发布前还要临时回忆 release 步骤。Claude Code 会话很长时，最后仍然要手写“改了什么、验证了什么、还有什么风险”。团队越依赖 AI 编程代理，这些重复的小动作就越应该沉淀成流程。

自定义斜杠命令可以把重复提示词变成团队都认识的短名字。/review、/handoff、/release 不只是快捷方式。设计得好，它们会变成团队共同的工作标准：怎样审查代码，怎样交接上下文，怎样判断是否可以发布。

本文按照 2026 年 6 月 3 日确认过的 Claude Code Skills 官方文档 和 Commands 参考 编写。关键变化是：自定义命令已经并入 Skills。已有的 .claude/commands/*.md 仍然有效，但新的团队流程通常更适合放在 .claude/skills/<name>/SKILL.md。

核心理解：命令是可复用的工作流程

在 Claude Code 中，命令是在会话里以 / 开头的消息。官方参考说明，命令必须出现在消息开头，命令名后面的文字会作为参数传入。所以 /release 1.8.0 可以把 1.8.0 当作版本号，/handoff frontend reviewer 可以说明交接笔记写给谁。

Skill 可以理解为 Claude 的可复用说明包。更直白地说，它是一份小型操作手册：什么时候用、按什么步骤做、哪些输入重要、输出应该长什么样。旧的 .claude/commands/ 文件继续可用，但 Skills 支持目录结构、frontmatter、辅助文件、命名参数，也更适合代码审查。

首先要注意命名冲突。当前 Claude Code 可能已经有 /review、/code-review、/security-review 等内置或捆绑命令。创建自己的 /review 之前，先在 Claude Code 中输入 / 查看菜单。如果名称已存在，就改用 /team-review、/review-note 等团队专用名字。本文讨论的是 review 这个模式，实际名称要以你的环境为准。

文件布局：优先使用 Skills，Commands 用于兼容

团队规则应该放在项目中，而不是某个人的 home 目录里。项目级 Skill 可以提交到 Git、通过 pull request 审查，并随着仓库一起演进。个人 Skill 适合私人习惯，但不适合承载全队依赖的规则。

位置	示例	适合场景
项目 Skill	.claude/skills/team-review/SKILL.md	团队审查、发布准备、调查、入职流程
项目 Command	.claude/commands/handoff.md	已有轻量命令，或迁移期间的兼容层
个人 Skill	~/.claude/skills/my-note/SKILL.md	个人笔记和私有日常流程
个人 Command	~/.claude/commands/my-command.md	临时个人快捷方式

一个清晰的仓库结构可以这样设计：

.claude/
├── commands/
│   └── handoff.md
└── skills/
    ├── team-review/
    │   ├── SKILL.md
    │   └── checklists/
    │       └── review.md
    └── release-prep/
        ├── SKILL.md
        └── scripts/
            └── collect-release-notes.sh

它的思路很简单：仓库保存团队流程，/ 菜单把流程暴露成命令，用户传入参数，Claude Code 再把说明和当前任务上下文结合起来。

flowchart LR
  A[".claude/skills 或 .claude/commands"] --> B["例如 /team-review 的命令"]
  B --> C["参数：$ARGUMENTS 或 $version"]
  C --> D["Claude Code 加载说明"]
  D --> E["Review、handoff 或 release 准备"]
  E --> F["人类检查并决定是否合并或发布"]

新增或修改 Skill 后，先确认它是否出现在 / 菜单里。如果当前会话没有识别到，可以运行 /reload-skills，或者重新打开 Claude Code 会话。描述字段也要检查，因为它会影响团队成员是否能发现这个 workflow。

可直接复制的起步模板

先从小模板开始。下面创建 /team-review，避免和可能存在的内置 /review 冲突。

mkdir -p .claude/skills/team-review
cat > .claude/skills/team-review/SKILL.md <<'EOF'
---
description: Review the current change with the team's checklist before a pull request or merge.
argument-hint: [target-branch-or-path]
disable-model-invocation: true
---

You are performing a read-only team review.

Target: $ARGUMENTS

If the target is empty, ask which diff, branch, or path to review before scanning broadly.
Do not edit files.
Do not run destructive commands.

Review from these perspectives:
1. Correctness bugs and edge cases
2. Security and privacy risks
3. Test coverage and missing verification
4. Consistency with existing code patterns
5. Documentation, migration notes, and user-facing copy

Output:
- Findings first, ordered by severity
- File path and line number when available
- One short suggestion for each issue
- "No blocking findings" only if you found none
EOF

之后可以用 /team-review main、/team-review src/auth 这类目标来调用。disable-model-invocation: true 会阻止 Claude 自动选择这个 Skill。对于 review 和 release 这类控制点，最好由人明确触发，而不是让模型自动启动。

用例 1：把 /review 固定为团队审查清单

Review 命令的价值在于一致性。没有共同清单时，有人主要看命名，有人看安全，有人看测试。命令应该定义严重级别、范围和输出格式，让 Claude 和人类按照同一套标准审查。

如果你的环境已经有 /review，就使用 team-review.md 或 team-review Skill。如果没有冲突，.claude/commands/review.md 仍然可以创建 /review。

---
description: Team review checklist for the current branch or specified path.
argument-hint: [branch-or-path]
disable-model-invocation: true
---

Review target: $ARGUMENTS

Read the diff or files related to the target and report only review findings.
Do not rewrite code unless the user asks for fixes after the review.

Severity:
- P0: data loss, auth bypass, secret leak, production outage
- P1: correctness bug, missing validation, broken user flow
- P2: maintainability, unclear naming, duplicated logic
- P3: optional cleanup

Required checks:
1. Is the change scoped to the request?
2. Are tests or manual verification enough for the risk?
3. Are error paths and empty states handled?
4. Does the code follow existing local patterns?
5. Could the change break monetization links, analytics, or release notes?

Return a short summary after the findings.

最关键的是 “Do not rewrite code”。如果 review 命令悄悄修改文件，它就不再是审查，而变成实现任务。建议第一轮只读，确认 findings 后再单独启动修复任务。

用例 2：用 /handoff 交接给下一个人或代理

长会话最容易丢失的是结尾上下文。/handoff 可以把任务收尾变成结构化笔记，交给明天的自己、队友或另一个代理继续。

---
description: Create a concise handoff note for the current task.
argument-hint: [next-owner-or-audience]
disable-model-invocation: true
---

Create a handoff note for: $ARGUMENTS

Include these sections:
1. Goal: what the task was trying to achieve
2. Changed files: important files and why they changed
3. Decisions: tradeoffs or assumptions made during the work
4. Verification: commands run, screenshots checked, or checks not run
5. Risks: unresolved issues, fragile areas, or things needing human review
6. Next steps: the smallest useful next action

Keep it factual. Do not hide failed attempts. If something was not verified, say so clearly.

这对变现内容站和生产应用尤其有用。内部链接、CTA、埋点事件、截图、人工检查都容易在多文件任务中被忘掉。handoff 命令能把这些细节重新摆到台面上。

用例 3：用 /release 做发布准备，而不是发布

Release 命令要保守。目标不是让 Claude 直接替你发布，而是收集上下文、草拟变更说明、列出阻塞项，并把最终决定留给人。

下面的模板使用命名参数。当前文档说明，arguments 会把名称映射到位置参数，因此第一个参数会成为 $version。

---
description: Prepare a release checklist and changelog draft without publishing.
argument-hint: [version]
arguments: [version]
disable-model-invocation: true
---

Prepare release $version.

Allowed work:
1. Inspect the current diff, package metadata, and changelog
2. Draft a changelog section for $version
3. Suggest verification commands
4. List release blockers and rollback notes
5. Propose a commit message

Safety rules:
- Do not run git push
- Do not publish packages
- Do not deploy to production
- Do not delete files
- Ask before changing version files

Output:
- Release summary
- Checklist
- Blockers
- Commands the user should run manually

这是 release-prep 命令，不是发布按钮。如果团队最终要自动发布，应放在 CI/CD 中处理，并配好审批、日志和回滚规则。

参数：先从 $ARGUMENTS 开始

大多数自定义命令只需要 $ARGUMENTS。/handoff backend reviewer 会把 backend reviewer 放进 $ARGUMENTS。当前文档还支持 $ARGUMENTS[0]、$0，以及在 frontmatter 中声明的 $issue、$branch 这类命名参数。

---
description: Prepare an issue-specific work plan.
argument-hint: [issue] [branch]
arguments: [issue, branch]
disable-model-invocation: true
---

Issue: $issue
Branch: $branch
All arguments: $ARGUMENTS

Create a plan that:
1. Restates the issue in plain language
2. Lists files to inspect first
3. Identifies likely tests
4. Names one thing that should not be changed

多词参数要用引号包起来，例如 /plan-issue "login redirect bug" fix-login。如果看到旧示例说 $1 是第一个参数，要和当前文档核对。当前文档把 $0 描述为第一个位置参数的简写。

版本管理和审查流程

把项目 Skills 和 Commands 当作代码来管理。它们会影响团队看什么、漏什么、把什么算作“完成”。.claude/skills/release-prep/SKILL.md 的修改应该出现在 pull request 中，而不是藏在一个无关功能分支里。

规则	目的
把 .claude/skills/ 纳入 Git	保留谁在什么时候改了流程
允许只改命令的 PR	不让流程变更混进应用代码
在 README 或 CLAUDE.md 列出命令	方便新人发现
在提示词中禁止破坏性操作	避免误 push、publish、deploy 或删除
每月清理一次命令列表	删除过期流程，减少误用

做团队导入时，可以配合阅读 Claude Code 入门指南、CLAUDE.md 最佳实践 和 Claude Code Hooks 指南。

常见坑和安全注意

最大的误区是：因为命令很短，就以为它天然安全。它仍然是一个强提示词。如果使用带 ! 反引号的动态上下文注入，Claude Code 会先运行 shell 命令，再把输出插入 Skill 内容中。这很方便，但必须限制为只读。

---
description: Collect read-only git context for release notes.
disable-model-invocation: true
---

Current status:
!`git status --short`

Recent commits:
!`git log --oneline -20`

Summarize the release notes from the information above.
Do not run write operations.

这类命令只应包含 git status、git log 这样的安全检查。不要放入 rm、git clean、git push、npm publish、curl ... | sh 或影响生产环境的脚本。allowed-tools 也要小心，过宽的 Bash 权限会减少确认提示，可能超出团队预期。先从只读工具开始，确实需要时再逐项增加权限。

具体失败例很常见：自定义 /review 和内置命令冲突；命令只存在于某个人的 home 目录；Skill 正文太长，每次加载都浪费上下文；参数为空却让 Claude 扫描整个仓库；release 命令包含发布动作。它们都来自“想更方便一点”。先只读、目标小、保留人工确认，才是更稳的设计。

CTA：把模板变成你的团队操作系统

这些模板只有贴合你的仓库才真正有价值。个人使用可以先从 Claude Code 免费速查表 开始，把安全命令模式放在手边。需要可复用的 review、release、handoff 模板时，可以查看 ClaudeCodeLab 产品。如果团队要一起设计权限、CLAUDE.md、Skill 审查、CI 边界和 onboarding，可以使用 Claude Code 培训与咨询。

在 Masa 的流程中实际尝试后，结论很明确：三个命令就足够稳定。/team-review、/handoff、/release-prep 覆盖了大部分重复工作，又没有把 Claude Code 变成危险的部署工具。最大的改进来自把 /release 定义为“收集证据，辅助人类决策”的命令，而不是“直接发布”的命令。自定义斜杠命令最适合用来让团队按同一标准停下来、检查清楚、再交接下去。