Project Rules and Legacy .cursorrules
Rules record durable project constraints so repeated tasks do not drift away from the team's stack, exports, types or testing conventions.
#Use the current rule format
Cursor's rules documentation↗ describes project rules in .cursor/rules. The root .cursorrules file is a legacy format. Preserve an existing file when maintaining a project, but use the documented current rule workflow for new rules.
Team, project and personal instructions have different scopes. Check the current product's precedence and application modes rather than relying on the original guide's simplified hierarchy.
#Keep permanent and temporary instructions separate
Always-applied rules suit durable team conventions. Manual/task-specific rules suit a limited assignment. A one-off performance-only task should not become an unrelated permanent rule.
#Organize the contents
Record the stack, code style, testing requirements, output/comment language and explicit exclusions.
markdown# Project conventions ## Stack - Next.js App Router, TypeScript and styled-components - Jest for meaningful unit tests ## Style - Functional components and named exports - async/await for asynchronous logic ## Tests - Cover new utility behavior - Avoid snapshots that merely mirror implementation ## Output - Follow the task's requested language - Keep comments concise
This is sample rule content, not a prescription to change an existing repository's framework.
#Useful exclusions
Require an explicit decision before schema changes; avoid unrequested state libraries; remove temporary debug code; and do not use any merely to silence type errors.
#Common rule failures
“Follow best practices” is too vague. Temporary instructions become stale. An exhaustive wish list is difficult for both people and tools to maintain.
For writing tasks, plain headings, source-backed claims, an appropriate language policy and a non-promotional tone can also be recorded. These improve editorial consistency without guaranteeing search outcomes.
Start with the five constraints your team most frequently has to repeat.