Cursor has four rule types: **Always Apply**, **Apply Intelligently**, **Apply to Specific Files**, and **Apply Manually**. You don't pick a type by name in the file. Per Cursor's docs, you "control how rules are applied from the type dropdown which changes properties description, globs, alwaysApply." Those three frontmatter fields decide when a rule reaches the Agent. A project rule must be an `.mdc` file in `.cursor/rules`. A plain `.md` file there "is ignored by the rules system because it has no frontmatter to specify description, globs, and alwaysApply."
Who this is for
You wrote a Cursor rule and it either fires on every chat when it shouldn't, or never fires at all. Either way the problem is almost always in the frontmatter, not the rule body.
The four types and their frontmatter
Cursor's docs (cursor.com/docs/context/rules, checked 2026-10-16) describe each type and how the fields combine:
| Rule type | Docs description | `alwaysApply` | `description` | `globs` | Behavior per docs |
|---|---|---|---|---|---|
| Always Apply | "Apply to every chat session" | `true` | — | — | "Always included. Globs and description are ignored." |
| Apply to Specific Files | "When file matches a specified pattern" | `false` | — | provided | "Auto-attached when a matching file is in context." |
| Apply Intelligently | "When Agent decides it's relevant based on description" | `false` | provided | omitted | "Agent reads the description and pulls the rule in when relevant." |
| Apply Manually | "When @-mentioned in chat" (e.g. `@my-rule`) | `false` | omitted | omitted | "Included only when you @-mention the rule in chat." |
The docs also state the core switch plainly: "If alwaysApply is true, the rule will be applied to every chat session. Otherwise, the description of the rule will be presented to the Cursor Agent to decide if it should be applied."
What each one looks like
Always Apply — use it for the few lines that belong in every session:
---
alwaysApply: true
---
- Never modify generated files in dist/ or build/Apply to Specific Files — scope by path. The docs say to "use globs to scope a rule to specific files or directories. Separate multiple patterns with commas." `*` matches one file-name segment and `**` matches any number of directories:
---
globs: src/components/**/*.tsx
alwaysApply: false
---
- Use named exports, not default exportsApply Intelligently — the description is the trigger, so write it as a one-line statement of when the rule matters:
---
description: RPC service conventions and patterns for the backend
alwaysApply: false
---
- Validate inputs at the service boundaryApply Manually — no description, no globs. It sits idle until you type `@` and its name in chat:
---
alwaysApply: false
---
- Every migration needs both up and down functionsOne more detail from the docs: a file mention inside a rule, such as `@migration-template.sql`, tells the Agent where to look; the file's contents are not inlined into the prompt. Anything that must always be in context belongs in the rule body itself.
Pitfalls
- Using `.md` instead of `.mdc`. The file looks fine in the editor and does nothing. Cursor's docs are explicit that it's ignored. If you want plain markdown instructions, the docs point you to `AGENTS.md` instead.
- Setting `alwaysApply: true` and expecting globs to narrow it. With `alwaysApply: true`, globs and description are ignored. The rule loads everywhere.
- An Apply Intelligently rule with no description. Without a description there is nothing for the Agent to judge relevance on; with globs also omitted it behaves as a manual rule. The docs FAQ says: "For Apply Intelligently, ensure a description is defined."
- Globs that don't match the files you're actually working on. The docs FAQ: "For Apply to Specific Files, ensure the file pattern matches referenced files." A pattern like `src/components/*.tsx` won't reach nested folders; `**` is what recurses.
- Vague descriptions. "Backend stuff" gives the Agent little to decide on. Name the task or area the rule is for.
- Putting rules in the wrong place. Project rules live under `.cursor/rules`, and they can be organized in subfolders there. If you are fighting a legacy `.cursorrules` file, see the related post on that below.
How to check it
- Confirm the extension: every rule in `.cursor/rules` should end in `.mdc`.
- Open the rule and read its frontmatter against the table above. Ask which of the four rows it lands on. If it lands on a row you didn't intend, change the type in the dropdown rather than hand-editing three fields.
- For a file-scoped rule, open a file that should match the glob and start an Agent chat. Then open one that shouldn't, and compare.
- For an Apply Intelligently rule, ask the Agent to do a task the description names, and check whether the rule was pulled in.
- For a manual rule, @-mention it by name and confirm it applies.
- For an Always Apply rule, keep it short. Every session carries it.
Where ShipKits fits
The Day-1 Desk is a $12 pay-once first desk day: two seats (Day Desk + Reviewer Lite), one path-lock skill, a thin gate card, install.sh, and a ~90-minute sample run. Its `install.sh` copies the skill plus optional AGENTS.md / CLAUDE.md snippets (Cursor primary; Claude Code and Grok Bot notes). Soft path: /free. Cheat Sheet for the skim checklist mindset.
Soft next step
Rename any `.md` in `.cursor/rules` to `.mdc`, give every Apply Intelligently rule a one-line description, and test each file-scoped glob against a real file. Soft ladder: /free, then the Day-1 Desk ($12). Related: .cursorrules broke Agent mode, Cursor skill not loading.