Turn Frequent Prompts into .cursor/commands?

If you paste the same review, commit, or checklist prompt into chat every time, pin it as a slash command. In Cursor, a command is a reusable prompt you invoke with /name in Agent chat. No pricing, no full Skills-vs-Rules retell.

This post covers only where the files live, how arguments work, and how commands differ from rules. Grounded in Customize Cursor, Plugins — Commands format, Rules, and Command deeplinks.

Where do the files live?

One-line answer: Put Markdown (or text) files in .cursor/commands/ for the project and ~/.cursor/commands/ for personal globals. The filename becomes the / name.

Where docs and plugins put them:

LocationScopeNotes
.cursor/commands/*.mdWorkspace (repo)Commit to Git; share with the team
~/.cursor/commands/User (machine-global)Personal shortcuts; not in the repo
Plugin commands/Plugin bundleShip via marketplace / team plugins

Practical create order:

  1. Create .cursor/commands/ at the repo root.
  2. Use a kebab-case name like code-review.md → /code-review in chat.
  3. Write steps, output shape, and hard stops in Markdown.
  4. Optionally add YAML frontmatter name and description (plugin Commands format documents these fields).
  5. Type / in Agent chat; project and global commands are listed together.

Minimal example:

---
name: code-review
description: Review the open diff against a checklist
---

# Code review

1. Summarize change scope and risk in one paragraph.
2. Call out bugs, regressions, secrets, and missing tests only.
3. Write short PR-comment style notes.

Plugin docs accept .md / .mdc / .markdown / .txt. Day to day, one .md file = one command is enough. Command deeplinks can share name + body; the recipient still confirms before it is registered.

How do arguments work?

One-line answer: Text after /command is attached as this run’s context. Do not assume Claude Code–style $ARGUMENTS templates—tell the prompt body how to use the trailing text.

Practical patterns:

PatternExample inputWhat the body should say
Trailing text/fix-issue 456Treat number/URL as the issue to fetch
Natural-language tail/fix-issue add email validationTreat the rest as the requirement
Context-first/commit-msgWork from staged diff / open files
Selection/explain-selection (after select)Assume editor selection / @ files

Body that consumes a trailing arg:

# Fix issue

If an issue number, URL, or one-line requirement follows the command, prefer that.
Otherwise discover a repro from the current chat and open files first.

1. Write repro and failure conditions.
2. Fix with the smallest change.
3. Run verification commands and report results.

Design tips:

  1. Do not expect positional argv or flag parsers. The tail is raw text.
  2. Keep a context-only fallback (open file, staged diff) so the command still works bare.
  3. If an arg is required, say so in the first line and ask the user for one short line.
  4. For team commands, lock an output schema (table, checklist, commit format) so quality stays consistent.

How do they differ from rules?

One-line answer: Rules are persistent instructions that seep into sessions; commands are on-demand reusable prompts you fire with /. Location and trigger differ.

AxisCommands (.cursor/commands)Rules (.cursor/rules)
IdentityReusable prompt / workflow shortcutSystem-level standing guidance
TriggerExplicit /name in chatAlways / Intelligent / globs / @rule
Files.md (etc.); filename ≈ command name.mdc + frontmatter (alwaysApply, globs, …)
ArgsTrailing text + current contextStatic; no per-invocation parameters
Length feelProcedures/checklists may be longerKeep focused (docs suggest under ~500 lines)
Example rolesOne-shot review, PR draft, security passStyle, architecture, domain constraints

How teams combine them:

  1. Must always hold (license headers, banned imports, test policy) → rule.
  2. Same procedure, sometimes (release checklist, diff review) → command.
  3. Do not dump full workflows into Always rules—every chat pays the context cost.
  4. One line in the command body—“follow project rules / AGENTS.md”—keeps standing policy and one-shot procedure separate.

Out of scope here: the full Skills vs Rules matrix, /migrate-to-skills detail, pricing or request-limit numbers.

FAQ

I type / but my command does not appear

Confirm the path is repo-root .cursor/commands/ (or ~/.cursor/commands/) and the extension is supported. Prefer kebab-case filenames. Reopen chat or reload the window, then type / again.

What if frontmatter name disagrees with the filename?

In plugin packaging, name is the identifier. For everyday workspace use, keep filename = invoke name so the team does not guess. Avoid mismatching them.

Can I put the same checklist in a rule?

Yes, but an Always rule loads it into every chat. Occasional procedures belong in a command. Split “always-on short constraints” from “explicit long procedures.”

Sources