Cursor Project Rules belong in .cursor/rules and can be scoped to relevant paths. Prefer small rules with one purpose over a single giant instruction file.
1. Collect repeated conventions
Start with rules you repeatedly correct: framework patterns, file naming, test expectations, API boundaries or forbidden generated files.
2. Create a focused rule
Give the rule a clear purpose and concise instructions. Include examples only when they remove ambiguity.
3. Scope it to the right files
Apply frontend rules to frontend files, database rules to migrations, and so on. Narrow scoping prevents irrelevant guidance from polluting context.
4. Test with one real edit
Ask Agent to make a small change in a file covered by the rule and explain which rule it followed.
5. Refine from failures
If Agent ignores or misreads the rule, reduce ambiguity, adjust scope or split the rule instead of simply adding more prose.
Before editing this file, list the Cursor Project Rules that apply to it and summarize the constraints. Then make the smallest change that satisfies the task and show how the diff follows those rules.
One global rule for everything; rules that conflict with each other; stale commands; using legacy configuration without checking current Cursor rule support; never testing rule scope.
Finish check
A small edit in a matching file receives the intended guidance while unrelated files are not burdened by that rule.