---
metadata:
  - name: generator
    content: Diplodoc Platform v5.50.6
alternate:
  - https://sourcecraft.dev/portal/docs/en/code-assistant/operations/agent/slash-commands.md
  - https://sourcecraft.dev/portal/docs/ru/code-assistant/operations/agent/slash-commands.md
title: Slash commands in SourceCraft Code Assistant
description: How to create and use custom rules in SourceCraft Code Assistant to automate repetitive tasks.
---
> **Documentation Index:** Fetch the complete configuration index at https://sourcecraft.dev/portal/docs/en/llms.txt


# Slash (/) commands in SourceCraft Code Assistant

<!-- source: en/_includes/code-assistant/only-in-vscode.md -->
{% note warning %}

This feature is only available in Visual Studio Code.

{% endnote %}
<!-- endsource: en/_includes/code-assistant/only-in-vscode.md -->

Create custom `/` commands to automate repetitive tasks and extend the Code Assistant's functionality using simple Markdown files.

Enter `/` in the chat to see all available commands or create your own by adding a Markdown file to `.codeassistant/commands/` or `~/.codeassistant/commands/`.

Advantages:
* Workflow automation: turn complex multi-step processes into single commands.
* Command standardization: share commands with your colleagues for consistent practices.
* Context preservation: include project-specific context into each command.
* Quick access: search and auto-suggest for instant command detection.

{% note tip %}

Use quick Code Assistant actions using pre-configured commands: **AI code review with current branch**, **AI code review with main branch**, **Commit description**, **Code refactoring**, **Test generation**.

{% endnote %}

## Creating custom commands {#command-creation}

Custom commands extend Code Assistant's functionality by adding Markdown files to specific directories:
* Project-specific commands are located in `.codeassistant/commands/` in your workspace directory.
* Global commands are located in `~/.codeassistant/commands/` in your home directory.

The file name becomes the command name. Here is an example:
* `review.md` → `/review`
* `test-api.md` → `/test-api`
* `deploy-check.md` → `/deploy-check`

{% note info %}

When creating commands via the user interface, command names are processed automatically:
* They are converted to lower case.
* Spaces are replaced with hyphens.
* Special characters, except hyphens, are removed.
* Multiple sequential hyphens are replaced with a single one.
* Hyphens at the beginning and end are removed.

> For example, `My Cool Command!` changes to `my-cool-command`.

{% endnote %}

### Basic command format {#base-format}

Create a simple command by adding a Markdown file:

```markdown
# review.md
Please check this code for:
* Performance issues
* Security vulnerabilities
* Code style violations
* Potential errors
```

### Advanced command with metadata {#advanced-format}

Add metadata for extended functionality:

```yaml
---
description: Comprehensive code review with emphasis on security and performance
argument-hint: <file or directory for check>
---
# Security-prioritized code review
Please perform a thorough security review of the selected code:
1. Authentication and authorization:
    * Check access control for correctness.
    * Make sure tokens are checked.
    * Check permissions.

2. Input validation:
    * Identify potential injection points.
    * Check data cleanup for correctness.
    * Check data type validation.

3. Security best practices:
    * Search for secrets in code.
    * Check communication security.
    * Check error processing for information leaks.
```

Metadata fields:
* `description`: Displayed in the command menu to help users understand the purpose of the command.
* `argument-hint`: Optionally, offers a hint on what arguments the command is expecting to get. For more information, see [Argument hints](#argument-hints).

## Using slash (/) commands {#slash-commands}

Enter `/` in the chat to see a menu of all available commands. The menu presents custom workflow commands, mode-switching commands, and built-in commands – all in the same interface.

Start entering text to filter commands. For example, if you enter `/sam` you will see `sample-command-name`.

You can view command descriptions in the menu.

Project commands override global commands of the same name.

## Argument hints {#argument-hints}

Argument hints provide instant help for slash commands by showing what information you need to provide as the command is awaiting additional input.

As soon as you type `/` to open the command menu, commands that are waiting for arguments will display a hint. This hint indicates what type of argument is expected.

> Here is an example:
> * `/mode <mode_slug>`: The `<mode_slug>` hint indicates that you need to provide the mode name, e.g., `code` or `debug`.
> * `/api-endpoint <endpoint-name> <http-method>` indicates that you need to provide both the endpoint name and HTTP method.

After you select the command, it will be inserted into the chat input field with a space. 

{% note info %}

The hint will not go into the chat. It is just a visual guide to help you figure out what to enter next. As a next step, you need to manually enter the argument after the command.

{% endnote %}

### Adding argument hints to custom commands {#adding-argument-hints-to-custom-commands}

You can add argument hints to your custom commands using the `argument-hint` field in command metadata:

```yaml
---
description: Create a new best-practice REST API endpoint
argument-hint: <endpoint_name> <HTTP_method>
---
```

In the command menu, it will be displayed as `/api-endpoint <endpoint-name> <http-method>`.

## Recommendations {#recommendations}

Command names:
* Use descriptive, action-oriented names.
* Keep the names concise but clear.
* Use hyphens for multi-word commands.
* Avoid general names, such as `help` or `test`.

Command contents:
* Start by giving a clear direction.
* Use structured formats (lists, sections).
* Include specific requirements.
* Reference general project conventions.
* Keep commands focused on a single task.

Organization:
* Group related commands into subdirectories.
* Use consistent naming templates.
* Document complex commands.
* Control your command versions.
* Share commands in the project repository.