第 2 卷
支持情况
验证插件目录结构和 manifest 有效性。不 /plugin- [path]✅ 支持带参数时验证当前目录。详见插件参考文 validate 档。
/reload-重新加载所有插件（Skills、Agents、
- 支持
pluginsHooks、MCP/LSP 服务器等）,无需重启。
查看当前已加载的所有 Skills,包括用户级、 /skills✅ 支持项目级和插件级 Skills,并显示预估 token 数量。详见 Skills 文档。
生成 AI驱动的使用洞察报告,分析您的 CodeBuddy Code 使用模式、交互风格、 /insights✅ 支持项目领域、摩擦点等多个维度,并生成可在浏览器中查看的 HTML报告。
自定义斜杠命令（Custom Slash Commands)
这是 CodeBuddy Code最强大的功能之一。您可以将常用的提示(Prompts)、脚本和工作流封装成可复用的自定义命令，从而极大地提升效率。
💡 另请参阅：Skills技能系统 -如果您需要创建 AI 自动识别并调用的专业能力模板，而不是用户手动触发的命令，请查看 Skills文档。
创建自定义命令
自定义命令通过在特定目录中创建 .md (Markdown) 文件来定义。
1.项目级命令：在您的项目根目录下创建 .codebuddy/commands/ 文件夹。此处的命令对所有项目协作者可用。
2.个人全局命令：在您的用户主目录下创建 ~/.codebuddy/commands/ 文件夹。此处的命令在您所有的项目中都可用。
创建一个命令，只需在上述任一目录中添加一个 .md 文件即可。例如, test.md 文件会自动注册
为 /test 命令。
子目录中的命令命名
您可以在 commands/ 目录下创建子目录来组织您的命令。子目录中的命令会使用冒号分隔的层级
命名结构：
commands/test.md → /test
commands/backend/deploy/staging.md → /backend:deploy:staging
这种命名方式让您可以：
按功能模块组织命令（如 frontend、 backend、 database 等）
创建层级化的命令结构
避免命名冲突，提高命令的可维护性
Frontmatter 与元数据
您可以在 Markdown文件的顶部使用 YAML Frontmatter来定义命令的元数据。
markdown
--- description: "为我的项目运行单元测试并报告结果。"
argument-hint: "[test-file]"
allowed-tools: Bash(npm run:*) model: gemini-3.1-pro ---
请为我运行 `npm run test -- $1` 命令，并总结测试结果。如果未提供测试文件，则运行所有测试。
支持的元数据字段：
字段描述示例
命令的简短描述,会在自动补全提示中显 description"运行单元测试"
示。
"[test-file]" 或 "[pr- 描述命令需要的参数,为用户提供输入提 argument-hintnumber] [priority] 示。
[assignee]"
model指定执行该命令时使用的 AI模型。gemini-3.1-pro
该命令可以使用的工具列表,支持工具细 allowed-toolsBash(git:*), Read 粒度权限控制。
设置为 true 时，命令不会出现在 Skill disable-model- 工具中，只能通过 /command-name 手true invocation 动触发。
💡 注意：如果指定了 allowed-tools ,命令只能使用列出的工具。使用 Bash(git:*) 表示允
许所有 git命令, Bash(git add:*) 表示仅允许 git add 命令。
使用参数
您的自定义命令可以接收参数，就像 Shell脚本一样。有两种方式来处理参数：
方式一：位置参数（$1, $2, $3,...)
按位置访问单个参数。这种方式适合需要在命令的不同部分使用不同参数的情况。
示例： review-pr.md
markdown
--- description: "代码审查"
argument-hint: "[pr-number] [priority] [assignee]"
---
请审查 PR #$1，优先级为 $2，并分配给 $3 进行最终确认。
重点检查以下方面：
- 代码风格和最佳实践
- 性能影响
- 安全问题
- 测试覆盖率
调用 /review-pr 456 high alice 时：
$1 = 456
$2 = high
$3 = alice
方式二：捕获所有参数（$ARGUMENTS)
一次性捕获所有参数。这种方式适合参数个数不确定的情况。
示例： fix-issue.md
markdown
--- description: "修复代码问题"
argument-hint: "[issue-number] [details...]"
---
请修复 issue #$ARGUMENTS，遵循我们的编码标准。
按照以下步骤：
- 理解问题
- 定位根本原因
- 实现修复
- 添加测试
- 验证修复效果
调用 /fix-issue 123 high-priority refactor-auth-module 时：
$ARGUMENTS = 123 high-priority refactor-auth-module