Slash Commands in AI Coding Assistants: General Concepts and Examples

Why slash commands are worth learning

When you use AI coding assistants for development, many actions do not require long natural-language descriptions. Clearing the conversation context, switching the underlying model, viewing the current changes, compacting a long session history, and generating a standardized commit message can all be done with one slash command.

There is a noticeable efficiency gap between people who know slash commands and those who do not. Users who are unfamiliar with them repeatedly explain their intent in plain language, which wastes time and tokens. Users who know them can handle common operations with a single command and can package frequent personal workflows into custom commands for reuse and sharing across a team.

What is a slash command? Two trigger rules

A slash command is a shortcut instruction triggered by typing / at the beginning of the input. Two rules matter:

• It is only recognized at the beginning of a message: the command must be the first thing in the input. A / in the middle of a sentence will not trigger a command.
• Text after the command name is passed as an argument: for example, in /model sonnet, sonnet is the argument passed to the command.

Support varies by tool: different AI coding assistants differ in command names, argument syntax, configuration directories, and whether custom commands are supported. Behavior may also change after upgrades or plugin installations. Command names, directories, and field names in this article are examples. Always verify against the target tool’s official documentation, the current / menu, or the built-in help. Do not treat them as universal rules.

What are the three sources of slash commands?

The / menu does not show one kind of command. It usually shows three sources:

• Built-in commands: provided by the tool and implemented directly in the program. Examples include /clear for clearing context and /compact for compacting a session. Their behavior is fixed and does not depend on external files.
• Bundled skills and workflows: preinstalled commands that exist in the form of skills, such as /review for code review and /test for running tests. They are essentially instructions given to the AI, and they can be invoked manually or triggered automatically by the AI at appropriate times.
• Custom commands: created by users. They package frequently used instructions or processes as /your-command, usually using Markdown files.

Command source	Built-in	Modifiability	Typical use	Example commands
Built-in commands	Yes	Not modifiable; invoke only	Manage sessions, switch models, view changes	/clear, /compact, /model, /commit
Bundled skills and workflows	Provided by the tool	Usually overridable or disableable	Code review, run tests, generate documentation	/review, /test
Custom commands	No	Fully controlled by you	Team conventions, repeatable process templates	/commit staged, /pr-desc

Command names are examples only and may vary by tool and version.

How to choose high-frequency built-in commands? Four categories and risks

There are many built-in commands, but four categories are especially worth memorizing.

• Context management: clearing the current session, such as /clear, and compacting long conversations, such as /compact. After long development sessions, context can become bloated, and cleaning or compacting it often improves answer quality. Risk: clearing loses existing context, and the AI may “forget” prior agreements or already-read code. Put important conclusions in documentation or code comments first. Compaction is summarization and loses details, so restate key constraints afterward to confirm the AI understood them.
• Model switching: switching the underlying model for different tasks, such as /model. Lightweight models can save cost and improve speed for simple tasks, while stronger models can be used for complex reasoning. Risk: switching models affects response speed, token cost, and output style. In cost-sensitive situations, run a small sample first before batch use, and do not assume that a stronger model is always more cost-effective.
• Code changes: viewing the current changes and generating a commit message, such as /diff and /commit. These commands help you quickly review what the AI changed and turn the changes into a standard commit description. Before using generated commit messages, review them manually to avoid committing unrelated files or debugging code.
• Project context: loading project descriptions or importing rule files to help the AI understand the codebase structure and technical conventions faster.

Common mistakes to check:

• The command is written in the middle of a sentence and is not triggered; put it on the first line.
• The argument name or value is wrong, such as spelling staged as stage.
• The command name does not exist; if you cannot find it in the / menu, it is probably unavailable.
• The context has exceeded the limit, making compaction or answer quality worse.
• A custom command file is placed in the wrong directory, so team members cannot see it when sharing.

How to create custom commands? Directories, arguments, and a complete example

Custom commands turn repetitive work into reusable assets. The core idea is to turn instructions you would otherwise repeat into a template.

Where to place them: custom commands are usually placed in project-level or user-level command configuration directories and implemented as Markdown files. The file name determines the command name, and the file content determines the instruction the AI receives. Example paths:

• Project level: <project-root>/.claude/commands/commit.md. Different tools may use different directory names, such as .cursor/commands/ or .github/prompts/. Check the official documentation for your tool.
• User level: ~/.claude/commands/commit.md. This applies only to you.

Complete example file (commit.md):

---
description: Generate standardized commit messages for the current staged changes
argument-hint: staged | last-commit
allowed-tools: Bash(git diff:*) Bash(git log:*)
---
Target scope: $ARGUMENTS
For changes within that scope only, follow the Conventional Commits specification.
Generate one commit message for each logically independent change, and briefly explain the motivation for the change.
Do not run any git commit or push commands.

Calling with arguments: type the command name in the input box, followed by the argument value. The argument replaces the placeholder in the command body:

/commit staged
/commit last-commit

Arguments are commonly written as $ARGUMENTS for all input, or $1, $2 for positional input. Check the tool documentation for the exact syntax. To make arguments easier to use, add argument-hint in the header to show valid values.

The value of custom commands is that they are write once, reuse long term. Once you put the rules, constraints, and output formats you repeatedly need into a command, you no longer have to explain them every time. Command files can also be tracked by Git, so changes have diffs, history, and can be rolled back.

How to share commands in a team? Security and governance checklist

A major benefit of slash commands is team reuse. If you put command files into the appropriate directory in a project repository, team members can share the same commands after pulling the code. If you put them in a user-level directory, they apply only to you.

Before sharing, review this governance checklist:

• Include them in code review: command files are instructions to the AI and should be treated like code. Require pull request review and do not allow anyone to bypass it.
• Never store sensitive information: do not put API keys, passwords, internal network addresses, or customer data in commands.
• Be careful with internal rules: for unpublished business logic or compliance guidance, make sure the project-level sharing scope matches repository visibility. Do not put internal conventions in public repositories.
• Restrict high-risk actions: custom commands that run shell commands, delete files, or access the network should explicitly declare allowed tool scopes, such as allowed-tools. Avoid a single command opening all permissions.
• Clarify sharing scope: project-level commands travel with the repository and are visible to everyone; user-level commands apply only locally and are suitable for personal habits, not team standards.
• Clean up regularly: low-frequency commands create menu noise. Archive outdated commands regularly.

Summary

A slash command may look like just a / in the input box, but it is an efficiency mechanism. First, distinguish among built-in commands, bundled skills, and custom commands. Then remember high-frequency built-in commands and their risks. Finally, package repetitive personal and team work into custom commands. This can turn an AI coding assistant from a tool that must be re-explained every time into a ready-to-use productivity tool.

FAQ

Q: What is a slash command?
A shortcut instruction triggered by typing / at the beginning of the input. It is used to clear context, switch models, call preset workflows, or execute a user-created template.

Q: How do I create my own command?
Create a new Markdown file in the command configuration directory. The file name becomes the command name. Use description to state the purpose, use the body to specify what the AI should do, and add argument placeholders when dynamic input is needed.

Q: How do teams share commands?
Put command files into the command directory in the project repository and include them in code review. Team members can use them after pulling the code. Personal habits should be placed in the user-level directory.

Q: What should I consider before clearing context?
First put conclusions, decisions, and completed changes into documentation, comments, or commit messages. After clearing, this information cannot be recovered from the session. Compaction also loses details, so restate key constraints afterward to confirm understanding.

Q: Are these commands the same across all AI coding assistants?
No. Command names, argument rules, configuration directories, and custom command support vary by tool. Always follow the official documentation for the current version of your target tool.