Home › Rules › Custom slash commands

Custom slash commands for Claude Code and Cursor: where the files go, arguments, and 7 commands to copy

Built from each tool's own docs, checked Oct 25, 2026. Sources below.

• Guide
• Slash commands
• Claude Code
• Cursor
• Codex
• Copilot
• Skills

Short answer: a custom slash command is a Markdown file with instructions you'd otherwise retype. Save it, then type /its-name to run it. In Claude Code, custom commands are now skills: put the file at .claude/skills/<name>/SKILL.md (the old .claude/commands/<name>.md still works). Cursor's docs now handle slash commands as skills too, in .cursor/skills/<name>/SKILL.md, and Cursor reads .claude/skills/ too, so one file can serve both. Add disable-model-invocation: true if you only want it to run when you type it.

Where command files go in each tool

Claude Code: the file format

Make a folder named after your command inside .claude/skills/ and put a file called SKILL.md in it. The top part, between the --- lines, is the settings (frontmatter). Everything below it is the instructions Claude follows when you run the command. This example is adapted from Claude Code's own docs:

---
name: fix-issue
description: Fix a GitHub issue
argument-hint: [issue-number]
disable-model-invocation: true
---

Fix GitHub issue $ARGUMENTS following our coding standards.

1. Read the issue description
2. Understand the requirements
3. Implement the fix
4. Write tests
5. Create a commit

Running /fix-issue 123 sends Claude "Fix GitHub issue 123 following our coding standards..."

The settings you'll use most (all are optional; Claude Code's docs recommend at least description):

• name: the command you type. Leave it out and the folder name is used.
• description: what it does and when to use it. Claude uses this to decide when to load it on its own.
• argument-hint: the hint shown while you type, like [issue-number].
• disable-model-invocation: true: only you can start it. Good for anything with side effects, like commits or deploys.
• allowed-tools: tools Claude can use without asking, only during the turn you run the command.

Arguments: $ARGUMENTS, $0, $1

• $ARGUMENTS is everything you typed after the command.
• $0 is the first word, $1 the second, and so on ($ARGUMENTS[0] is the long form). Wrap a multi-word value in quotes to keep it together.
• If the file has no placeholder, Claude Code adds what you typed to the end as ARGUMENTS: ..., so Claude still sees it.
• Need a real dollar sign before a number, like $1.00? Write \$1.00.

---
name: migrate-component
description: Migrate a component from one language to another
argument-hint: [component] [from] [to]
---

Migrate the $0 component from $1 to $2.
Preserve all existing behavior and tests.

Run it as /migrate-component SearchBar JavaScript TypeScript.

.claude/commands vs .claude/skills

Both create the same /command. .claude/commands/deploy.md and .claude/skills/deploy/SKILL.md both make /deploy, and your old command files keep working. Claude Code's docs say to prefer skills for new work, because a skill folder can also hold extra files (examples, scripts) and Claude can load it automatically when it fits. A file in a subfolder of commands/ gets a colon in its name: .claude/commands/frontend/component.md becomes /frontend:component.

Project skills in .claude/skills/ can be committed to GitHub so everyone on the project gets the same commands. Personal ones in ~/.claude/skills/ work in all your projects on that computer.

Cursor: commands are skills now

Cursor's current docs cover slash commands as skills. A skill is a folder with a SKILL.md inside .cursor/skills/ (or .agents/skills/) in your project, or ~/.cursor/skills/ for all projects. Cursor also loads skills from .claude/skills/ and .codex/skills/.

• name and description are required. The name must be lowercase letters, numbers and hyphens, and must match the folder name.
• By default the agent can use a skill on its own when it looks relevant. disable-model-invocation: true makes it behave like a traditional slash command: it's only used when you type /skill-name.
• Run one by typing / in Agent chat and picking it, or type @ to attach it as context. Type /create-skill and Cursor walks you through making one.
• Have old Cursor commands? Type /migrate-to-skills (Cursor 2.4+). It converts your user and project commands into skills with disable-model-invocation: true, so they still only run when you call them.
• To see what Cursor found, open Customize in the sidebar and go to Skills.

Using the same file in both tools: the 7 files below sit in .claude/skills/, which Claude Code and Cursor both read. argument-hint, allowed-tools and $ARGUMENTS come from Claude Code's docs; Cursor's skills docs don't list them. In Cursor, type your details right after the command in the same message.

Codex and GitHub Copilot

• Codex: custom prompts (Markdown files in ~/.codex/prompts/, run as /prompts:name) are deprecated. OpenAI's docs say to use skills instead: a SKILL.md folder in .agents/skills/ in your repo, run with /skills or by typing $ and the name. To try the files below in Codex, copy the folders into .agents/skills/ (Codex's docs only show name and description in the frontmatter).
• Copilot in VS Code: prompt files are .prompt.md files in .github/prompts/, run by typing / and the name in the Chat view. They support description, name, argument-hint, agent, model and tools, and run only in Local sessions. VS Code also reads skills from .claude/skills/, and those show up as slash commands too.

Built-in commands cheat sheet

A short list of built-ins from each tool's docs. Type / to see everything your version has.

In the Cursor CLI, /plan, /ask, /model, /clear, /resume, /summarize and /rewind are built in too.

Commands vs skills vs rules: which one?

Rule of thumb from Cursor's docs: use a rule when a short instruction is enough, and a skill when the AI needs a detailed, repeatable process. Claude Code's docs say to keep side-effect jobs like /commit or /deploy manual, because you don't want Claude deciding to deploy because your code looks ready. Full comparison: Cursor rules vs skills.

You can also tell your rules file about your commands:

## Commands
- Our reusable commands live in .claude/skills/ (one folder per command, each with a SKILL.md).
- When I ask for something we do often, tell me which command fits.

7 beginner command files to copy

Make the folder, save the file as SKILL.md, then type / to find it. All of them stay hands-off until you say go.

1. /plan-feature: Plan a feature before building it (an argument + manual-only)

---
name: plan-feature
description: Plan a new feature step by step before writing any code.
argument-hint: [what the feature should do]
disable-model-invocation: true
---

I want to add this feature: $ARGUMENTS

Before writing any code:
1. Ask me up to 3 questions about anything that's unclear.
2. Write a plan with 3 to 6 small steps I can test one at a time.
3. For each step, list the files you expect to change.
4. Say what could break and how I can check it still works.

Use plain English. Don't change any files until I say "go".

Run it as /plan-feature a contact form that emails me. disable-model-invocation: true means the AI never starts this on its own; it runs only when you type it.

2. /explain-error: Explain an error in plain English (paste the error as the argument)

---
name: explain-error
description: Explain an error message in plain English and suggest the smallest fix.
argument-hint: [paste the error]
disable-model-invocation: true
---

Here's the error I got:

$ARGUMENTS

1. Explain what it means in plain English, in 2 or 3 sentences.
2. Find where it comes from in this project and show me the line.
3. Tell me the most likely cause and how sure you are.
4. Suggest the smallest fix. Don't change anything until I say yes.

If you need more information, tell me exactly what to run or paste.

Paste the whole error after the command. If you leave it empty, the steps still tell the AI to ask you for what it needs.

3. /write-tests: Write tests for one file (a file name as the argument)

---
name: write-tests
description: Write simple tests for one file or function and run them.
argument-hint: [file or function]
disable-model-invocation: true
---

Write tests for: $ARGUMENTS

1. Look at how tests are already written in this project and match that style.
   If there are no tests yet, tell me which test tool you'd use and why, and wait for my OK.
2. Cover the normal case, one empty or missing input, and one bad input.
3. Run the tests and show me the result.
4. If a test fails because of a real bug, tell me. Don't change the code under test without asking.

Step 4 keeps the AI from changing your code just to make a failing test pass without telling you.

4. /fix-lint: Fix lint errors without changing behavior (optional argument)

---
name: fix-lint
description: Run the linter and fix the problems it reports without changing what the code does.
argument-hint: [optional: folder or file]
disable-model-invocation: true
---

Fix lint problems in: $ARGUMENTS (if empty, the whole project).

1. Find the lint command this project uses (package.json scripts, a Makefile or the README) and run it.
2. Fix the problems it reports, one file at a time.
3. Don't change what the code does. If a fix would change behavior, list it and skip it.
4. Run the linter again and show me what's left.

Run it as /fix-lint for the whole project or /fix-lint src/components for one folder.

5. /security-check: Quick security check before you publish (manual-only, no arguments needed)

---
name: security-check
description: Check the project for beginner security mistakes before publishing.
argument-hint: [optional: area to focus on]
disable-model-invocation: true
---

Check this project for security problems a beginner might miss. Focus on $ARGUMENTS if I named something.

1. Secret keys, passwords or tokens written in the code or committed to git.
2. Database tables anyone can read or change.
3. Pages or API routes that should need a login but don't.
4. Forms that trust user input without checking it.

List what you find in priority order, with the file and line. Don't change any files yet.

Pairs with our 12-point security checklist. We avoided the names /security-review (built into Claude Code) and /review-security (built into Cursor).

6. /commit-message: Write a commit message from your changes (allowed-tools (Claude Code only))

---
name: commit-message
description: Write a short, clear commit message for the staged changes.
disable-model-invocation: true
allowed-tools:
  - Bash(git status *)
  - Bash(git diff *)
---

Run git status and git diff --staged, then write a commit message:

- First line: under 60 characters, says what changed.
- Then 1 to 3 short bullet points on why.
- If nothing is staged, tell me and stop.

Show me the message. Don't commit until I say so.

allowed-tools lets Claude Code run those two git commands without asking you each time, only for the turn where you run the command. Cursor's skills docs don't list this field.

7. /explain-file: Explain a file like I'm new to coding (a file name as the argument)

---
name: explain-file
description: Explain what a file does in plain English for a beginner.
argument-hint: [file path]
---

Explain $ARGUMENTS to me like I'm new to coding:

1. What this file is for, in one sentence.
2. The main parts, top to bottom, in plain English.
3. What other files use it or depend on it.
4. Anything risky to change here.

No jargon without a short explanation. Don't edit anything.

This one leaves out disable-model-invocation, so the AI can also load it on its own when you ask something like "what does this file do?".

Command not showing up? Check these

• Wrong file name or place. It has to be .claude/skills/<name>/SKILL.md (a folder, then SKILL.md), or .claude/commands/<name>.md for the old style. In Codex, skills go in .agents/skills/; in VS Code, prompt files must end in .prompt.md.
• Started in the wrong folder. Claude Code loads project skills from where you start it and every parent folder up to the repo root. Skills in a subfolder below that only show up once Claude works on files there.
• New folder mid-session. Claude Code watches skill folders, but if you created .claude/skills/ after the session started, run /reload-skills. Codex custom prompts need a restart.
• Frontmatter not on line 1. Claude Code only reads the settings when the opening --- is the very first line. If the YAML is broken, /name still works but the description is ignored. claude --debug shows the error.
• Odd characters in the name. Claude Code refuses names with <, >, double spaces or invisible characters. In Cursor, stick to lowercase letters, numbers and hyphens, and match the folder name.
• Same name as a built-in. In Claude Code in the terminal, your skill replaces a built-in with the same name (but not its aliases), so pick names that don't clash.
• Hidden on purpose. user-invocable: false hides a skill from the / menu in Claude Code.
• Still nothing? Run /skills in Claude Code, or open Customize → Skills in Cursor, to see what was found.

Related

• Claude Code skills examples (7 copy-paste SKILL.md files)
• Cursor rules vs skills (when to use a SKILL.md instead)
• Claude Code hooks examples (7 copy-paste hooks, plus Cursor)
• Claude Code subagents examples (7 copy-paste subagents)
• Cursor rules examples
• CLAUDE.md examples
• Plan mode guide (Cursor, Claude Code, Codex, Copilot, Lovable, Bolt + 6 plan prompts)
• Vibe coding prompts cheat sheet (21 prompts for any tool)

Sources

• Claude Code docs: Extend Claude with skills (custom commands)
• Claude Code docs: Commands (built-in reference)
• Cursor docs: Agent Skills
• Cursor help: Skills (commands vs skills, migrating)
• Cursor docs: CLI slash commands
• Codex docs: Custom prompts (deprecated)
• Codex docs: Build skills
• VS Code docs: Use prompt files
• VS Code docs: Use Agent Skills

Checked Oct 25, 2026. These tools change often; if something here no longer matches, tell us at [email protected].