If you have been using Claude Code for more than a few sessions, you have probably noticed the / prefix popping up in examples and documentation. This Claude Code slash commands tutorial is your definitive guide to understanding what those commands actually do, how they differ from skills, and — most importantly — how to use them strategically to cut friction out of your development workflow. We will cover built-in commands, how arguments work, and walk through real skill files that power custom commands you can add today.
What Slash Commands Are (and Are Not)
Slash commands in Claude Code fall into two distinct categories that are easy to conflate.
The first category is built-in commands — hardwired shortcuts that ship with Claude Code itself. These include things like /help, /clear (to wipe the conversation context), /compact (to summarize and compress long context), and /cost (to view token usage for the current session). You do not configure these; they work out of the box in any project.
The second category is custom commands, which are powered by skill files — Markdown files stored in .claude/commands/ at the project level or ~/.claude/commands/ globally. When you type /write-tests or /pre-deploy-checklist, Claude Code looks up the corresponding .md file, reads the instructions inside it, and executes the workflow. The slash command is just the interface; the skill file is the logic.
This tutorial focuses on both layers: using built-in commands well, and building custom commands that fit your exact workflow.
Built-In Slash Commands You Should Know
Most developers discover these by accident. Knowing them deliberately makes a real difference.
/clear resets the conversation context completely. Use this when you switch tasks mid-session and do not want stale context from a different file or feature bleeding into a new request. It is the equivalent of opening a fresh terminal tab — fast and clean.
/compact is subtler and more useful for longer sessions. Instead of clearing context, it asks Claude Code to summarize the conversation so far into a compressed form and continue from that summary. You keep the thread of what you were working on without burning tokens on raw history. Use this after a big refactor discussion before asking follow-up questions.
/cost displays how many tokens the current session has consumed and what that maps to in API cost. Useful when you are running Claude Code with your own API key and want to stay aware of usage before a long agentic task.
/help lists all available commands, including any custom ones you have defined. It is the fastest way to audit what commands are loaded in a given project.
/resume (where available) lets you continue a previous conversation session rather than starting fresh. Handy when you close your terminal mid-task and come back the next morning.
Claude Code Slash Commands Tutorial: Custom Commands in Depth
Custom slash commands are where Claude Code becomes a genuinely programmable tool. The command name is simply the filename (without the .md extension) of a skill file in the commands directory. The content of that file is the full prompt Claude Code will execute.
Here is a concrete example. Suppose your team consistently forgets to check for accessibility issues before merging front-end changes. Instead of reminding people manually, encode the check as a command.
Create .claude/commands/a11y-check.md:
---
name: a11y-check
description: Audit the specified component or page file for accessibility issues before merge.
---
You are performing an accessibility audit on a front-end file. Follow these steps exactly:
1. Read the target file provided as an argument (e.g., `src/components/Modal.tsx`).
2. Identify all interactive elements: buttons, links, form inputs, dialogs, and custom components.
3. Check each element for the following issues:
- Missing or non-descriptive `aria-label` / `aria-labelledby` attributes
- Interactive elements unreachable by keyboard (missing `tabIndex`, `role`, or focus handlers)
- Images missing meaningful `alt` text (decorative images must use `alt=""`)
- Color contrast issues called out in inline styles or Tailwind classes (flag classes like `text-gray-300` on light backgrounds)
- Form inputs missing an associated `<label>` element or `aria-label`
4. For each issue found, output:
- File path and line number
- A one-line description of the problem
- A corrected code snippet that resolves it
5. If no issues are found, output: "No accessibility issues detected in [filename]."
6. Do not modify any files. Output only the audit report.
Once this file exists, any developer on the team can run:
/a11y-check src/components/Modal.tsx
Claude Code reads the skill, substitutes the argument, and produces a structured audit report. The check is reproducible, reviewable, and shareable — because it is just a file.
Passing Arguments to Slash Commands
Custom commands become significantly more powerful when they accept arguments. Claude Code passes anything you type after the command name into the skill's context automatically. The convention is to reference the argument naturally in your instructions.
Here is a second example — a skill for generating a structured changelog entry from a branch diff:
---
name: changelog-entry
description: Generate a formatted changelog entry from the diff of a named branch against main.
---
You are generating a changelog entry for a software release. Follow these steps:
1. Run `git diff main...$1` to get the full diff for the branch provided as an argument.
If no argument is given, use the current branch (`git branch --show-current`).
2. Analyze the diff and group changes into these categories (omit any category with no changes):
- **Added** — new features, new API endpoints, new components
- **Changed** — modifications to existing behavior or interfaces
- **Fixed** — bug fixes
- **Removed** — deleted code, deprecated features, removed flags
- **Security** — any change with a security implication
3. Write each entry as a single, past-tense sentence starting with a verb.
Good: "Added pagination support to the `/users` API endpoint."
Bad: "We added some pagination stuff."
4. Format the output as a Markdown section:
## [Unreleased] — <today's date>
### Added
- ...
### Fixed
- ...
5. Do not include trivial changes: formatting-only commits, dependency bumps under one major version, or test-only changes unless they fix a known flaky test.
6. Output only the Markdown section. Do not explain your reasoning.
To use this, a developer runs:
/changelog-entry feature/user-pagination
Claude Code diffs the branch, categorizes the changes, and outputs a publication-ready changelog block. What used to take ten minutes of manual reading and writing takes seconds.
Organizing Commands for a Team
Once you have more than a few custom commands, the .claude/commands/ directory becomes a first-class part of your repository — as important as your linting config or CI workflow. A few practices that scale well:
Commit the directory. Adding .claude/commands/ to version control means every engineer who clones the repo immediately has the full command library available with zero setup. Onboarding a new developer means they inherit the team's accumulated workflow knowledge on day one.
Treat skill files like code in review. When someone adds or changes a skill, the diff is readable and reviewable. You can discuss the instructions the same way you would discuss implementation logic in a PR.
Keep names predictable. If your team uses a prefix convention — test-* for testing commands, doc-* for documentation tasks, deploy-* for release steps — tab-completion in Claude Code becomes genuinely useful. Typing /test- and seeing a list of three focused commands is far better than scrolling through a flat alphabetical list.
Put global utilities in ~/.claude/commands/ and project-specific logic in .claude/commands/. A /summarize-pr command that works across all your repos belongs globally. A /seed-db command tied to a specific project's schema belongs locally.
A Note on Command Discovery
One of the most overlooked features: running /help in any Claude Code session gives you a list of every available command — both built-in and custom — loaded for that session. The output includes the description field from each skill's frontmatter, which is why writing a precise, single-sentence description matters. It is what you read when you have forgotten exactly what a command does six weeks after writing it.
If a command is not showing up, the two most common causes are a filename that is not lowercase-hyphen-separated, or the file being placed in the wrong directory. Double-check the path and filename before debugging anything else.
From Commands to a Workflow System
A single slash command saves you from retyping a prompt. Ten well-designed commands start to feel like a custom IDE extension built for your exact stack and conventions. The key insight is that slash commands are not just shortcuts — they are a way to encode institutional knowledge into something executable.
The team that writes down "here is how we audit accessibility" or "here is how we write a changelog entry" in natural language, then turns that natural language into a skill file, has done something valuable: they have made their process both explicit and automatable.
Ready to build custom slash commands without writing the skill file from scratch? SkillMinter takes a plain-language description of what you want to automate and generates a complete, production-ready Claude Code skill file in seconds — properly formatted, instruction-complete, and ready to drop into your .claude/commands/ directory.