tencent cloud

Slash Commands

Download
Focus Mode
Font Size
Last updated: 2026-09-30 18:15:50
AI-Translated & Reviewed
CodeBuddy Code supports slash commands, allowing you to perform special actions, manage sessions, and customize frequently used workflows in chat.

Built-in Slash Commands

These commands are used to manage your CodeBuddy Code sessions. The following describes the current support status:
Command
Parameter
CodeBuddy Support Status
Description
/help
-
Supported
Display help information and provide guidance on feedback channels.
/clear
-
Supported
Start a new conversation (previous conversations can be restored through /resume).
/login
-
Supported
Log in to your account.
/logout
-
Supported
Log out of the current account.
/doctor
-
Supported
Check the status and environment of CodeBuddy Code.
/status
-
Supported
Display the status of the current repository and session.
/add-dir
<path>
Supported
Add a working directory. Specify the directory path to add.
/agents
-
Supported
Manage built-in and custom AI agents; view the effective routing values and sources of built-in subagents, and save model settings to the Global or Project scope. Scenario-specific models can be viewed in /model.
/branch
[name]
Supported
Create a branch at the current conversation position, copy the active conversation history to a new session, and switch to it automatically. Optionally specify a branch name.
/btw
<question>
Supported
Ask a quick question without interrupting the current Agent workflow. This is useful for temporarily asking a brief question while the Agent is executing a task, with the answer generated based on existing context.
/compact
-
Supported
Compress the context.
/config
[list | get | set]
Supported
View or modify local configuration. When no parameter is provided, an interactive panel opens. list lists current settings, get <key> reads a setting, and set <key> <value> modifies a setting.
/context
-
Supported
Calculate the context token distribution of the current session.
/cost
-
Supported
Display the cost and Token usage of the session.
/init
-
Supported
Initialize a new CodeBuddy repository.
/mcp
-
Supported
Manage MCP connections.
/memory
-
Supported
Manage long-term memory.
/model
[list | model-name]
Supported
Switch or view the main model. When no parameter is provided, an interactive interface opens. list lists available models, and when a model name parameter is provided, the main model is switched directly.
/model:lite
[list | model-id]
Supported
Switch or view the effective model and source of the lite scenario variant (used by lightweight subtasks such as Explore). When no parameter is provided, an interactive selection interface opens (including Global / Project settings). list lists available models, and when a model ID parameter is provided, the switch is performed directly.
/model:reasoning
[list | model-id]
Supported
Switch or view the effective model and source of the reasoning scenario variant (used by complex analysis tasks). When no parameter is provided, an interactive selection interface opens (including Global / Project settings). list lists available models, and when a model ID parameter is provided, the switch is performed directly.
/model:text-to-image
[list | model-id]
Supported
Switch or view the currently used text-to-image model. When no parameter is provided, an interactive selection interface opens. list lists available models, and when a model ID parameter is provided, the switch is performed directly to the specified model.
/model:image-to-image
[list | model-id]
Supported
Switch or view the currently used image-to-image model. When no parameter is provided, an interactive selection interface opens. list lists available models, and when a model ID parameter is provided, the switch is performed directly to the specified model.
/permissions
-
Supported
Manage tool permissions and workspace directory access permissions.
/plan
-
Supported
Preview the content of the plan file in the current plan mode.
/goal
<condition> | clear
Supported
Work continuously until the condition is met. /goal <condition> sets a goal condition (for example, /goal all tests pass), registers a prompt-type Stop hook at the session level, and each time the model wants to stop, a small model evaluator determines whether the condition is met; if not, the reason is injected into the history to make the model continue working. /goal without parameters opens the recap panel, and /goal clear (aliases: stop / off / reset / none / cancel) ends the goal early. For details, see goal documentation.
/upgrade
-
Supported
Open the upgrade page in a browser to view advanced features and subscription options.
/bashes
-
Supported
List and manage background tasks.
/terminal-setup
-
Supported
Configure the Shift+Enter shortcut binding to insert a line break in the input box.
/todos
-
Supported
Display the list of to-do items in the current session.
/statusline
-
Supported
Configure the terminal status line display to show session information, model status, and more.
/security-review
-
Supported
Perform a code security review of the current branch. A senior security engineer conducts a focused security review to identify high-confidence security vulnerabilities.
/theme
-
Supported
Open the theme selection panel to select and preview different terminal themes (dark, light, colorblind-friendly, ANSI, and more).
/export
-
Supported
Export the current conversation to a file or the clipboard.
/feedback
-
Supported
Open the feedback page to submit Bug reports or feature suggestions.
/fork
[name]
Supported
Create a branch at the current conversation position (an alias of /branch). Copy the active conversation history to a new session and switch to it automatically. You can return to the original conversation through /resume.
/resume
[list | session-id]
Supported
Resume a previous session. If no parameter is provided, an interactive panel opens. list lists all sessions. If a session-id is provided, switch directly to the specified session.
/rewind
-
Supported
Rewind the conversation to a previous message point. You can choose to rewind only the conversation, only the code, or both. For details, see Checkpoints.
/sandbox
-
Supported
Manage Bash command sandbox mode and control security policies for command execution. For details, see Sandbox Documentation.
/stats
-
Supported
Display usage statistics, including detailed data such as Token usage, model call counts, and session duration. Support both an overview and a by-model breakdown view.
/ide
-
Supported
Manage IDE integration status. You can view the currently connected IDE, switch IDE connections, or disconnect. For details, see IDE Integration Documentation.
/plugin
[action] [args...]
Supported
Manage plugins and plugin marketplaces. If no parameter is provided, an interactive interface opens, supporting operations such as marketplace add, install, enable, disable, and uninstall. For details, see Plugin Documentation.
/plugin-validate
[path]
Supported
Validate the plugin directory structure and manifest validity. If no parameter is provided, validate the current directory. For details, see Plugin Reference Documentation.
/reload-plugins
-
Supported
Reload all plugins (Skills, Agents, Hooks, MCP/LSP servers, and so on) without restarting.
/skills
-
Supported
View all currently loaded Skills, including user-level, project-level, and plugin-level Skills, and display the estimated number of tokens. For details, see Skills Documentation.
/insights
-
Supported
Generate an AI-driven usage insight report that analyzes multiple dimensions of your CodeBuddy Code usage, including usage patterns, interaction styles, project domains, and friction points, and generates an HTML report viewable in a browser.
/simplify
[target]
Supported
Clean up changed code without altering behavior. Automatically start 4 parallel Agents to review the code from four perspectives: reuse, simplification, efficiency, and abstraction level, then consolidate and apply fixes. Perform quality cleanup only, without looking for correctness bugs (to find bugs, use /code-review).
/code-review
[--fix] [--comment] [target]
Supported
Review the current diff for correctness bugs and code quality issues. Supports --fix to automatically fix discovered issues and --comment to publish findings as inline PR comments. Findings are sorted by severity and include the file, line number, severity level, and fix suggestion.
/verify
[description]
Supported
Verify that code changes work as expected. Automatically identify the change type, run relevant test suites, build checks, and type checks, report test results, and flag failures or warnings.
/copy
[N]
Supported
Copy the latest AI reply to the system clipboard. The optional parameter N specifies the Nth reply (1 = latest, 2 = second latest, and so on), and the reply is also written to the temporary file /tmp/codebuddy/response.md as a backup.
/debug
[issue description]
Supported
Enable debug logging and help diagnose session issues. Automatically read the tail of the current session's debug log (last 20 lines), automatically enable debug logging if it is not enabled, analyze errors and warnings in the log, and provide fix suggestions.

Custom Slash Commands

This is one of the core features of CodeBuddy Code. You can package frequently used Prompts, scripts, and workflows into reusable custom commands, greatly improving efficiency.
Note:
If you need to create professional capability templates that AI automatically identifies and invokes, rather than commands manually triggered by users, see the Skills documentation.

Creating a Custom Command

Custom commands are defined by creating .md (Markdown) files in a specific directory.
1. Project-level commands: create a .codebuddy/commands/ folder in your project root directory. Commands defined here are available to all project collaborators.
2. Personal global commands: create a ~/.codebuddy/commands/ folder in your user home directory. Commands defined here are available in all of your projects.
To create a command, simply add a .md file in any of the directories mentioned above. For example, a test.md file is automatically registered as the /test command.

Command Naming in Subdirectories

You can create subdirectories under the commands/ directory to organize your commands. Commands in subdirectories use a colon-separated hierarchical naming structure:
commands/test.md → /test
commands/frontend/build.md → /frontend:build
commands/backend/deploy/staging.md → /backend:deploy:staging
This naming convention allows you to:
Organize commands by functional module (such as frontend, backend, database, and so on)
Create a hierarchical command structure.
Avoid naming conflicts and improve command maintainability.

Frontmatter and Metadata

You can use YAML Frontmatter at the top of a Markdown file to define command metadata.
---
description: "Run unit tests for my project and report the results."
argument-hint: "[test-file]"
allowed-tools: Bash(npm run:*)
model: gemini-3.1-pro
---

Run the `npm run test -- $1` command for me and summarize the test results. If no test file is provided, run all tests.
Supported metadata fields:
Field
Description
Example
description
A brief description of the command, displayed in autocomplete suggestions.
"Run unit tests"
argument-hint
Describes the parameters required by the command and provides input hints for users.
"[test-file]" or "[pr-number] [priority] [assignee]"
model
Specifies the AI model used when this command is executed.
gemini-3.1-pro
allowed-tools
A list of tools available to this command, with support for fine-grained tool permission control.
Bash(git:*), Read
disable-model-invocation
When set to true, the command does not appear in the Skill tool and can only be triggered manually through /command-name.
true
Note:
If allowed-tools is specified, the command can only use the listed tools. Bash(git:*) allows all git commands, and Bash(git add:*) allows only the git add command.

Using Parameters

Your custom commands can accept parameters, just like Shell scripts. There are two ways to handle parameters:

Method 1: Positional Parameters ($1, $2, $3, ...)

Access individual parameters by position. This approach is suitable when different parameters are needed in different parts of a command.
Example: review-pr.md
---
description: "Code review"
argument-hint: "[pr-number] [priority] [assignee]"
---

Review PR #$1 with priority $2, and assign it to $3 for final confirmation.

Focus on checking the following aspects:
- Code style and practical tutorials
- Performance impact
- Security issues
- Test coverage
When calling `/review-pr 456 high alice`:
`$1` = `456`
`$2` = `high`
`$3` = `alice`

Method 2: Capturing All Parameters ($ARGUMENTS)

Capture all parameters at once. This approach is suitable when the number of parameters is uncertain.
---
description: "Fix code issues"
argument-hint: "[issue-number] [details...]"
---

Fix issue #$ARGUMENTS, following our coding standards.

Follow these steps:
1. Understand the problem
2. Identify the root cause
3. Implement the fix.
4. Add tests
5. Verify the fix.
When calling /fix-issue 123 high-priority refactor-auth-module:
$ARGUMENTS = 123 high-priority refactor-auth-module
Parameter parsing rules: Parameters are separated by spaces. Single quotes and double quotes are supported to handle parameters that contain spaces. For example, /greet "Hello World" passes "Hello World" as a single parameter.

Executing Shell Commands

If you prefix any line of a command with ! and enclose the command in backticks, that line is executed as a Shell command, and its output (stdout) is captured and injected into the context for subsequent AI analysis.
Important:
To execute Shell commands, you must include the Bash tool in the allowed-tools frontmatter. Otherwise, the command cannot be executed.
Example: status.md
---
description: "Display the current git repository status and analyze it."
allowed-tools: Bash(git status:*), Bash(git diff:*)
---

Current git status:
!`git status`

Changes in the current branch:
!`git diff HEAD`

Based on the output above, summarize the current status of the branch for me.
More examples: commit.md
---
description: "Create a git commit."
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git diff:*), Bash(git commit:*)
argument-hint: "[message]"
---

## Current status

- Git status: !`git status`
- Staged changes: !`git diff --cached`
- Recent commits: !`git log --oneline -5`

## Tasks

Based on the information above, create a git commit using the provided commit message: $1

If no message is provided, use the default descriptive message.

File References

Use the @ prefix in commands to include file content. The system automatically reads the file and injects its content into the AI context.
Examples
---
description: "Code review"
---

Please review the following files:

@src/utils/helpers.js
@src/utils/validators.js

Identify potential performance issues and code style issues.

Usage Recommendations

1. Clear and Specific Descriptions

Write clear descriptions and argument hints to help users and AI understand the purpose of the command:
---
description: "Perform a security audit to scan code for potential vulnerabilities and security issues"
argument-hint: "[files...] [--severity high|medium|low]"
---

2. Using Fine-Grained Tool Permissions

Use allowed-tools to limit the tools and operations available to the command:
---
allowed-tools: Bash(npm test:*), Bash(git diff:*), Read
description: "Run tests and compare with the main branch"
---
This is more secure and efficient than allowing all tools.

3. Organizing Commands into Subdirectories

Create logical groups for a large number of commands:
.codebuddy/commands/
├── frontend/
│ ├── build.md
│ ├── test.md
│ └── lint.md
├── backend/
│ ├── migrate.md
│ ├── deploy.md
│ └── logs.md
└── git/
├── commit.md
├── review.md
└── release.md
Usage:
/frontend:build
/backend:deploy
/git:commit "message"

4. Providing Useful Context

Insert useful information before the Shell command is executed:
---
description: "Analyze code coverage"
allowed-tools: Bash(npm run:*)
---

## Current status

Project root directory: !`pwd`
Current branch: !`git rev-parse --abbrev-ref HEAD`

## Tasks

Run tests and generate a coverage report:
!`npm run coverage`

Based on the above results, summarize the code coverage for me.

5. Handling Optional Parameters

Use conditional logic to handle optional parameters:
---
description: "Run specific or all tests"
argument-hint: "[test-file]"
allowed-tools: Bash(npm run:*)
---

If $1 is empty, all tests will be run. Otherwise, the specified test file will be run.

Command: !`npm run test -- $1`

6. Specifying a Specific Model

Specify a model for commands that require specific capabilities:
---
description: "Code complexity analysis"
model: gemini-3.1-pro
---

Analyze the complexity of this code...

Common Usage Scenarios

Scenario 1: Code Review Workflow

Create .codebuddy/commands/code-review.md:
---
description: "Perform code review on the specified file"
argument-hint: "[file-paths...]"
allowed-tools: Read
---

Perform a code review on the following file, focusing on code quality, maintainability, and security:

@$ARGUMENTS

Review points:
1. Code style and naming conventions
2. Function complexity
3. Error handling
4. Performance considerations
5. Security risks

Scenario 2: Automated Deployment

Create .codebuddy/commands/deploy.md:
---
description: "Deploy the application to the specified environment"
argument-hint: "[environment] [version]"
allowed-tools: Bash(npm run:*), Bash(git:*)
---

## Deployment Process

Current version: !`cat package.json | grep version`
Latest tag: !`git describe --tags --abbrev=0`

Target environment: $1
Target version: $2

Preparing to deploy $2 to the $1 environment...

Scenario 3: Project Diagnosis

Create .codebuddy/commands/diagnose.md:
---
description: "Diagnose project status and environment"
allowed-tools: Bash(npm list:*), Bash(git:*), Bash(node --version:*)
---

## Project Diagnostic Report

Node version: !`node --version`
NPM version: !`npm --version`
Git status: !`git status --short`
Dependencies: !`npm list --depth=0`

Based on the information above, summarize the project status and provide recommendations.

Troubleshooting

Commands Not Executing

1. Check the command file location.
Project commands: .codebuddy/commands/*.md
Global commands: ~/.codebuddy/commands/*.md
2. Check the frontmatter format.
Ensure that the YAML syntax is correct.
If allowed-tools is specified, ensure that the tool format is correct.
3. Check Shell command permissions.
If you use the ! prefix to run a command, you must include the Bash tool in allowed-tools.

Parameters Not Replaced Correctly

Ensure that the correct parameter format is used:
$1, $2, and $3 are used for positional parameters.
$ARGUMENTS is used for all arguments.
argument-hint is correctly specified in the frontmatter.

File References Not Working

1. Use absolute paths or paths relative to the project root directory.
2. Ensure that the path contains no spaces, or enclose the full path in quotation marks.
3. Check whether the file exists and is readable.

Tips and Tricks

Version control: Commit project commands to Git so that team members can share them.
Permission control: Use allowed-tools to ensure that commands use only the necessary permissions.
Performance: Avoid time-consuming operations in Shell commands.
Clarity: Use clear naming and descriptions to help the team understand the purpose of the command.


Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback