Scope matches the files
Use a precise glob for file-specific guidance; reserve always-on rules for truly universal constraints.
Rule builder
Write a project rule your agent can actually follow
Cursor project rules live in .cursor/rules. A strong rule is narrow, concrete, and easy to verify—not a second README or a collection of vague preferences.
A focused starter
Save the example as an .mdc file under .cursor/rules/, then replace the scope, commands, and standards with facts from your repository.
---
description: Standards for API route changes
globs:
- "src/app/api/**/*.ts"
alwaysApply: false
---
# API route standards
- Validate every external input before using it.
- Return structured errors with an appropriate HTTP status.
- Never log secrets, tokens, or complete personal records.
- Add or update tests for success and failure paths.
- Run `pnpm test` before marking the change complete.
Review before committing
Instructions are testable
Replace words like “clean” or “robust” with commands, thresholds, patterns, and observable outcomes.
Repository facts are current
Confirm paths, package names, framework versions, and scripts against the actual codebase.
The rule stays small
Split unrelated concerns so the agent receives only the context relevant to the task.
Security boundaries are explicit
Call out sensitive paths, data handling rules, approval requirements, and prohibited actions.
Examples agree with the rule
A contradictory example is often followed more readily than an abstract instruction.
About the old .cursorrules format
Cursor's documentation treats the root .cursorrules file as a legacy format. Existing examples can still be useful for their content, but new rules should use project rule files so they can be scoped and composed.