Home · Cursor Skills · Rules vs Skills
Cursor rules vs skills: the difference that actually matters
One sentence: rules are loaded on every request whether you need them or not; skills are loaded only when a task matches. Everything else — where your instructions belong, what they cost, why your skill "never fires" — follows from that.
The split, concretely
| Rules | Skills | |
|---|---|---|
| Where | .cursor/rules/ | .cursor/skills/ or ~/.cursor/skills/ |
| When loaded | Every request (always-on types) | When the request matches the skill's description, or on /name |
| Context cost | Paid on every single chat | Near zero until triggered — just the description line |
| Right home for | Stack choices, naming, architecture, "never do X" | Task playbooks: migrations, PDF work, test plans, design direction |
| Failure mode | Bloat — rules grow until they crowd out your code | Silence — a vague description means the skill never triggers |
Two mistakes we keep seeing
The 600-line rule. Someone pastes an entire playbook — say, how the team processes PDFs — into a rule. It works, and then every unrelated chat pays for those 600 lines: less room for code, slower, and the instruction competes with everything else in context. As a skill, the same playbook costs one description line until someone actually touches a PDF.
The convention hidden in a skill. The reverse: "always use our error type" placed inside a skill that triggers on bug-fix requests. Half the time the description doesn't match, the skill never loads, and the convention is silently ignored. If it must always apply, it is a rule — that is the whole test.
The one-question version: should this be in the agent's head even when the task is unrelated? Yes → rule. No → skill.
How they compose in a real project
A typical setup we see working: three short rules (stack and naming; testing conventions; a short forbidden-patterns list) plus a shelf of skills — one for the design system, one for data migrations, one for release notes. A request like "redesign the pricing page" runs under all three rules while the design skill loads on top. Nothing is duplicated, and the total always-on cost stays small enough to leave context for the codebase.
Choosing skills is the other half of the problem — quality and safety vary wildly, which is why we live-test and score them instead of listing everything.
Frequently asked questions
Can a project have both rules and skills?
Yes, and most mature projects do. Rules hold the conventions that must never be forgotten (naming, architecture, forbidden patterns). Skills hold task playbooks (how to write a migration, how to process a PDF). They compose: the agent works under your rules while following the skill.
Do skills replace rules for prompting?
No. A skill only loads when a request matches its description (or you invoke it). Anything that must apply to every single response — tone, stack choices, code style — belongs in a rule, because a skill cannot guarantee it will be in context.
Why not put everything in rules?
Context cost and dilution. Rules are loaded on every request; a 600-line PDF playbook in a rule would tax every unrelated chat and push out room for your actual code. Skills exist precisely so deep instructions cost nothing until the task needs them.
Next: how to add a skill to Cursor, or every place Cursor looks for skills.