Skip to lesson
Exit
Cursor Product Mastery1 / 3

1 min lesson

The four rule types and exactly when each fires

Explain the practical point behind "There are four types, set in each rule's header."

Step 1 of 3

The four rule types and exactly when each firesthe most-asked topic in the field - know it cold

"Scope" (project vs user vs legacy) is one axis, but the axis engineers actually ask about is firing: when does a given rule get injected? There are four types, set in each rule's header. You create them via Settings > Rules, Skills, and Sub Agents > project > Rules > New, which writes an .mdc (Markdown) file under .cursor/rules with a header carrying name, description and apply setting.

Learn more

Advanced table

Glob-scoping is also a token lever

Rule type
Always Apply
When it fires
Attached to every single prompt
Use it for
The basics: tech stack, what you're building, a few hard constraints
Rule type
Apply Intelligently
When it fires
Agent reads your description and invokes it when it judges it relevant
Use it for
Conditional guidance the model should pull in by topic
Rule type
Apply to Specific Files
When it fires
Only when a file matching the glob (e.g. *.tsx) is touched
Use it for
Subsystem conventions, kept out of unrelated context
Rule type
Apply Manually
When it fires
Only when you @-mention it while prompting
Use it for
Heavy content like a full style guide, run as an on-demand audit

Glob-scoping is also a token lever: a file-scoped rule never loads on unrelated work.

The '300 other things' failure mode

The dominant rules anti-pattern: cramming directives into an always-apply rule. The model does best with the least to attend to, and an always-apply rule with 300 directives silently appends "also do these 300 other things" to every prompt - so output gets worse, not safer.

Build rules reactively, not preventively: keep always-apply to stack/constraints, and add a directive only after the model makes the same mistake a few times. Don't write "just in case" rules and don't replace your linter with a rule - that just burns tokens injecting rule content into every call. As models improved, best practice loosened: today they need fewer behavioral instructions than they did 18-24 months ago.

Per-agent personas, live

A manually-applied rule is also the cleanest demo of instructed behavior across parallel agents. Write a small Markdown rule with one directive - "keep it simple," or a strict code-reviewing directive - then @-tag it into just one chat. That agent becomes a code-reviewing agent; the agent next to it, untagged, doesn't inherit the rule at all.

Narrate it: "This agent will keep it simple. This one won't have that rule applied. So I can dictate the behavior of one agent through project rules that are applied manually." One window becomes a planning agent, another a reviewer, another a plain prompter - each shaped by which rule you tagged, not by a global setting.

Learn more

Full explanation

Rules vs. Skills vs. Commands

Rules vs. Skills vs. Commandsthe primitive engineers most often blur

Rules are no longer the only standardization primitive, and an SA who can't draw the line loses credibility with a platform team. The clean framing: a rule is more a "what" (use Tailwind; 100% test coverage); a skill is more a "how" (here's the design system and how to apply it). Skills are an open cross-tool standard - supported across Cursor, Claude Code and Codex - that the agent auto-discovers from a name/description and invokes only when relevant (progressive disclosureHow skills load: the agent boots knowing only each skill's name and description, then pulls a skill's full instructions into context only at the moment it decides to use it. Press Enter for the full definition.: if a skill isn't firing, the fix is usually a better description). Commands are explicit slash-triggered workflows.

Rule

Static content, applied always or to a file glob.

Decided ahead of time, always enforced when in scope.

Best kept to one-sentence always-apply basics (e.g. "never leave AI slop comments").

Skill

Dynamic capability the agent discovers and invokes when relevant.

The more capable replacement for "apply intelligently" rules - the agent is trained to invoke them more reliably and they can hold templates/workflows.

A native Cursor skill even converts an old rule into a skill.

Command

An explicit workflow triggered by a forward slash.

For recurring multi-step jobs you launch on demand.

All three live under .cursor and ride in the context window, so all three count toward tokens.

Distribution scopes - the governance backbonehow a standard actually reaches the whole org

Versioned Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. Press Enter for the full definition. answer one team's consistency; an org needs distribution. Rules, skills, commands and hooks apply at three scopes: user-level (only you), repo-level (committed, anyone with repo access) and team/org level via Teams Marketplaces - org-wide configs with sub-team variants (one set for the design team, another for backend infra). Admins can push skills, hooks and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. integrations centrally to the whole team.

Two scope tricks worth knowing

.cursor is git-ignored by default - you unignore what you want committed. To keep a personal rule set private, create it in the rules directory and add it to .gitignore.

Before org-level rules existed (and still in use): keep a shared rules repo and add it as a root folder via a multi-root workspace, so several repos inherit one known-good baseline.