⚡

命令开发Skill command-development

这个skill提供关于如何在Claude Code中创建和管理斜杠命令的详细指南，包括命令结构、YAML frontmatter配置、动态参数、文件引用、Bash命令执行以及命令的最佳实践和模式。

DevOps 0 次安装 0 次浏览 更新于 3/1/2026

命令开发 for Claude Code

概览

斜杠命令是在交互会话中由Claude执行的常用提示，定义为Markdown文件。理解命令结构、frontmatter选项和动态特性可以创建强大、可重用的流程。

关键概念：

  • 命令的Markdown文件格式
  • 配置的YAML frontmatter
  • 动态参数和文件引用
  • Bash执行上下文
  • 命令组织和命名空间

命令基础

什么是斜杠命令？

斜杠命令是一个包含提示的Markdown文件，当被调用时，Claude执行该命令。命令提供：

  • 可重用性：一次定义，重复使用
  • 一致性：标准化常见工作流程
  • 共享：在团队或项目间分发
  • 效率：快速访问复杂提示

重要：命令是给Claude的指令

命令是为代理消费而写的，不是给人消费的。

当用户调用 /command-name 时，命令内容成为Claude的指令。写命令时，作为对Claude的指令，告诉它做什么，而不是作为给用户的消息。

正确方法（给Claude的指令）：

审查此代码以查找安全漏洞，包括：
- SQL注入
- XSS攻击
- 认证问题

提供具体的行号和严重性等级。

错误方法（给用户的消息）：

此命令将审查您的代码以查找安全问题。
您将收到包含漏洞详情的报告。

第一个示例告诉Claude做什么。第二个告诉用户将发生什么，但没有指导Claude。始终使用第一种方法。

命令位置

项目命令（与团队共享）：

  • 位置：.claude/commands/
  • 范围：在特定项目中可用
  • 标签：在 /help 中显示为 “（项目）”
  • 用途：团队工作流程，项目特定任务

个人命令（到处可用）：

  • 位置：~/.claude/commands/
  • 范围：在所有项目中可用
  • 标签：在 /help 中显示为 “（用户）”
  • 用途：个人工作流程，跨项目实用工具

插件命令（与插件捆绑）：

  • 位置：plugin-name/commands/
  • 范围：插件安装时可用
  • 标签：在 /help 中显示为 “（插件名）”
  • 用途：插件特定功能

文件格式

基本结构

命令是带有.md扩展名的Markdown文件：

.claude/commands/
├── review.md           # /review命令
├── test.md             # /test命令
└── deploy.md           # /deploy命令

简单命令：

审查此代码以查找安全漏洞，包括：
- SQL注入
- XSS攻击
- 认证绕过
- 不安全数据处理

基本命令不需要frontmatter。

带有YAML Frontmatter

使用YAML frontmatter添加配置：

---
description: 审查代码以查找安全问题
allowed-tools: 读取，Grep，Bash(git:*)
model: sonnet
---

审查此代码以查找安全漏洞...

YAML Frontmatter字段

description

目的： 在 /help 中显示的简短描述 类型： 字符串 默认值： 命令提示的第一行

---
description: 审查拉取请求以查找代码质量
---

最佳实践： 清晰、可操作的描述（少于60个字符）

allowed-tools

目的： 指定命令可以使用的工具 类型： 字符串或数组 默认值： 从对话中继承

---
allowed-tools: 读取，写入，编辑，Bash(git:*)
---

模式：

  • 读取，写入，编辑 - 特定工具
  • Bash(git:*) - 仅限git命令的Bash
  • * - 所有工具（很少需要）

使用时： 命令需要特定工具访问

model

目的： 指定命令执行的模型 类型： 字符串（sonnet, opus, haiku） 默认值： 从对话中继承

---
model: haiku
---

用例：

  • haiku - 快速，简单命令
  • sonnet - 标准工作流程
  • opus - 复杂分析

argument-hint

目的： 为自动完成记录预期参数 类型： 字符串 默认值： 无

---
argument-hint: [pr-number] [priority] [assignee]
---

好处：

  • 帮助用户理解命令参数
  • 提高命令发现性
  • 文档化命令接口

disable-model-invocation

目的： 阻止SlashCommand工具以编程方式调用命令 类型： 布尔值 默认值： false

---
disable-model-invocation: true
---

使用时： 命令应仅手动调用

动态参数

使用 $ARGUMENTS

将所有参数捕获为单个字符串：

---
description: 按编号修复问题
argument-hint: [issue-number]
---

修复问题 #$ARGUMENTS 遵循我们的编码标准和最佳实践。

用法：

> /fix-issue 123
> /fix-issue 456

扩展为：

修复问题 #123 遵循我们的编码标准...
修复问题 #456 遵循我们的编码标准...

使用位置参数

使用 $1, $2, $3 等捕获个别参数：

---
description: 审查优先级和被分配人的PR
argument-hint: [pr-number] [priority] [assignee]
---

审查拉取请求 #$1 优先级为 $2 。
审查后，分配给 $3 跟进。

用法：

> /review-pr 123 high alice

扩展为：

审查拉取请求 #123 优先级为 high 。
审查后，分配给 alice 跟进。

结合参数

混合位置和剩余参数：

部署 $1 到 $2 环境，选项：$3

用法：

> /deploy api staging --force --skip-tests

扩展为：

部署 api 到 staging 环境，选项：--force --skip-tests

文件引用

使用 @ 语法

在命令中包含文件内容：

---
description: 审查特定文件
argument-hint: [file-path]
---

审查 @$1 为：
- 代码质量
- 最佳实践
- 潜在错误

用法：

> /review-file src/api/users.ts

效果： Claude在处理命令前读取 src/api/users.ts

多个文件引用

引用多个文件：

与 @src/old-version.js 比较 @src/new-version.js

识别：
- 破坏性变更
- 新功能
- 错误修复

静态文件引用

引用已知文件，无需参数：

审查 @package.json 和 @tsconfig.json 以确保一致性

确保：
- TypeScript版本匹配
- 依赖项一致
- 构建配置正确

Bash命令在命令中的执行

命令可以在Claude处理命令之前内联执行bash命令，以动态地收集上下文。这适用于包括存储库状态、环境信息或特定于项目的上下文。

何时使用：

  • 包括动态上下文（git状态、环境变量等）
  • 收集项目/存储库状态
  • 构建上下文感知工作流程

实施细节： 有关完整语法、示例和最佳实践，请参见 references/plugin-features-reference.md 部分中的bash执行。参考包括确切的语法和多个工作示例，以避免执行问题

命令组织

扁平结构

小型命令集的简单组织：

.claude/commands/
├── build.md
├── test.md
├── deploy.md
├── review.md
└── docs.md

使用时： 5-15个命令，没有明确的类别

命名空间结构

在子目录中组织命令：

.claude/commands/
├── ci/
│   ├── build.md        # /build (project:ci)
│   ├── test.md         # /test (project:ci)
│   └── lint.md         # /lint (project:ci)
├── git/
│   ├── commit.md       # /commit (project:git)
│   └── pr.md           # /pr (project:git)
└── docs/
    ├── generate.md     # /generate (project:docs)
    └── publish.md      # /publish (project:docs)

好处：

  • 按类别逻辑分组
  • 在 /help 中显示命名空间
  • 更容易找到相关命令

使用时： 15+命令，明确类别

最佳实践

命令设计

  1. 单一责任： 一个命令，一个任务
  2. 清晰描述： 在 /help 中自解释
  3. 显式依赖： 需要时使用 allowed-tools
  4. 文档化参数： 总是提供 argument-hint
  5. 一致命名： 使用动词-名词模式（review-pr, fix-issue）

参数处理

  1. 验证参数： 在提示中检查所需参数
  2. 提供默认值： 当参数缺失时建议默认值
  3. 文档化格式： 解释预期的参数格式
  4. 处理边缘情况： 考虑缺失或无效参数
---
argument-hint: [pr-number]
---

$IF($1,
  审查PR #$1,
  请提供PR编号。用法：/review-pr [number]
)

文件引用

  1. 显式路径： 使用清晰的文件路径
  2. 检查存在性： 优雅地处理缺失文件
  3. 相对路径： 使用项目相对路径
  4. 支持Glob： 考虑使用Glob工具进行模式匹配

Bash命令

  1. 限制范围： 使用 Bash(git:*) 而不是 Bash(*)
  2. 安全命令： 避免破坏性操作
  3. 处理错误： 考虑命令失败
  4. 保持快速： 长时间运行的命令会减慢调用

文档化

  1. 添加注释： 解释复杂逻辑
  2. 提供示例： 在注释中显示用法
  3. 列出要求： 文档化依赖关系
  4. 版本化命令： 注释破坏性更改
---
description: 部署应用程序到环境
argument-hint: [environment] [version]
---

<!--
用法：/deploy [staging|production] [version]
需要：AWS凭据配置
示例：/deploy staging v1.2.3
-->

将应用程序部署到 $1 环境，使用版本 $2 ...

常见模式

审查模式

---
description: 审查代码变更
allowed-tools: 读取，Bash(git:*)
---

变更的文件：!`git diff --name-only`

审查每个文件：
1. 代码质量和风格
2. 潜在错误或问题
3. 测试覆盖率
4. 文档需求

为每个文件提供具体反馈。

测试模式

---
description: 为特定文件运行测试
argument-hint: [test-file]
allowed-tools: Bash(npm:*)
---

运行测试：!`npm test $1`

分析结果并为失败提供修复建议。

文档模式

---
description: 为文件生成文档
argument-hint: [source-file]
---

为 @$1 生成全面的文档，包括：
- 函数/类描述
- 参数文档
- 返回值描述
- 使用示例
- 边缘情况和错误

工作流模式

---
description: 完成PR工作流
argument-hint: [pr-number]
allowed-tools: Bash(gh:*), 读取
---

PR #$1 工作流：

1. 获取PR：!`gh pr view $1`
2. 审查变更
3. 运行检查
4. 批准或请求更改

故障排除

命令未出现：

  • 检查文件是否在正确的目录中
  • 验证是否存在 .md 扩展名
  • 确保有效的Markdown格式
  • 重启Claude Code

参数不工作：

  • 验证 $1, $2 语法正确
  • 检查 argument-hint 是否匹配用法
  • 确保没有额外的空格

Bash执行失败：

  • 检查 allowed-tools 是否包括Bash
  • 验证反引号中的命令语法
  • 先在终端中测试命令
  • 检查所需的权限

文件引用不工作：

  • 验证 @ 语法正确
  • 检查文件路径是否有效
  • 确保允许读取工具
  • 使用绝对或项目相对路径

插件特定功能

CLAUDE_PLUGIN_ROOT 变量

插件命令可以访问 ${CLAUDE_PLUGIN_ROOT}，这是一个环境变量，解析为插件的绝对路径。

目的：

  • 可移植地引用插件文件
  • 执行插件脚本
  • 加载插件配置
  • 访问插件模板

基本用法：

---
description: 使用插件脚本进行分析
allowed-tools: Bash(node:*)
---

运行分析：!`node ${CLAUDE_PLUGIN_ROOT}/scripts/analyze.js $1`

审查结果并报告发现。

常见模式：

# 执行插件脚本
!`bash ${CLAUDE_PLUGIN_ROOT}/scripts/script.sh`

# 加载插件配置
@${CLAUDE_PLUGIN_ROOT}/config/settings.json

# 使用插件模板
@${CLAUDE_PLUGIN_ROOT}/templates/report.md

# 访问插件资源
@${CLAUDE_PLUGIN_ROOT}/docs/reference.md

为什么使用它：

  • 适用于所有安装
  • 系统间可移植
  • 不需要硬编码路径
  • 对多文件插件至关重要

插件命令组织

插件命令自动从 commands/ 目录中发现：

plugin-name/
├── commands/
│   ├── foo.md              # /foo (plugin:plugin-name)
│   ├── bar.md              # /bar (plugin:plugin-name)
│   └── utils/
│       └── helper.md       # /helper (plugin:plugin-name:utils)
└── plugin.json

命名空间的好处：

  • 逻辑命令分组
  • 在 /help 输出中显示
  • 避免名称冲突
  • 组织相关命令

命名约定：

  • 使用描述性动作名称
  • 避免通用名称（测试，运行）
  • 考虑插件特定前缀
  • 对多词名称使用连字符

插件命令模式

基于配置的模式：

---
description: 使用插件配置部署
argument-hint: [environment]
allowed-tools: 读取，Bash(*)
---

加载配置：@${CLAUDE_PLUGIN_ROOT}/config/$1-deploy.json

将应用程序部署到 $1 环境，使用配置设置。
监控部署并报告状态。

基于模板的模式：

---
description: 从模板生成文档
argument-hint: [component]
---

模板：@${CLAUDE_PLUGIN_ROOT}/templates/docs.md

为 $1 生成文档，遵循模板结构。

多脚本模式：

---
description: 完成构建工作流
allowed-tools: Bash(*)
---

构建：!`bash ${CLAUDE_PLUGIN_ROOT}/scripts/build.sh`
测试：!`bash ${CLAUDE_PLUGIN_ROOT}/scripts/test.sh`
打包：!`bash ${CLAUDE_PLUGIN_ROOT}/scripts/package.sh`

审查输出并报告工作流状态。

查看 references/plugin-features-reference.md 了解详细的模式。

与插件组件集成

命令可以与其他插件组件集成，以实现强大的工作流程。

代理集成

为复杂任务启动插件代理：

---
description: 深度代码审查
argument-hint: [file-path]
---

使用 code-reviewer 代理对 @$1 进行全面审查。

代理将分析：
- 代码结构
- 安全问题
- 性能
- 最佳实践

代理使用的插件资源：
- ${CLAUDE_PLUGIN_ROOT}/config/rules.json
- ${CLAUDE_PLUGIN_ROOT}/checklists/review.md

关键点：

  • 代理必须存在于 plugin/agents/ 目录中
  • Claude使用Task工具启动代理
  • 文档代理能力
  • 引用代理使用的插件资源

技能集成

利用插件技能进行专门知识：

---
description: 按照插件标准文档化API
argument-hint: [api-file]
---

按照插件标准在 @$1 中文档化API。

使用 api-docs-standards 技能确保：
- 完整的端点文档
- 一致的格式
- 示例质量
- 错误文档

生成生产就绪的API文档。

关键点：

  • 技能必须存在于 plugin/skills/ 目录中
  • 提及技能名称以触发调用
  • 文档技能目的
  • 解释技能提供的内容

钩子协调

设计命令以与插件钩子一起工作：

  • 命令可以为钩子处理准备状态
  • 钩子在工具事件上自动执行
  • 命令应记录预期的钩子行为
  • 指导Claude解释钩子输出

查看 references/plugin-features-reference.md 了解命令与钩子协调的示例

多组件工作流

结合代理、技能和脚本：

---
description: 全面审查工作流
argument-hint: [file]
allowed-tools: Bash(node:*), 读取
---

目标：@$1

第一阶段 - 静态分析：
!`node ${CLAUDE_PLUGIN_ROOT}/scripts/lint.js $1`

第二阶段 - 深度审查：
启动 code-reviewer 代理进行详细分析。

第三阶段 - 标准检查：
使用 coding-standards 技能进行验证。

第四阶段 - 报告：
模板：@${CLAUDE_PLUGIN_ROOT}/templates/review.md

按照模板编制调查结果。

何时使用：

  • 复杂的多步骤工作流
  • 利用多个插件能力
  • 需要专门分析
  • 需要结构化输出

验证模式

命令应在处理之前验证输入和资源。

参数验证

---
description: 部署并验证
argument-hint: [environment]
---

验证环境：!`echo "$1" | grep -E "^(dev|staging|prod)$" || echo "INVALID"`

如果 $1 是有效环境：
  将应用程序部署到 $1
否则：
  解释有效环境：dev, staging, prod
  显示用法：/deploy [environment]

文件存在性检查

---
description: 处理配置
argument-hint: [config-file]
---

检查文件存在：!`test -f $1 && echo "EXISTS" || echo "MISSING"`

如果文件存在：
  处理配置：@$1
否则：
  解释放置配置文件的位置
  显示预期格式
  提供示例配置

插件资源验证

---
description: 运行插件分析器
allowed-tools: Bash(test:*)
---

验证插件设置：
- 脚本：!`test -x ${CLAUDE_PLUGIN_ROOT}/bin/analyze && echo "✓" || echo "✗"`
- 配置：!`test -f ${CLAUDE_PLUGIN_ROOT}/config.json && echo "✓" || echo "✗"`

如果所有检查通过，则运行分析。
否则，报告缺少的组件。

错误处理

---
description: 构建并错误处理
allowed-tools: Bash(*)
---

执行构建：!`bash ${CLAUDE_PLUGIN_ROOT}/scripts/build.sh 2>&1 || echo "BUILD_FAILED"`

如果构建成功：
  报告成功和输出位置
如果构建失败：
  分析错误输出
  提出可能的原因
  提供故障排除步骤

最佳实践：

  • 尽早在命令中验证
  • 提供有用的错误消息
  • 建议纠正措施
  • 优雅地处理边缘情况

有关详细的frontmatter字段规范，请参见 references/frontmatter-reference.md。 有关插件特定功能和模式，请参见 references/plugin-features-reference.md。 有关命令模式示例，请参见 examples/ 目录。