Slash Commands in AI Coding Assistants: Built-In, Bundled, and Custom

In AI coding tools, many people still explain what they want in plain language over and over: clear the context, switch models, look at what just changed, compact a conversation that has grown too long, and finally generate a commit message. Experienced users collapse these frequent operations into a single slash command — one instruction instead of a paragraph. They go one step further: they package the workflows they repeat every day into commands of their own and share them within the team. The efficiency difference comes down to two things — less repeated description and a consistent execution standard — not some mysterious trick.

This article covers how slash commands are triggered, how the three types of entries that share the same menu differ, which commands are worth turning into muscle memory, and how to build and share your own commands along with the pitfalls to avoid.

1. How Slash Commands Are Triggered: Two Things to Verify in Your Own Tool

A slash command is a shortcut instruction triggered by typing / at the beginning of the input box. After you type /, the tool usually lists dozens of available functions, so you don’t have to memorize anything — you can browse and pick.

Two rules are worth confirming first:

• Rule 1: Where the command is recognized differs by product. In most AI coding assistants, a slash command is recognized only at the start of a message. However, different products may also support natural-language invocation, context menus, keyboard shortcuts, or other trigger methods, and some versions even allow triggering mid-sentence. Don’t treat this as a universal rule across tools — go by the official documentation for the tool and version you use.
• Rule 2: Text after the command name is usually passed in as an argument. For example, if you follow a model-switching command with a model identifier, that identifier is the argument being passed in. This means commands aren’t always “click and run a fixed action” — they can be invoked with context and options. Different tools support different argument syntaxes, commonly placeholders such as $ARGUMENTS, $1, $2, or {{args}}, so check the documentation.

One risk worth flagging: arguments enter the command context verbatim, so don’t paste sensitive information into them — account credentials, passwords, tokens, ID numbers, customer data, and the like — especially when you’re using cloud-hosted models or shared sessions.

2. The Three Types Mixed Together in the Menu Are Not the Same Thing

Entries in the command menu look alike and feel consistent, but they come from three different sources and have different capabilities. Sorting out the categories keeps everything that follows from getting muddled.

Category	Origin	Typical characteristics	Example commands	Common use cases	Can the AI trigger it automatically?
Built-in commands	Shipped with the tool, behavior hard-coded in the program	Act directly on the tool or session state	Clear, compact, view diff	Session management, trimming context, prep before a code review	Generally no
Bundled skills and workflows	A set of “instruction-shaped” commands preconfigured by the vendor	Essentially a prompt handed to the AI to execute	Code review, run script	Standardized processes, repetitive quality checks	Usually depends on the tool, configuration, and command definition
Custom commands	Created by you or your team	Turn a frequent instruction or workflow into a single command name	Whatever name you define	Team conventions, specialized checks, fixed output formats	Depends on the tool and configuration

How do you tell whether a given command can be triggered by the AI automatically? Three practical checkpoints:

1. Read the command description: menu entries or documentation usually indicate whether something is an auto-invocable skill (skill / agent / workflow, and so on).
2. Check the permission settings: many tools expose a per-skill switch in the settings panel for “allow automatic execution / manual invocation only / disabled”.
3. Check the official documentation: the logic, matching conditions, and priority used to decide automatic triggering are defined there. Don’t guess.

3. Built-In Commands: They Operate on the Tool Itself

Built-in commands ship with the tool and their behavior is hard-coded. They don’t change the AI’s “thinking”; they act directly on the session or tool state. The command names below are common spellings only — naming may differ between products, so go by the menu in your own tool:

Scenario	Example command	Argument example	Notes
Clear context	/clear, /new	Usually none	Cannot be undone; save important conclusions elsewhere first
Compact the conversation	/compact	/compact keep interface contracts and open questions	Compacting loses detail; in long sessions, summarize key conclusions manually first
View changes	/diff, /changes	/diff HEAD~1	For large changes, review directory by directory to avoid missing anything
Switch model	/model	/model <model-id>	Use the model identifiers your tool supports
Generate a commit message	/commit	/commit add related ticket number	Review the result by hand to make sure no sensitive content slipped in

What these have in common: they target the tool or session itself, and using a command is faster, more precise, and less ambiguous than describing the action in natural language. This is the group worth turning into muscle memory.

4. Bundled Skills and Workflows: Manual by Default, Sometimes Automatic

Vendors usually preconfigure a batch of “skill-shaped” commands — code review, running scripts, generating tests, and so on. Their biggest difference from built-in commands: they are essentially an instruction handed to the AI to execute, not hard-coded program logic.

Two consequences follow. First, they can be invoked manually, handing a standard action off with one keystroke. Second, they may be triggered automatically by the AI — but note that this depends on the product you use, its configuration, permissions, and the command definition itself; it is not on by default everywhere. If you find the AI using one when it shouldn’t, or skipping one when it should, adjust it explicitly in the permission settings, or switch to manual invocation for a more predictable setup.

5. Custom Commands: Turn Frequent Workflows into Files

When a combination of instructions gets typed a dozen times a day, it’s time to solidify it into a custom command. The value is threefold: consistency (the same input follows the same execution logic), reuse (one command name replaces a long description), and shareability (a command is a text file, so it can be version-controlled alongside your code).

Where to put them: paths depend on your tool

Example paths (common conventions only — the actual directory, file extension, and loading mechanism depend on your tool’s documentation):

• .commands/ (the convention in some tools)
• .cursor/commands/ (the convention in Cursor-family tools)
• .claude/commands/ (the Claude Code convention)
• A user-level directory (such as ~/.commands/) for reuse across projects

Naming rules

• Use lowercase letters and hyphens, such as review-pr.md; avoid spaces, capitals, and non-ASCII filenames, which cause compatibility problems.
• The filename is the command name: /review-pr maps to review-pr.md.
• Use directories for grouping, such as test/unit.md; most tools map this to a hierarchical command name.
• Agree on a team prefix convention, for example team-lint, team-release, to avoid colliding with built-in commands.

Argument placeholders

Put placeholders in the body text and they get substituted at invocation time. Common forms are $ARGUMENTS (the whole argument string), $1/$2 (positional arguments), and {{args}}. Confirm the exact syntax in the documentation — when you get it wrong, the symptom is usually arguments being handed to the AI as ordinary text.

# Example path: use whatever your tool expects (e.g., .commands/review-pr.md)
Please review the changes in $1 against the main branch, focusing on:
1. Whether boundary conditions and error handling are complete;
2. Whether there are any obvious performance risks;
3. Whether naming and comments follow team conventions.
Additional constraints: $ARGUMENTS
Output format: grouped by file, with each issue and a suggested fix listed individually.

Invocation example: /review-pr origin/main only report high-risk issues.

Refreshing and troubleshooting

• Changes to a file don’t take effect: most tools scan the command directory at startup, so after adding or editing a command you need to restart the session or run the operation that refreshes the command directory (some tools offer a /reload-style command).
• The command doesn’t appear in the menu: check, in order, whether the directory name is correct, whether the extension is recognized, whether it sits in a project-level rather than user-level directory, and whether the filename contains invalid characters.
• Arguments aren’t substituted: your placeholder syntax doesn’t match this tool — check the documentation and switch to the correct form.
• The command produces odd results: first look for ambiguous or double-meaning wording in the command file’s instructions, then check whether an external script is being referenced by mistake.

6. Quick Reference: Six High-Frequency Commands

The command names below are common spellings; naming and argument support vary by tool, so go by your own menu and documentation.

1. Clear context — Example: /clear; Arguments: usually none; Notes: cannot be undone, so export important conclusions first.
2. Compact the conversation — Example: /compact; Arguments: /compact keep interface contracts and open items; Notes: detail is lost, so record key decisions separately.
3. View changes — Example: /diff; Arguments: /diff HEAD~3, --staged; Notes: review in batches when the changeset is large.
4. Generate a commit message — Example: /commit; Arguments: /commit link JIRA-1234; Notes: review manually before committing so secrets and internal addresses don’t end up in the message.
5. Code review — Example: /review-pr; Arguments: /review-pr origin/main focus on concurrency; Notes: the review scope is determined by the arguments — get the scope wrong and the conclusion isn’t trustworthy.
6. Run tests — Example: /test; Arguments: /test tests/auth, /test --watch; Notes: check whether the tests write to real data or call external services, and switch to an isolated environment if needed.

How to choose: use built-in commands for anything that only touches session or tool state; use bundled skills when there’s a defined standard process and you want to reuse the vendor’s best practices; build your own commands for team conventions, fixed output formats, and anything that needs to run the same way repeatedly.

7. Sharing Custom Commands with Your Team: Security and Compliance First

Custom commands are plain text, which makes them a natural fit for living in a repository: git add them to the project, get them merged in review, and team members can use them as soon as they pull. That turns “how this team does things” into an executable asset. But a few things must be handled before you share:

• Never put sensitive content in a command file: no accounts, passwords, tokens, API keys, customer data, or non-public internal information. The file gets distributed with the repository and may end up in a cloud model’s context.
• Sanitize before sharing: replace real hostnames, internal addresses, business unit names, and real ticket numbers in your examples with placeholders.
• Grant least privilege: if a command invokes scripts or reaches into external systems, grant only the permissions needed to complete the task. For destructive actions (deleting branches, force pushing, running SQL), prefer defaulting to “print a list of proposed operations for confirmation” and let a human approve and run them.
• Don’t run unreviewed scripts: a command file is effectively an executable instruction, so review it like code before merging. For community command files of unknown provenance, read them through before enabling them.
• State version boundaries: the placeholder syntax and directory conventions a command depends on change as tools are upgraded. Note at the top of the file something like “requires tool X version X or later”.

8. Common Mistakes and a Path to Proficiency

What are the common mistakes with slash commands?

• Typing / in the middle of a sentence, so the command isn’t recognized and is treated as an ordinary character.
• Putting arguments before the command name, or having the tool treat them as body text rather than arguments.
• Editing a command file without refreshing the command directory, then concluding the configuration doesn’t work.
• Hard-coding project paths or branch names in a command, which breaks the moment the environment changes.
• Writing commands that are too broad (such as “take a look at my code”), producing output you can’t control. Specify the checks and the output format instead.

A pragmatic progression:

• Beginner: turn the highest-frequency actions — clearing context, compacting the conversation, viewing changes — into reflex.
• Intermediate: try the vendor’s bundled skills, observe which scenarios trigger automatically and which don’t, and learn to hand standard processes off.
• Advanced: inventory the instruction combinations you repeat most each week, package three to five of them as custom commands, and commit them to the repository for the team to share after review.

A few principles hold throughout: when a command will do, don’t describe it in natural language, especially for actions that operate on the tool itself; make good use of arguments so one command fits more scenarios; and turn stable processes into files promptly instead of typing them out again each time.

A slash command looks like just one character at the start of the input box, but behind it is an engineering mindset: abstracting repetitive work into reusable assets. Get fluent with built-in commands, use bundled skills effectively, and package your own high-frequency workflows into commands and share them safely — and your command of AI coding tools moves from “can chat” to “can orchestrate”.