4 min read
Cursor Skills vs Commands: When to Use Each
- cursor
- ai
- developer-experience
- tooling
Cursor gives you two ways to guide the AI: Commands and Skills. They solve different problems. Using them well keeps sessions fast and consistent; using them interchangeably adds noise or gaps.
At a glance
| Commands | Skills | |
|---|---|---|
| What they are | User-invoked playbooks in .cursor/commands/ | Instruction files (SKILL.md) the agent loads when a task matches |
| When they run | When you trigger them | When the task falls within the skill's scope |
| Best for | Repeatable workflows with a clear start and end | Conventions and rules that apply across many tasks |
| Risk if overused | Too many to remember | Broad skills fire too often and pollute context |
Rule of thumb: procedures you run on demand go in Commands. Knowledge that should shape many tasks goes in Skills.
Commands
A command is a step-by-step workflow you invoke intentionally. It lives in .cursor/commands/your-command.md and contains exactly what the agent needs for that job — nothing more.
.cursor/commands/
new-post.md # /new-post — scaffold an MDX blog post
review.md # /review — pre-merge checklist
continue-plan.md # /continue-from-plan — pick up the roadmap
Use commands when:
- The workflow has a clear start and end ("run
/reviewbefore every merge") - Steps are long or templated — you don't want them injected into every chat
- The user should consciously decide to run it (releases, migrations, audits)
Commands are opt-in by design. The agent only sees that context when you ask for it.
Skills
A skill is durable guidance the agent reads when the task is in scope. It covers conventions, framework quirks, or rules that apply across many tasks — not just one.
.cursor/skills/
react-patterns/SKILL.md # hooks style, file layout, testing conventions
db-migrations/SKILL.md # rules for touching src/db/
Use skills when:
- The same rule applies to a whole class of edits (not a one-off)
- You want the agent to load context automatically, without you naming it each time
- The knowledge is stable across project phases
Keep skills small and focused. A global skill that covers everything becomes always-on noise. One concern per skill file, not one mega-skill.
Combining without duplication
A clean split for a typical project:
- Skills: coding conventions, file layout, testing patterns, security rules ("never hardcode API keys")
- Commands: "ship a release," "audit env vars," "continue the roadmap through phase 2"
If the same paragraph appears in both, extract it to one place. Evergreen rules belong in the skill; the command references them and adds step ordering only.
The bottom line
Commands are your explicit playbooks. Skills are your ambient expertise. Use Commands when intent and sequence matter; use Skills when the same rule should quietly apply across many tasks. Trim both aggressively — noisy context and forgotten steps are symptoms of the same problem: too much guidance in the wrong place.
