command-development

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Command Development for Claude Code

Claude Code 命令开发

Overview

概述

Slash commands are frequently-used prompts defined as Markdown files that Claude executes during interactive sessions. Understanding command structure, frontmatter options, and dynamic features enables creating powerful, reusable workflows.
Key concepts:
  • Markdown file format for commands
  • YAML frontmatter for configuration
  • Dynamic arguments and file references
  • Bash execution for context
  • Command organization and namespacing
Slash commands是定义为Markdown文件的常用提示词,Claude会在交互式会话中执行这些命令。了解命令结构、YAML frontmatter选项和动态功能,能够创建强大且可复用的工作流。
核心概念:
  • 命令采用Markdown文件格式
  • 使用YAML frontmatter进行配置
  • 动态参数与文件引用
  • 用于上下文获取的Bash执行
  • 命令组织与命名空间

Command Basics

命令基础

What is a Slash Command?

什么是Slash Command?

A slash command is a Markdown file containing a prompt that Claude executes when invoked. Commands provide:
  • Reusability: Define once, use repeatedly
  • Consistency: Standardize common workflows
  • Sharing: Distribute across team or projects
  • Efficiency: Quick access to complex prompts
Slash Command是包含提示词的Markdown文件,用户调用时Claude会执行该提示词。命令具备以下优势:
  • 可复用性:定义一次,重复使用
  • 一致性:标准化常见工作流
  • 可共享性:在团队或项目间分发
  • 高效性:快速访问复杂提示词

Critical: Commands are Instructions FOR Claude

关键注意点:命令是给Claude的指令

Commands are written for agent consumption, not human consumption.
When a user invokes
/command-name
, the command content becomes Claude's instructions. Write commands as directives TO Claude about what to do, not as messages TO the user.
Correct approach (instructions for Claude):
markdown
Review this code for security vulnerabilities including:
- SQL injection
- XSS attacks
- Authentication issues

Provide specific line numbers and severity ratings.
Incorrect approach (messages to user):
markdown
This command will review your code for security issues.
You'll receive a report with vulnerability details.
The first example tells Claude what to do. The second tells the user what will happen but doesn't instruct Claude. Always use the first approach.
命令是写给Agent(智能体)的,而非给人类阅读的。
当用户调用
/command-name
时,命令内容会成为Claude的指令。撰写命令时,要以给Claude的指令形式编写,而非给用户的消息。
正确写法(给Claude的指令):
markdown
审查以下代码的安全漏洞,包括:
- SQL注入
- XSS攻击
- 认证问题

提供具体的行号和风险等级。
错误写法(给用户的消息):
markdown
此命令将审查你的代码是否存在安全问题。
你会收到包含漏洞详情的报告。
第一个示例明确告诉Claude要做什么,第二个示例只是告知用户会发生什么,但没有给Claude下达指令。请始终使用第一种写法。

Command Locations

命令存放位置

Project commands (shared with team):
  • Location:
    .claude/commands/
  • Scope: Available in specific project
  • Label: Shown as "(project)" in
    /help
  • Use for: Team workflows, project-specific tasks
Personal commands (available everywhere):
  • Location:
    ~/.claude/commands/
  • Scope: Available in all projects
  • Label: Shown as "(user)" in
    /help
  • Use for: Personal workflows, cross-project utilities
Plugin commands (bundled with plugins):
  • Location:
    plugin-name/commands/
  • Scope: Available when plugin installed
  • Label: Shown as "(plugin-name)" in
    /help
  • Use for: Plugin-specific functionality
项目命令(与团队共享):
  • 位置:
    .claude/commands/
  • 范围:仅在特定项目中可用
  • 标识:在
    /help
    中显示为“(project)”
  • 适用场景:团队工作流、项目特定任务
个人命令(全局可用):
  • 位置:
    ~/.claude/commands/
  • 范围:在所有项目中可用
  • 标识:在
    /help
    中显示为“(user)”
  • 适用场景:个人工作流、跨项目工具
插件命令(随插件捆绑):
  • 位置:
    plugin-name/commands/
  • 范围:安装插件后可用
  • 标识:在
    /help
    中显示为“(plugin-name)”
  • 适用场景:插件特定功能

File Format

文件格式

Basic Structure

基本结构

Commands are Markdown files with
.md
extension:
.claude/commands/
├── review.md           # /review command
├── test.md             # /test command
└── deploy.md           # /deploy command
Simple command:
markdown
Review this code for security vulnerabilities including:
- SQL injection
- XSS attacks
- Authentication bypass
- Insecure data handling
No frontmatter needed for basic commands.
命令是扩展名为
.md
的Markdown文件:
.claude/commands/
├── review.md           # /review 命令
├── test.md             # /test 命令
└── deploy.md           # /deploy 命令
简单命令示例:
markdown
审查以下代码的安全漏洞,包括:
- SQL注入
- XSS攻击
- 认证绕过
- 不安全的数据处理
基础命令无需添加frontmatter。

With YAML Frontmatter

带YAML Frontmatter的命令

Add configuration using YAML frontmatter:
markdown
---
description: Review code for security issues
allowed-tools: Read, Grep, Bash(git:*)
model: sonnet
---

Review this code for security vulnerabilities...
可通过YAML frontmatter添加配置:
markdown
---
description: 审查代码安全问题
allowed-tools: Read, Grep, Bash(git:*)
model: sonnet
---

审查以下代码的安全漏洞...

YAML Frontmatter Fields

YAML Frontmatter字段

description

description

Purpose: Brief description shown in
/help
Type: String Default: First line of command prompt
yaml
---
description: Review pull request for code quality
---
Best practice: Clear, actionable description (under 60 characters)
用途:
/help
中显示的简短描述 类型: 字符串 默认值: 命令提示词的第一行
yaml
---
description: 审查拉取请求的代码质量
---
最佳实践: 清晰、可执行的描述(不超过60个字符)

allowed-tools

allowed-tools

Purpose: Specify which tools command can use Type: String or Array Default: Inherits from conversation
yaml
---
allowed-tools: Read, Write, Edit, Bash(git:*)
---
Patterns:
  • Read, Write, Edit
    - Specific tools
  • Bash(git:*)
    - Bash with git commands only
  • *
    - All tools (rarely needed)
Use when: Command requires specific tool access
用途: 指定命令可使用的工具 类型: 字符串或数组 默认值: 继承自当前会话
yaml
---
allowed-tools: Read, Write, Edit, Bash(git:*)
---
模式:
  • Read, Write, Edit
    - 指定具体工具
  • Bash(git:*)
    - 仅允许使用git相关的Bash命令
  • *
    - 允许所有工具(极少需要)
适用场景: 命令需要特定工具权限时

model

model

Purpose: Specify model for command execution Type: String (sonnet, opus, haiku) Default: Inherits from conversation
yaml
---
model: haiku
---
Use cases:
  • haiku
    - Fast, simple commands
  • sonnet
    - Standard workflows
  • opus
    - Complex analysis
用途: 指定执行命令的模型 类型: 字符串(sonnet, opus, haiku) 默认值: 继承自当前会话
yaml
---
model: haiku
---
适用场景:
  • haiku
    - 快速、简单的命令
  • sonnet
    - 标准工作流
  • opus
    - 复杂分析任务

argument-hint

argument-hint

Purpose: Document expected arguments for autocomplete Type: String Default: None
yaml
---
argument-hint: [pr-number] [priority] [assignee]
---
Benefits:
  • Helps users understand command arguments
  • Improves command discovery
  • Documents command interface
用途: 记录自动补全所需的参数 类型: 字符串 默认值:
yaml
---
argument-hint: [pr-number] [priority] [assignee]
---
优势:
  • 帮助用户理解命令参数
  • 提升命令的可发现性
  • 记录命令的接口规范

disable-model-invocation

disable-model-invocation

Purpose: Prevent SlashCommand tool from programmatically calling command Type: Boolean Default: false
yaml
---
disable-model-invocation: true
---
Use when: Command should only be manually invoked
用途: 防止SlashCommand工具以编程方式调用命令 类型: 布尔值 默认值: false
yaml
---
disable-model-invocation: true
---
适用场景: 命令仅允许手动调用时

Dynamic Arguments

动态参数

Using $ARGUMENTS

使用$ARGUMENTS

Capture all arguments as single string:
markdown
---
description: Fix issue by number
argument-hint: [issue-number]
---

Fix issue #$ARGUMENTS following our coding standards and best practices.
Usage:
> /fix-issue 123
> /fix-issue 456
Expands to:
Fix issue #123 following our coding standards...
Fix issue #456 following our coding standards...
将所有参数捕获为单个字符串:
markdown
---
description: 根据编号修复问题
argument-hint: [issue-number]
---

按照我们的编码标准和最佳实践,修复编号为#$ARGUMENTS的问题。
使用示例:
> /fix-issue 123
> /fix-issue 456
展开后:
按照我们的编码标准和最佳实践,修复编号为#123的问题。
按照我们的编码标准和最佳实践,修复编号为#456的问题。

Using Positional Arguments

使用位置参数

Capture individual arguments with
$1
,
$2
,
$3
, etc.:
markdown
---
description: Review PR with priority and assignee
argument-hint: [pr-number] [priority] [assignee]
---

Review pull request #$1 with priority level $2.
After review, assign to $3 for follow-up.
Usage:
> /review-pr 123 high alice
Expands to:
Review pull request #123 with priority level high.
After review, assign to alice for follow-up.
通过
$1
,
$2
,
$3
等捕获单个参数:
markdown
---
description: 按优先级和经办人审查PR
argument-hint: [pr-number] [priority] [assignee]
---

审查编号为#$1的拉取请求,优先级为$2。
审查完成后,分配给$3进行跟进。
使用示例:
> /review-pr 123 high alice
展开后:
审查编号为#123的拉取请求,优先级为high。
审查完成后,分配给alice进行跟进。

Combining Arguments

参数组合使用

Mix positional and remaining arguments:
markdown
Deploy $1 to $2 environment with options: $3
Usage:
> /deploy api staging --force --skip-tests
Expands to:
Deploy api to staging environment with options: --force --skip-tests
混合使用位置参数和剩余参数:
markdown
将$1部署到$2环境,选项:$3
使用示例:
> /deploy api staging --force --skip-tests
展开后:
将api部署到staging环境,选项:--force --skip-tests

File References

文件引用

Using @ Syntax

使用@语法

Include file contents in command:
markdown
---
description: Review specific file
argument-hint: [file-path]
---

Review @$1 for:
- Code quality
- Best practices
- Potential bugs
Usage:
> /review-file src/api/users.ts
Effect: Claude reads
src/api/users.ts
before processing command
在命令中包含文件内容:
markdown
---
description: 审查指定文件
argument-hint: [file-path]
---

审查@$1,检查:
- 代码质量
- 最佳实践
- 潜在bug
使用示例:
> /review-file src/api/users.ts
效果: Claude在处理命令前会读取
src/api/users.ts
文件

Multiple File References

多文件引用

Reference multiple files:
markdown
Compare @src/old-version.js with @src/new-version.js

Identify:
- Breaking changes
- New features
- Bug fixes
引用多个文件:
markdown
对比@src/old-version.js和@src/new-version.js

识别:
- 破坏性变更
- 新功能
- Bug修复

Static File References

静态文件引用

Reference known files without arguments:
markdown
Review @package.json and @tsconfig.json for consistency

Ensure:
- TypeScript version matches
- Dependencies are aligned
- Build configuration is correct
无需参数即可引用已知文件:
markdown
审查@package.json和@tsconfig.json的一致性

确保:
- TypeScript版本匹配
- 依赖项对齐
- 构建配置正确

Bash Execution in Commands

命令中的Bash执行

Commands can execute bash commands inline to dynamically gather context before Claude processes the command. This is useful for including repository state, environment information, or project-specific context.
When to use:
  • Include dynamic context (git status, environment vars, etc.)
  • Gather project/repository state
  • Build context-aware workflows
Implementation details: For complete syntax, examples, and best practices, see
references/plugin-features-reference.md
section on bash execution. The reference includes the exact syntax and multiple working examples to avoid execution issues
命令可以内联执行Bash命令,在Claude处理命令前动态收集上下文。这对于包含仓库状态、环境信息或项目特定上下文非常有用。
适用场景:
  • 包含动态上下文(git状态、环境变量等)
  • 收集项目/仓库状态
  • 构建上下文感知的工作流
实现细节: 关于完整语法、示例和最佳实践,请参阅
references/plugin-features-reference.md
中关于Bash执行的章节。该参考文档包含准确的语法和多个可用示例,可避免执行问题。

Command Organization

命令组织

Flat Structure

扁平结构

Simple organization for small command sets:
.claude/commands/
├── build.md
├── test.md
├── deploy.md
├── review.md
└── docs.md
Use when: 5-15 commands, no clear categories
适用于小型命令集的简单组织方式:
.claude/commands/
├── build.md
├── test.md
├── deploy.md
├── review.md
└── docs.md
适用场景: 5-15个命令,无明确分类

Namespaced Structure

命名空间结构

Organize commands in subdirectories:
.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)
Benefits:
  • Logical grouping by category
  • Namespace shown in
    /help
  • Easier to find related commands
Use when: 15+ commands, clear categories
在子目录中组织命令:
.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个以上命令,有明确分类

Best Practices

最佳实践

Command Design

命令设计

  1. Single responsibility: One command, one task
  2. Clear descriptions: Self-explanatory in
    /help
  3. Explicit dependencies: Use
    allowed-tools
    when needed
  4. Document arguments: Always provide
    argument-hint
  5. Consistent naming: Use verb-noun pattern (review-pr, fix-issue)
  1. 单一职责:一个命令对应一个任务
  2. 清晰描述:在
    /help
    中自解释
  3. 显式依赖:必要时使用
    allowed-tools
  4. 参数文档:始终提供
    argument-hint
  5. 命名一致:使用动词-名词模式(如review-pr、fix-issue)

Argument Handling

参数处理

  1. Validate arguments: Check for required arguments in prompt
  2. Provide defaults: Suggest defaults when arguments missing
  3. Document format: Explain expected argument format
  4. Handle edge cases: Consider missing or invalid arguments
markdown
---
argument-hint: [pr-number]
---

$IF($1,
  Review PR #$1,
  Please provide a PR number. Usage: /review-pr [number]
)
  1. 参数验证:在提示词中检查必填参数
  2. 提供默认值:参数缺失时建议默认值
  3. 文档格式:说明参数的预期格式
  4. 处理边缘情况:考虑参数缺失或无效的情况
markdown
---
argument-hint: [pr-number]
---

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

File References

文件引用

  1. Explicit paths: Use clear file paths
  2. Check existence: Handle missing files gracefully
  3. Relative paths: Use project-relative paths
  4. Glob support: Consider using Glob tool for patterns
  1. 路径明确:使用清晰的文件路径
  2. 检查存在性:优雅处理文件缺失的情况
  3. 相对路径:使用项目相对路径
  4. Glob支持:考虑使用Glob工具匹配文件模式

Bash Commands

Bash命令

  1. Limit scope: Use
    Bash(git:*)
    not
    Bash(*)
  2. Safe commands: Avoid destructive operations
  3. Handle errors: Consider command failures
  4. Keep fast: Long-running commands slow invocation
  1. 限制范围:使用
    Bash(git:*)
    而非
    Bash(*)
  2. 安全命令:避免破坏性操作
  3. 错误处理:考虑命令执行失败的情况
  4. 保持快速:长时间运行的命令会降低调用速度

Documentation

文档

  1. Add comments: Explain complex logic
  2. Provide examples: Show usage in comments
  3. List requirements: Document dependencies
  4. Version commands: Note breaking changes
markdown
---
description: Deploy application to environment
argument-hint: [environment] [version]
---

<!--
Usage: /deploy [staging|production] [version]
Requires: AWS credentials configured
Example: /deploy staging v1.2.3
-->

Deploy application to $1 environment using version $2...
  1. 添加注释:解释复杂逻辑
  2. 提供示例:在注释中展示使用方法
  3. 列出依赖:记录命令所需的依赖
  4. 版本化命令:标注破坏性变更
markdown
---
description: 将应用部署到环境
argument-hint: [environment] [version]
---

<!--
使用方法:/deploy [staging|production] [version]
要求:已配置AWS凭证
示例:/deploy staging v1.2.3
-->

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

Common Patterns

常见模式

Review Pattern

审查模式

markdown
---
description: Review code changes
allowed-tools: Read, Bash(git:*)
---

Files changed: !`git diff --name-only`

Review each file for:
1. Code quality and style
2. Potential bugs or issues
3. Test coverage
4. Documentation needs

Provide specific feedback for each file.
markdown
---
description: 审查代码变更
allowed-tools: Read, Bash(git:*)
---

变更文件:!`git diff --name-only`

审查每个文件的:
1. 代码质量与风格
2. 潜在bug或问题
3. 测试覆盖率
4. 文档需求

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

Testing Pattern

测试模式

markdown
---
description: Run tests for specific file
argument-hint: [test-file]
allowed-tools: Bash(npm:*)
---

Run tests: !`npm test $1`

Analyze results and suggest fixes for failures.
markdown
---
description: 运行指定文件的测试
argument-hint: [test-file]
allowed-tools: Bash(npm:*)
---

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

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

Documentation Pattern

文档生成模式

markdown
---
description: Generate documentation for file
argument-hint: [source-file]
---

Generate comprehensive documentation for @$1 including:
- Function/class descriptions
- Parameter documentation
- Return value descriptions
- Usage examples
- Edge cases and errors
markdown
---
description: 为文件生成文档
argument-hint: [source-file]
---

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

Workflow Pattern

工作流模式

markdown
---
description: Complete PR workflow
argument-hint: [pr-number]
allowed-tools: Bash(gh:*), Read
---

PR #$1 Workflow:

1. Fetch PR: !`gh pr view $1`
2. Review changes
3. Run checks
4. Approve or request changes
markdown
---
description: 完成PR工作流
argument-hint: [pr-number]
allowed-tools: Bash(gh:*), Read
---

PR #$1工作流:

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

Troubleshooting

故障排除

Command not appearing:
  • Check file is in correct directory
  • Verify
    .md
    extension present
  • Ensure valid Markdown format
  • Restart Claude Code
Arguments not working:
  • Verify
    $1
    ,
    $2
    syntax correct
  • Check
    argument-hint
    matches usage
  • Ensure no extra spaces
Bash execution failing:
  • Check
    allowed-tools
    includes Bash
  • Verify command syntax in backticks
  • Test command in terminal first
  • Check for required permissions
File references not working:
  • Verify
    @
    syntax correct
  • Check file path is valid
  • Ensure Read tool allowed
  • Use absolute or project-relative paths
命令未显示:
  • 检查文件是否在正确目录中
  • 验证文件是否有
    .md
    扩展名
  • 确保Markdown格式有效
  • 重启Claude Code
参数不生效:
  • 验证
    $1
    ,
    $2
    等语法是否正确
  • 检查
    argument-hint
    是否与使用方法匹配
  • 确保没有多余空格
Bash执行失败:
  • 检查
    allowed-tools
    是否包含Bash
  • 验证反引号中的命令语法
  • 先在终端中测试命令
  • 检查是否有必要的权限
文件引用不生效:
  • 验证
    @
    语法是否正确
  • 检查文件路径是否有效
  • 确保已允许Read工具
  • 使用绝对路径或项目相对路径

Plugin-Specific Features

插件特定功能

CLAUDE_PLUGIN_ROOT Variable

CLAUDE_PLUGIN_ROOT变量

Plugin commands have access to
${CLAUDE_PLUGIN_ROOT}
, an environment variable that resolves to the plugin's absolute path.
Purpose:
  • Reference plugin files portably
  • Execute plugin scripts
  • Load plugin configuration
  • Access plugin templates
Basic usage:
markdown
---
description: Analyze using plugin script
allowed-tools: Bash(node:*)
---

Run analysis: !`node ${CLAUDE_PLUGIN_ROOT}/scripts/analyze.js $1`

Review results and report findings.
Common patterns:
markdown
undefined
插件命令可访问环境变量
${CLAUDE_PLUGIN_ROOT}
,该变量指向插件的绝对路径。
用途:
  • 可移植地引用插件文件
  • 执行插件脚本
  • 加载插件配置
  • 访问插件模板
基本用法:
markdown
---
description: 使用插件脚本进行分析
allowed-tools: Bash(node:*)
---

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

审查结果并报告发现的问题。
常见模式:
markdown
undefined

Execute plugin script

执行插件脚本

!
bash ${CLAUDE_PLUGIN_ROOT}/scripts/script.sh
!
bash ${CLAUDE_PLUGIN_ROOT}/scripts/script.sh

Load plugin configuration

加载插件配置

@${CLAUDE_PLUGIN_ROOT}/config/settings.json
@${CLAUDE_PLUGIN_ROOT}/config/settings.json

Use plugin template

使用插件模板

@${CLAUDE_PLUGIN_ROOT}/templates/report.md
@${CLAUDE_PLUGIN_ROOT}/templates/report.md

Access plugin resources

访问插件资源

@${CLAUDE_PLUGIN_ROOT}/docs/reference.md

**Why use it:**
- Works across all installations
- Portable between systems
- No hardcoded paths needed
- Essential for multi-file plugins
@${CLAUDE_PLUGIN_ROOT}/docs/reference.md

**使用原因:**
- 在所有安装环境中都能正常工作
- 在不同系统间可移植
- 无需硬编码路径
- 对多文件插件至关重要

Plugin Command Organization

插件命令组织

Plugin commands discovered automatically from
commands/
directory:
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
Namespace benefits:
  • Logical command grouping
  • Shown in
    /help
    output
  • Avoid name conflicts
  • Organize related commands
Naming conventions:
  • Use descriptive action names
  • Avoid generic names (test, run)
  • Consider plugin-specific prefix
  • Use hyphens for multi-word names
插件命令会自动从
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)
  • 考虑添加插件特定前缀
  • 多词名称使用连字符分隔

Plugin Command Patterns

插件命令模式

Configuration-based pattern:
markdown
---
description: Deploy using plugin configuration
argument-hint: [environment]
allowed-tools: Read, Bash(*)
---

Load configuration: @${CLAUDE_PLUGIN_ROOT}/config/$1-deploy.json

Deploy to $1 using configuration settings.
Monitor deployment and report status.
Template-based pattern:
markdown
---
description: Generate docs from template
argument-hint: [component]
---

Template: @${CLAUDE_PLUGIN_ROOT}/templates/docs.md

Generate documentation for $1 following template structure.
Multi-script pattern:
markdown
---
description: Complete build workflow
allowed-tools: Bash(*)
---

Build: !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/build.sh`
Test: !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/test.sh`
Package: !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/package.sh`

Review outputs and report workflow status.
See
references/plugin-features-reference.md
for detailed patterns.
基于配置的模式:
markdown
---
description: 使用插件配置进行部署
argument-hint: [environment]
allowed-tools: Read, Bash(*)
---

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

使用配置设置将应用部署到$1环境。
监控部署过程并报告状态。
基于模板的模式:
markdown
---
description: 从模板生成文档
argument-hint: [component]
---

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

按照模板结构为$1生成文档。
多脚本模式:
markdown
---
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

Integration with Plugin Components

与插件组件的集成

Commands can integrate with other plugin components for powerful workflows.
命令可与其他插件组件集成,实现强大的工作流。

Agent Integration

Agent集成

Launch plugin agents for complex tasks:
markdown
---
description: Deep code review
argument-hint: [file-path]
---

Initiate comprehensive review of @$1 using the code-reviewer agent.

The agent will analyze:
- Code structure
- Security issues
- Performance
- Best practices

Agent uses plugin resources:
- ${CLAUDE_PLUGIN_ROOT}/config/rules.json
- ${CLAUDE_PLUGIN_ROOT}/checklists/review.md
Key points:
  • Agent must exist in
    plugin/agents/
    directory
  • Claude uses Task tool to launch agent
  • Document agent capabilities
  • Reference plugin resources agent uses
启动插件Agent处理复杂任务:
markdown
---
description: 深度代码审查
argument-hint: [file-path]
---

启动code-reviewer Agent对@$1进行全面审查。

Agent会分析:
- 代码结构
- 安全问题
- 性能
- 最佳实践

Agent使用以下插件资源:
- ${CLAUDE_PLUGIN_ROOT}/config/rules.json
- ${CLAUDE_PLUGIN_ROOT}/checklists/review.md
关键点:
  • Agent必须存在于
    plugin/agents/
    目录中
  • Claude使用Task工具启动Agent
  • 文档化Agent的能力
  • 引用Agent使用的插件资源

Skill Integration

Skill集成

Leverage plugin skills for specialized knowledge:
markdown
---
description: Document API with standards
argument-hint: [api-file]
---

Document API in @$1 following plugin standards.

Use the api-docs-standards skill to ensure:
- Complete endpoint documentation
- Consistent formatting
- Example quality
- Error documentation

Generate production-ready API docs.
Key points:
  • Skill must exist in
    plugin/skills/
    directory
  • Mention skill name to trigger invocation
  • Document skill purpose
  • Explain what skill provides
利用插件Skill获取专业知识:
markdown
---
description: 按照标准记录API
argument-hint: [api-file]
---

按照插件标准记录@$1中的API。

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

生成可用于生产环境的API文档。
关键点:
  • Skill必须存在于
    plugin/skills/
    目录中
  • 提及Skill名称以触发调用
  • 文档化Skill的用途
  • 说明Skill提供的功能

Hook Coordination

Hook协同

Design commands that work with plugin hooks:
  • Commands can prepare state for hooks to process
  • Hooks execute automatically on tool events
  • Commands should document expected hook behavior
  • Guide Claude on interpreting hook output
See
references/plugin-features-reference.md
for examples of commands that coordinate with hooks
设计与插件Hook配合工作的命令:
  • 命令可为Hook处理准备状态
  • Hook会在工具事件触发时自动执行
  • 命令应文档化预期的Hook行为
  • 指导Claude解释Hook输出
请参阅
references/plugin-features-reference.md
中关于命令与Hook协同的示例

Multi-Component Workflows

多组件工作流

Combine agents, skills, and scripts:
markdown
---
description: Comprehensive review workflow
argument-hint: [file]
allowed-tools: Bash(node:*), Read
---

Target: @$1

Phase 1 - Static Analysis:
!`node ${CLAUDE_PLUGIN_ROOT}/scripts/lint.js $1`

Phase 2 - Deep Review:
Launch code-reviewer agent for detailed analysis.

Phase 3 - Standards Check:
Use coding-standards skill for validation.

Phase 4 - Report:
Template: @${CLAUDE_PLUGIN_ROOT}/templates/review.md

Compile findings into report following template.
When to use:
  • Complex multi-step workflows
  • Leverage multiple plugin capabilities
  • Require specialized analysis
  • Need structured outputs
结合Agent、Skill和脚本:
markdown
---
description: 全面审查工作流
argument-hint: [file]
allowed-tools: Bash(node:*), Read
---

目标文件:@$1

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

阶段2 - 深度审查:
启动code-reviewer Agent进行详细分析。

阶段3 - 标准检查:
使用coding-standards Skill进行验证。

阶段4 - 报告:
模板:@${CLAUDE_PLUGIN_ROOT}/templates/review.md

按照模板整理审查结果并生成报告。
适用场景:
  • 复杂的多步骤工作流
  • 利用多个插件功能
  • 需要专业分析
  • 需要结构化输出

Validation Patterns

验证模式

Commands should validate inputs and resources before processing.
命令应在处理前验证输入和资源。

Argument Validation

参数验证

markdown
---
description: Deploy with validation
argument-hint: [environment]
---

Validate environment: !`echo "$1" | grep -E "^(dev|staging|prod)$" || echo "INVALID"`

If $1 is valid environment:
  Deploy to $1
Otherwise:
  Explain valid environments: dev, staging, prod
  Show usage: /deploy [environment]
markdown
---
description: 带验证的部署
argument-hint: [environment]
---

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

如果$1是有效环境:
  将应用部署到$1
否则:
  说明有效环境:dev、staging、prod
  显示使用方法:/deploy [环境]

File Existence Checks

文件存在性检查

markdown
---
description: Process configuration
argument-hint: [config-file]
---

Check file exists: !`test -f $1 && echo "EXISTS" || echo "MISSING"`

If file exists:
  Process configuration: @$1
Otherwise:
  Explain where to place config file
  Show expected format
  Provide example configuration
markdown
---
description: 处理配置文件
argument-hint: [config-file]
---

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

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

Plugin Resource Validation

插件资源验证

markdown
---
description: Run plugin analyzer
allowed-tools: Bash(test:*)
---

Validate plugin setup:
- Script: !`test -x ${CLAUDE_PLUGIN_ROOT}/bin/analyze && echo "✓" || echo "✗"`
- Config: !`test -f ${CLAUDE_PLUGIN_ROOT}/config.json && echo "✓" || echo "✗"`

If all checks pass, run analysis.
Otherwise, report missing components.
markdown
---
description: 运行插件分析器
allowed-tools: Bash(test:*)
---

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

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

Error Handling

错误处理

markdown
---
description: Build with error handling
allowed-tools: Bash(*)
---

Execute build: !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/build.sh 2>&1 || echo "BUILD_FAILED"`

If build succeeded:
  Report success and output location
If build failed:
  Analyze error output
  Suggest likely causes
  Provide troubleshooting steps
Best practices:
  • Validate early in command
  • Provide helpful error messages
  • Suggest corrective actions
  • Handle edge cases gracefully

For detailed frontmatter field specifications, see
references/frontmatter-reference.md
. For plugin-specific features and patterns, see
references/plugin-features-reference.md
. For command pattern examples, see
examples/
directory.
markdown
---
description: 带错误处理的构建
allowed-tools: Bash(*)
---

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

如果构建成功:
  报告成功及输出位置
如果构建失败:
  分析错误输出
  建议可能的原因
  提供故障排除步骤
最佳实践:
  • 在命令早期进行验证
  • 提供有用的错误信息
  • 建议纠正措施
  • 优雅处理边缘情况

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