How to Use Cursor Rules to Guide AI Edits

Add a project rules file so Cursor follows your conventions and stack on every AI edit without being told each time.

8 minIntermediate

Visit Cursor

Cursor reads project rules and applies them to its AI edits, which is the difference between code that matches your codebase and code you have to rewrite. This guide adds a rules file and confirms the editor follows it.

What you need

Cursor installed with a project open
Knowledge of your stack and house style
About 8 minutes

Step 1: Create the rules folder

Project rules live in a dedicated folder at the repo root. Create it so Cursor knows where to look.

zsh - rules dir

$mkdir -p .cursor/rules

Step 2: Write a rule

Each rule is a small file describing how to write code in this project. Keep the guidance specific and testable, the same way you would brief a new teammate.

.cursor/rules/style.md

# Project style
- TypeScript strict; never use `any`.
- Prefer named exports over default exports.
- Use the existing `apiClient` helper for all network calls.
- Co-locate tests next to the file they cover.

Step 3: Reference the right files

Point a rule at the patterns it governs so Cursor applies it where it matters. Tie API rules to your network layer and UI rules to your components.

Cursor - rules in the sidebar

Explorer

style.md

api.md

components.md

.cursor/rules/style.md

1# Project style

2- TypeScript strict; never use any.

3- Named exports only.

4- Use apiClient for network calls.

Rule files live alongside the code they govern.

Step 4: Verify the rule is applied

Ask Cursor to add a small feature and check the result. If your rules are loaded, the generated code uses named exports and your helpers without a reminder.

One concern per file

Split rules by topic, style, testing, API, so you can tune each independently and Cursor can pull in only the relevant ones for a given edit.

Result: Cursor produces edits that fit your codebase from the start, cutting the cleanup you used to do on every AI suggestion.