Rules
Persistent project rules that steer every edit.
Persistent instructions for every edit
Rules are standing instructions Cursor applies to every AI request — your stack, your conventions, the patterns you want and the ones you have banned. Written well, they mean you stop re-explaining your project in each prompt, and the AI produces code consistent with what already exists. They are the closest thing Cursor has to teaching it your codebase's house style once, so every future edit respects it. For most teams, good rules are the single biggest quality lever in the whole tool.
Write rules that actually steer
Effective rules are specific and actionable: 'use our logger, never console.log', 'prefer composition over inheritance', 'all API calls go through the client in lib/api'. Vague aspirations do little; concrete conventions and hard constraints do a lot. Keep them current as your project evolves, and add a rule whenever you find yourself correcting the AI the same way twice. That repeated correction is exactly what belongs in your rules, so you never have to make it again.
What are Cursor rules?
Standing instructions Cursor applies to every AI request — your stack, conventions, preferred patterns, and things to avoid — so you stop re-explaining your project and get consistent output.
How do I write good Cursor rules?
Make them specific and actionable — concrete conventions and hard constraints, not vague aspirations. Add a rule whenever you catch yourself correcting the AI the same way twice.
Why are rules so important in Cursor?
They apply to every request, keeping generated code consistent with your codebase without restating your style each time. For most teams they are the biggest single quality lever.