How to Enforce Project Conventions with Cursor Rules

Without guidance, Cursor writes code in whatever style it defaults to, which may not match your project. Cursor Rules are short Markdown files that ride along with every prompt and tell the agent how your codebase works: which libraries to use, what to avoid, how to name things. They are especially valuable for multi-file edits, where a single bad assumption gets repeated across many files.

• A project open in Cursor
• A clear sense of two or three conventions your team always follows
• Write access to the project root

Create the rules folder

Make a .cursor/rules directory in your project root. Each rule lives in its own file with an .mdc extension. Splitting rules into focused files keeps them easy to maintain.

Write a rule

A rule file starts with a small frontmatter header that controls when it applies, followed by plain instructions. Keep instructions concrete and short. Vague rules get ignored.

---
description: Styling conventions for this project
globs: src/**/*.tsx
alwaysApply: false
---

- Use Tailwind utility classes, never inline style objects.
- Do not add new CSS files; extend the existing tokens.
- Components are function declarations, not arrow consts.
- Never use the any type.

Choose how the rule applies

The frontmatter decides scope. Set alwaysApply: true for rules that should ride along on every request, or use globs so a rule only loads when matching files are in context. Glob-scoped rules keep prompts focused.

Verify the rule changed behavior

Ask Composer to add a new component. With the styling rule in place, it should reach for Tailwind utilities and a function declaration without being told in the prompt. If it ignores a rule, make the rule more specific or mark it alwaysApply.

Result: every edit Cursor proposes now respects your conventions automatically, so multi-file changes stay consistent with the rest of the codebase.