⚡

命令开发Skill command-development

此技能专注于Claude Code平台上的命令开发，提供完整的指南，帮助用户创建、管理和优化斜杠命令，包括YAML前置元数据配置、动态参数处理、文件引用和bash命令执行，以实现自动化工作流和高效开发流程。关键词：斜杠命令开发、Claude Code、命令自动化、YAML配置、动态参数、文件引用、bash执行。

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

name: 命令开发 description: 当用户要求“创建斜杠命令”、“添加命令”、“编写自定义命令”、“定义命令参数”、“使用命令前置元数据”、“组织命令”、“创建带文件引用的命令”、“交互式命令”、“在命令中使用AskUserQuestion”，或需要关于斜杠命令结构、YAML前置元数据字段、动态参数、命令中的bash执行、用户交互模式或Claude Code命令开发最佳实践的指导时，应使用此技能。

Claude Code的命令开发

概述

斜杠命令是定义为Markdown文件的常用提示，Claude在交互会话中执行。理解命令结构、前置元数据选项和动态功能可以创建强大的、可重用的工作流。

关键概念：

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

命令基础

什么是斜杠命令？

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

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

关键：命令是针对Claude的指令

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

当用户调用/命令名称时，命令内容成为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攻击
- 身份验证绕过
- 不安全数据处理

基本命令不需要前置元数据。

带YAML前置元数据

使用YAML前置元数据添加配置：

---
description: 审查代码安全问题
allowed-tools: Read, Grep, Bash(git:*)
model: sonnet
---

审查此代码的安全漏洞...

YAML前置元数据字段

description

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

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

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

allowed-tools

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

---
allowed-tools: Read, Write, Edit, Bash(git:*)
---

模式：

  • Read, Write, Edit - 特定工具
  • 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执行

命令可以内联执行bash命令，以在Claude处理命令前动态收集上下文。这对于包含仓库状态、环境信息或项目特定上下文非常有用。

使用时机：

  • 包含动态上下文（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: Read, 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:*), Read
---

PR #$1工作流：

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

故障排除

命令不出现：

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

参数不工作：

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

Bash执行失败：

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

文件引用不工作：

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

插件特定功能

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输出中显示
  • 避免名称冲突
  • 组织相关命令

命名约定：

  • 使用描述性动作名称
  • 避免通用名称（test, run）
  • 考虑插件特定前缀
  • 使用连字符用于多词名称

插件命令模式

基于配置的模式：

---
description: 使用插件配置部署
argument-hint: [environment]
allowed-tools: Read, 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]
---

使用代码审查代理启动对@$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:*), Read
---

目标：@$1

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

阶段2 - 深度审查：
启动代码审查代理进行详细分析。

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

阶段4 - 报告：
模板：@${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"`

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

最佳实践：

  • 在命令早期验证
  • 提供有用的错误消息
  • 建议纠正操作
  • 优雅处理边缘案例

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