When developers on the same team use Cursor without a shared .cursorrules, each person gets different output. One developer's Cursor uses async/await, another's uses promise chains. One writes tests, another doesn't. The code review catches some of it, but not all.
A shared .cursorrules checked into the repo solves this.
What to centralize in .cursorrules
Naming conventions:
Files: kebab-case. Components: PascalCase. Variables/functions: camelCase. Constants: UPPER_CASE. Boolean props: is*, has*, can* prefix.
Testing requirements:
New functions require tests. Test files in __tests__/ adjacent to the source file. Use the existing test patterns in the codebase.
Commit discipline:
Do not commit debug code, console.log statements, or TODO comments older than the current task. Commit message format: type(scope): description.
No external dependencies:
Do not add new npm packages. If a new dependency is required, note it in a comment and stop. Dependencies require team approval.
What NOT to put in the team .cursorrules
Personal preferences. If one developer wants verbose comments and another wants minimal, the .cursorrules can't satisfy both. Keep it to project standards — things that belong in your contributing guide.
Also avoid: rules that only apply to certain parts of the codebase. Use subdirectory .cursorrules for module-specific rules.
The rollout process
- Draft the initial file as a PR — get buy-in before merging
- Start minimal: 5-7 rules you can all agree on
- Add rules when the team notices a recurring problem that Cursor caused
- Review the file quarterly — remove rules that are no longer needed
A .cursorrules file that everyone follows is better than a comprehensive one that gets ignored.
Top comments (0)