Custom Slash Commands in Cursor CLI: Reusable Prompts for Terminal Workflows

If you keep re-typing the same prompts (lint, summarize diffs, draft PR descriptions), you’re wasting time—and the output tends to be inconsistent. Cursor CLI lets you “program” your workflow with custom slash commands: reusable Markdown prompts you can run quickly from the terminal. ⚡

What is a custom slash command? 🤔

A custom slash command is a .md file that contains instructions for the AI agent. The filename becomes the command name, and when you run /<command>, Cursor uses that file’s content as the prompt.

What you get:

• Consistency: stable output and formatting
• Speed: run a short command instead of pasting a long prompt
• Reusability: scope it per project or make it global

Where do commands live? (Project vs global) 📁

Cursor discovers custom commands from two locations:

• Project-level: .cursor/commands/ (only for this repo)
• Global/personal: ~/.cursor/commands/ (available in all repos)

Use project-level commands when they depend on the repo (e.g., pnpm vs npm, biome vs eslint, specific folder layouts). Use global commands when the prompt is generic and you want it everywhere.

How to create a custom command 🛠️

1) Create the commands directory

In your project root:

mkdir -p .cursor/commands

Or for global commands:

mkdir -p ~/.cursor/commands

2) Create a .md file (the filename becomes the command)

Example: create /joke:

printf "%s\n" "tell a concise, funny programming joke" > .cursor/commands/joke.md

If you prefer an editor, just create .cursor/commands/joke.md and put a single instruction inside.

How to run it from the terminal 💻

Call the agent and reference your command with a leading /.

Example:

cursor-agent -p "/joke"

On some setups, the command may be agent:

agent -p "/joke"

In short: -p passes a prompt to the agent, and "/joke" loads and runs the content from joke.md.

Practical commands you’ll actually use ✅

1) /lint-fix: run linter + minimal fixes

Create .cursor/commands/lint-fix.md:

Run the linter for this repo and summarize the errors.
Then propose minimal code fixes.
Only touch files related to the reported errors.
If a fix may change behavior, explain the risk first.

Run:

cursor-agent -p "/lint-fix"

2) /diff-summary: summarize changes before committing

Create .cursor/commands/diff-summary.md:

Summarize the current git diff in 5-10 bullet points.
Focus on "what changed" and "why it matters".
If you see risky changes (auth, data, payments), call them out.

Run:

cursor-agent -p "/diff-summary"

3) /pr-body: draft a clean PR description 🧾

Create .cursor/commands/pr-body.md:

Write a PR description in this format:

## Summary
- (max 3 bullets)

## Test Plan
- [ ] ...

Keep it concise and actionable.

Run:

cursor-agent -p "/pr-body"

Tips to keep outputs consistent 🎯

These patterns make commands “tight” and predictable:

• Specify the output format: bullets, checklist, table, fixed template
• Add guardrails: “minimal changes”, “don’t touch config”, “don’t push”
• One command = one job: small, repeatable, easy to maintain
• Set limits: e.g., “max 10 bullets”, “max 5 suggestions”

Important notes ⚠️

• Avoid vague names: /fix is too generic; use /lint-fix or /build-fix.
• Don’t duplicate the same name in global and project unless you’re sure which one should win.
• Use file/folder references in prompts when you need tighter scope (e.g., @src/...).

---

If you work mostly in the terminal on Linux/WSL, custom slash commands are one of the easiest ways to make your workflow faster and more consistent—without building a new tool from scratch. 🚀