⚡

命令开发Skill CommandDevelopment

命令开发技能用于在Claude Code中创建和管理slash commands，通过Markdown文件和YAML frontmatter配置，实现工作流自动化、动态参数处理、文件引用集成和bash命令执行，提升开发效率。关键词：Claude Code, 命令开发, slash commands, YAML frontmatter, 工作流自动化, AI辅助开发, 低代码开发。

低代码开发 0 次安装 0 次浏览 更新于 3/13/2026

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

Claude Code 命令开发

概述

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

关键概念：

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

命令基础

什么是斜杠命令？

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

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

关键：命令是给Claude的指令

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

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

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

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

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

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

此命令将审查您的代码以查找安全问题。
您将收到带有漏洞详细信息的报告。

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

命令位置

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

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

个人命令（随处可用）：

  • 位置：~/.claude/commands/
  • 范围：在所有项目中可用
  • 标签：在/help中显示为“(user)”
  • 用途：个人工作流、跨项目工具

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

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

文件格式

基本结构

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

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

简单命令：

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

基本命令不需要frontmatter。

使用YAML Frontmatter

使用YAML frontmatter添加配置：

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

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

YAML Frontmatter字段

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执行

命令可以在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: 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"`

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

最佳实践：

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

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