Cursor for Cursor rules
The editor in the Cursor rules stack. Rules are a Cursor feature, not an add-on. They live in the repo as files, so they are version controlled and arrive with a clone.
- 1Put the rule in the right place, with the right extension
Project rules live in .cursor/rules as .mdc files and are version controlled, so they arrive with a clone. The extension matters more than it looks: a plain .md file in that directory is ignored by the rules system, because it has no frontmatter to carry description, globs and alwaysApply. That is the single most common reason a rule appears to do nothing.
Prompt · Create onemkdir -p .cursor/rules # .mdc, not .md. A .md file here is silently ignored. touch .cursor/rules/conventions.mdc # Or let Cursor scaffold it: type /create-rule in Agent and # describe what you want.
- 2Pick the type, because the frontmatter is the trigger
There are four types and the frontmatter alone decides which one you get. alwaysApply: true applies the rule to every chat session. A description with alwaysApply: false leaves it to the agent to decide when it is relevant. A globs pattern with alwaysApply: false fires only when a matching file is in play. Nothing at all means the rule only runs when you @-mention it. Most rules people write want the third and get the first.
Prompt · Always: conventions that are never wrong to apply--- alwaysApply: true --- - The middleware file is proxy.ts, not middleware.ts. - Content lives under content/, not lib/. The lib/*.ts files are thin loaders. - Do not add a dependency without saying why in the PR description.
Prompt · Scoped: only when the agent touches these files--- globs: ["**/*.test.ts", "**/*.spec.ts"] alwaysApply: false --- - Tests use the real database against a scratch schema, not mocks. - One assertion per test. If a test needs three, it is three tests. - Never assert on a snapshot of generated output.
Prompt · Agent-decided: describe when it matters--- description: Use when writing or changing a database migration. alwaysApply: false --- - Read the live schema before writing SQL. Do not infer it from the types. - Every migration is additive. No destructive change without a separate PR. - RLS is on. A new table with no policy is invisible to the client, which is the intended default, not a bug to work around.