Cursor Rules Examples (by Framework & Use Case)

Scope a TS/React rule to .ts and .tsx with globs so it only loads for the files it's about, then state the conventions as short directives. Keep it to the few things that actually matter on your team rather than a style-guide dump.

---
description: TypeScript & React conventions
globs: ["**/*.ts", "**/*.tsx"]
---

- Function components + hooks only.
- Use our `@/lib/logger`, never console.log.
- Co-locate component + test; name tests *.test.tsx.
- Prefer server components; mark client files with "use client".

Four lines is roughly the finished size rather than a starting point, and the reason is arithmetic rather than taste. Cursor's own open-sourced rules run about eight lines each, and every rule that loads spends context the task itself would otherwise get. The four above survive that test because none of them is inferable from the code around them. A model reading your components can copy your file layout on its own. It has no way to know that console.log is banned here.

The globs are doing quieter work than the body. **/*.ts and **/*.tsx keep this file out of every request that touches a migration, a stylesheet or a CI config, and in a repo with two or three stacks in it that is most requests. Leave the globs off and give it no description either and the rule waits for an @-mention, which is reasonable for a one-off checklist and wrong for a convention you want followed by default.

Same shape for Python: glob to **/*.py and keep the rule to a handful of conventions the agent would otherwise miss, like type hints on public functions and never catching with a bare except.

---
description: Python conventions
globs: ["**/*.py"]
---

- Type-hint all public functions.
- Use ruff for lint/format; no unused imports.
- Raise specific exceptions, never bare except.

One of those three lines is weaker than the others, and it is the ruff one. Lint and format are already enforced by the tool and its config, so restating them in a rule spends context on a check that runs whether or not the model read it. I kept a line like that for a long time as a hint about which tool we use. Cut it instead and let the linter be the linter, and the rule keeps only the two lines a config file cannot express.

Type hints on public functions specifically, not on everything. A named exception rather than a bare except. Keep the lines that describe intent and drop the ones that describe tooling.

Name the framework, the file layout, the naming convention and how to run the suite, then show one test the agent can copy. That is the shape one QA engineer used for a backend unit-testing rule, scoped to the backend test directory so it loads whenever the agent works near those files.

They did not hand-write it, which is the part worth stealing. Cursor ships a /create rule skill that generates the file from code you already have, so pointing it at a representative test produces the frontmatter and the body and you edit down from there. Generating from a real file also picks up the conventions nobody ever wrote down, the ones that exist only as a pattern across twenty tests.

The failure a testing rule guards against is narrower than "write good tests".

Generated tests sometimes log a failure instead of calling the framework's fail(), or wrap an assertion in a try/catch that swallows it, and either way the suite passes while proving nothing. Write the rule against that anti-pattern rather than against testing in general, and pair it with a validator step that runs the test and confirms a real failure surfaces.

Put in the conventions a reviewer would otherwise have to catch by hand, scoped by glob to the code they govern. The example Cursor points at for org-wide scope is a rule that says: when writing SQL, do not allow injections. On Teams and Enterprise that kind of rule can be pushed team-wide instead of copied into every repo by hand.

What does not belong is anything you would describe to an auditor as a control. A rule is guidance the model usually follows, and usually is carrying real weight in that sentence: a long enough conversation can crowd the rule out of context, and a member can switch a non-enforced Team Rule off in Customize. Hooks are the deterministic layer for the cases that must not slip, since a beforeSubmitPrompt hook runs before the request leaves the editor and can stop the submission outright.

Precedence matters more here than anywhere else on this page. Cursor merges every applicable rule and resolves conflicts by source: Team RulesRules promoted to apply across a whole organisation and shared consistently between the Cursor IDE, Agent and Bugbot. Press Enter for the full definition. first, then Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. Press Enter for the full definition., then User Rules. A security convention pushed at team level outranks whatever the repo's own .cursor/rules/ says about the same thing, so check the team list before you debug your file.

Scoping is what gets a rule loaded at the right moment. Set globs so each rule only fires for its files, keep one concern per file, and reserve alwaysApply: true for conventions that really are global. Rules cost context, so a short example beats a paragraph of prose.

• Set `globs` so a rule auto-attaches only for the files it's about.
• No globs? Give the rule a clear `description` (with alwaysApply: false) and the agent pulls it in when it judges the rule relevant.
• Keep each file to one concern (style, testing, security).
• Use alwaysApply: true sparingly - only for truly global conventions (it ignores globs and description).
• Prefer a one-line example over a paragraph of description.

There's also a simpler container: AGENTS.md, a plain markdown file with no frontmatter that Cursor reads from your project root - and now from subdirectories too, where nested AGENTS.md files combine with their parents and the more specific file takes precedence. It's the right choice when one file of conventions is enough, or when the repo is shared with other tools that read the same format.

One mechanical trap sits underneath all of this and it is probably the most expensive one to find, because nothing reports it. Project rules have to carry the .mdc extension. A .md file sitting in .cursor/rules/ is ignored by the rules system, and it looks entirely correct in the editor while doing nothing at all.