Cursor commands: custom slash commands in .cursor/commands

What are Cursor commands?

Cursor commands are reusable prompts stored as Markdown files that you run by typing / in Agent chat. Cursor's Customize docs describe commands as "Reusable prompts you invoke with / in Agent chat. Commands are markdown files that define a focused workflow or action."

So a command is a saved prompt with a name. Instead of pasting the same ten lines about how to review a pull request, you write them once in a file, and from then on you type / and pick the command from the list. The agent receives the file's text as part of your message and follows it.

Commands are explicit. Unlike rules, which Cursor adds to conversations on its own, a command only runs when you call it. That makes commands a good fit for routines you trigger on purpose: review this diff, write release notes, prepare a migration, run a security pass.

One thing to know before you build a large set: Cursor is moving this job to Agent Skills. More on that below.

Where do Cursor command files live?

There are three places commands come from.

The project location is named in Cursor's deeplinks reference, which talks about sharing "custom commands defined in your .cursor/commands directory." Because the folder sits in your repo, commands travel with the code and change through normal pull requests.

The Customize page is the in-app view. Cursor says you can "control which rules, skills, subagents, commands, and hooks are active for each scope," with user, team and workspace as the scopes.

How do you write a Cursor command?

A command is plain Markdown. Write it the way you would write a careful prompt to a colleague: what to do, in what order, and what the output should look like.

# Review the current branch

1. Run `git diff main...HEAD` and read every changed file.
2. Flag bugs, missing error handling and untested branches.
3. Check new code against the conventions in AGENTS.md.
4. Reply with a short list grouped as Must fix, Should fix, Nice to have.
   Quote the file and line for each item.

Save it in .cursor/commands/, then type / in Agent chat and select it.

If you package commands in a plugin, Cursor's plugins reference lists the rules. Plugin commands go in a commands/ directory, the supported extensions are .md, .mdc, .markdown and .txt, and the file can start with YAML frontmatter that has two fields: name ("Command identifier (lowercase, kebab-case)") and description ("Brief description of what the command does").

---
name: deploy-staging
description: Deploy the current branch to the staging environment
---

# Deploy to staging

1. Run tests
2. Build the project
3. Push to staging branch

Cursor's current docs do not describe an argument or placeholder syntax for commands. If a command needs input, say so in the prompt, for example "If I haven't given a ticket number, ask for it before you start."

How do you share commands with a team?

You have four documented options.

1. Commit them. Files in .cursor/commands/ are part of the repo, so every teammate gets the same set.
2. Send a deeplink. Cursor's deeplinks reference documents command links in two forms: cursor://anysphere.cursor-deeplink/command for the app and https://cursor.com/link/command for the web, each with name and text parameters. Opening one "creates a new command with the specified name and content," and "The user must review and confirm the command before it gets executed."
3. Ship a plugin. Cursor plugins can bundle commands with rules, skills, subagents, MCP servers and hooks.
4. Org-wide commands. Cursor's enterprise safety docs say "Commands are scoped to teams, projects, or users. Team admins can create organization-wide commands that appear for all developers."

Command deeplinks carry the full prompt in the URL, so treat a link from someone you don't know like any other prompt: read it before you confirm.

Should you use commands or skills in Cursor?

For new work, Cursor points you at skills. The old commands page on cursor.com now redirects to the skills help section titled "How do I migrate commands to skills?", and the skills reference covers the conversion.

The key setting is disable-model-invocation: true. Cursor says it makes "a skill behave like a traditional slash command, where it is only included in context when you explicitly type /skill-name in chat." In other words, a skill with that flag does what a command does, plus it can carry scripts, references and assets in its folder, and it follows the open Agent Skills standard that other tools also read.

To migrate, type /migrate-to-skills in Agent chat. Cursor describes it as a built-in skill "available in Cursor 2.4+" that finds eligible rules and commands and converts them. Per the skills reference, "Both user-level and workspace-level commands are converted to skills with disable-model-invocation: true, preserving their explicit invocation behavior." Review the new skills in .cursor/skills/ afterwards.

Existing commands still appear in Cursor's current docs, in the Customize page, the plugin format and deeplinks, so there is no rush. But if you are starting fresh, a manual-only skill gives you the same /name behavior with room to grow. Our Cursor skills guide covers the folder layout, and skills vs slash commands explains the trade-off across tools.

Do Cursor commands work in the CLI and on mobile?

Yes, according to Cursor's own docs. The CLI changelog notes that "/add-dir refreshes slash skills and custom commands immediately," and that reloading a plugin refreshes its slash commands. Cursor's mobile page says "Your slash commands, skills, and automations work the same on mobile as they do locally, in the CLI, and on the web."

Keep in mind that the CLI also has its own built-in slash commands, such as /model, /plan and /clear, listed in the CLI slash commands reference. Pick names for your own commands that don't collide with those. See the Cursor CLI guide for setup.

Tips for writing commands that hold up

• One job per command. A command that reviews code and also writes release notes is two commands.
• Name the output. Say what the reply should look like: a checklist, a table, a diff, a commit message.
• Point at sources of truth. Refer to AGENTS.md, a test command or a style guide instead of copying their content.
• Keep secrets out. Commands are plain text in your repo or in a link. Never put tokens or internal URLs you would not commit.
• Review them like code. A command changes agent behavior for everyone on the team, so it deserves a pull request.

If you also use Claude Code, the same idea exists there; see Claude Code custom commands.

Keep your command prompts in one place

The prompts behind your commands are worth keeping outside any one editor. Kipt stores prompts and Agent Skills as Markdown in a private GitHub repo you own, with {{name}} blanks for the parts that change. If you are turning commands into skills, the free SKILL.md generator converts a prompt into a SKILL.md in your browser, ready for .cursor/skills/.