AI Coding CLI Slash Commands: From Using Them to Using Them Well

1. Start with the positioning: what problem do slash commands actually solve?

In command-line AI coding assistants, a slash command is a shortcut entry point triggered by the first character you type into the input box. Press / and a list of the commands available in the current session appears; keep typing and the list is filtered live. Slash commands do not make the model smarter. They solve three engineering problems:

1. Interaction cost. Clearing context, switching models and reasoning effort, reviewing what changed in the current turn, compacting an over-long conversation, generating a commit message — these used to be descriptive requests, and now they are a single keystroke.
2. Ambiguity of expression. When the same instruction is restated in natural language over and over, wording drifts and so does the model’s understanding. A command is a stable contract.
3. Asset reuse. High-frequency workflows can be formalized, reviewed, versioned, and shared across a team instead of living in one person’s head.

A useful rule of thumb: the third time you say almost the same thing to the model, consider turning it into a command. One-off tasks with fuzzy requirements are best left in natural language, which stays the most flexible; only recurring, structurally fixed operations are worth formalizing. Mixing the two is the root cause of most bad experiences with this mechanism — writing every request as a command bloats the command library until nobody maintains it.

2. Know where commands come from: they sit side by side in the menu but have very different capabilities

Entries in the / menu look consistent, but they come from three different sources. Understanding this layering is the foundation for everything that follows.

Type	Who defines the behavior	Can the model trigger it automatically	Typical use cases
Built-in commands	Hard-coded in the program, handled by the CLI’s own logic	No	Context clearing and compaction, model switching, session resume, config inspection, exit and help
Instruction-style workflow commands	A predefined prompt/workflow definition handed to the model to execute	Yes	Code review, running tests, generating commit messages, refactoring suggestions
Custom commands	A Markdown file you write yourself	Depends on configuration	Team convention checks, pre-release self-checks, fixed-format retrospective reports

The key difference is the execution owner. Built-in commands do not consume model context; their behavior is predictable and fast. The other two are essentially “a prompt packaged as a verb” — they occupy the context window, so text length translates directly into token cost. This is frequently overlooked when teams build command assets.

Two trigger rules also need to be remembered:

• Commands are only recognized at the start of a message. A / appearing mid-sentence does not trigger anything, which is easy to trip over when writing paths or regular expressions.
• Text after the command name is passed in as arguments — for example, in /<command-name> sonnet, sonnet is the argument. Whether arguments are used, and whether they are received positionally or as one block, depends on the command’s own definition.
• Specific command names, arguments, and metadata fields differ between tools and versions. Treat the documentation for the version of the tool you are using as the source of truth, and do not hard-code them into scripts from memory.

3. The built-in commands worth turning into muscle memory

You do not need to memorize all of them. Across the dozens available, only five groups are high-frequency.

Context management. Long sessions are the first killer of agentic coding: the longer the context, the worse the model follows early constraints, while cost and latency rise in step. Three habits are worth forming — clear context before switching tasks, actively compact when context approaches its limit (keep conclusions and decisions, discard process output), and resume the previous session when continuing work across days rather than restating requirements from scratch. Whether compaction is needed is judged by “has the task goal changed”, not by the number of messages.

Model and reasoning-effort switching. Exploratory design and complex defect localization deserve a stronger model; deterministic work like bulk renaming, formatting, and writing comments is faster and cheaper on a lighter one. Treat it as gear selection, not “more expensive is always better”.

Change review. Before committing, have the tool list which files and which lines changed in this round, then decide whether to generate a commit message. Skipping this step and committing directly is the most expensive form of shortcut in AI-assisted programming — a bad change landing on the mainline costs far more to fix than the review would have cost.

Permissions and tool allowlists. Actions such as running commands, writing files, and network access should have boundaries. A tool allowlist/permission configuration file at the project root keeps “read-only analysis” and “writes allowed” modes consistent across a team instead of relying on verbal agreements.

Observability. Session logs, execution logs, cost statistics, and diagnostic output are the only evidence available when you need to work out “why did it behave oddly this time”. Reading the logs beats asking the model the same question again.

4. Packaging high-frequency workflows as custom commands

A custom command is essentially a Markdown file with metadata. The filename is the command name, and the body is the prompt template. The placement level usually determines scope: a user-level directory applies to all projects (personal habits), while a project-level directory is committed with the repository and applies to the team (team conventions).

An example review command you can put to work immediately:

---
description: Review a given scope of changes against team conventions
argument-hint: "[staged | branch name | file path]"
allowed-tools: Read, Grep, Bash(git diff:*)
---
You are a senior code reviewer. Review the changes in the scope given by
$ARGUMENTS and report in this order:
1. Correctness risks: boundary conditions, concurrency, error paths, resource release
2. Security: injection, missing authorization checks, hard-coded secrets
3. Maintainability: duplicated logic, cyclomatic complexity, naming
4. Test gaps: which branches are not covered
Constraints:
- For every finding, give `file:line` plus a concrete suggested fix; no vague conclusions
- Do not rewrite whole files; show diff fragments only
- For categories with no issues, state "None" explicitly; do not pad the list

A few conventions are worth standardizing when writing custom commands (supported by most tools, though you should still confirm the exact syntax against the documentation):

• Argument placeholders. Expose the variable parts as $ARGUMENTS, or reference them positionally as $1, $2, so branch names and paths are never hard-coded.
• Context injection. Put a shell command in the body; its output gets embedded in the prompt. This is a good way to feed dynamic facts such as the current diff, a list of failing test cases, or dependency versions.
• File references. Reference convention documents, interface definitions, or decision records in the repository so the command carries its own domain context.
• Subdirectories as namespaces. Organizing commands by topic creates natural groupings in the menu, so the list stays manageable as it grows.

For template structure, a fixed four-part layout works well: role → task → constraints → acceptance criteria. Most cases of “the model’s output was not what I expected” trace back to at least one of these four sections being missing. Do not skimp on constraints in particular — it is the main lever for pulling a general-purpose model back onto team conventions.

5. How commands, skills, and sub-agents divide the work

The three are easy to confuse, but the trade-off is clear:

• Commands: invoked explicitly by a person, deterministic behavior. Fit for “I do this every time and the steps are fixed”.
• Skills/workflows: triggered automatically when the model judges the current task to match. Fit for “used conditionally, and I can’t say exactly when it should apply”.
• Sub-agents: run in parallel inside an independent context window. Fit for exploratory retrieval and large-scale scans that generate a lot of intermediate noise, keeping the main context clean.

The practical recommendation is to combine them: commands own the entry point and the constraints, skills load domain knowledge on demand, and sub-agents isolate the dirty work.

6. Sharing and governing across teams: commands are code

Once a command enters a repository, it becomes an engineering asset and deserves the same level of management:

1. Review. Constraints written into a command body steadily affect everyone’s output quality, so changing one should go through review just like a CI configuration change.
2. Permission tiers. Mark commands that perform writes or execute operations explicitly, and pair them with a tool allowlist to limit their reach. For destructive operations, write into the template that the plan must be shown first and executed only after confirmation.
3. Context budget. Keep command bodies within a few dozen lines. Beyond that, split into “command + referenced convention document”, otherwise the command itself squeezes the task context.
4. Minimize parameters. The more parameters, the easier it is for callers to pass the wrong thing. Anything that can be inferred automatically from repository state, such as the current branch or the changed scope, should not be a parameter.
5. Versioning and documentation. Let commands evolve with the code, and list the command inventory, purpose, and applicable boundaries in the repository README. Promote a personal habit to team level only after it has stabilized.
6. Measure the effect. Track invocation frequency and rework rate per command. A command nobody uses over time, or one that needs manual correction every time, should be refactored or deleted.

If you want to connect command assets further with engineering processes, you can add unified validation in enterprise code hosting and pipelines (check metadata format on commit, verify that referenced files exist), and use general capabilities such as permission management, audit logs, monitoring, and alerting on cloud platforms to make “who ran which command, doing what, at what time” traceable. The principle here is general engineering practice; confirm the specific capabilities against your platform’s documentation.

7. A answer skeleton for interview questions

When asked “what practical tips are there for slash commands”, the layered answer order is: classify first, then scenarios, then governance.

1. Concepts and trigger rules: first-character recognition, argument passing, menu filtering.
2. The three sources: built-in control commands, instruction-style workflows, and custom commands — plus the execution-owner difference (whether context is consumed).
3. High-frequency built-in capabilities: context clearing/compaction/resume, model and reasoning-effort switching, change review, permissions and tool allowlists, logs and diagnostics.
4. Engineering custom commands: Markdown plus metadata, argument placeholders, context injection, file references, namespaces, the four-part template.
5. Team governance: review, permission tiers, context budget, measurement, and iteration.

A closing line that works: the value of commands lies not in their number, but in turning “the thing that has to be re-explained every time” into a contract that is defined once and reused for the long term — and the only signal for whether something should become a command is how often it repeats.