Skip to lesson
Exit
Cursor Product Mastery1 / 3

1 min lesson

Rules and standardization

Describe what "Rules are how you answer that worry" changes in practice.

Step 1 of 3

Rules are the SA's single most impactful lever, because they turn tribal knowledge that lives in three senior engineers' heads into a standard the model follows for everyone.

Left to defaults, every developer gets slightly different output: different patterns, different libraries, different opinions on error handling. That variance is fine for one person experimenting. Across a 300-engineer org it's chaos, and it's the thing a VP of Engineering worries about when they hear "we're rolling out AI coding."

Rules are how you answer that worry. They are persistent instructions that get injected into the model's context so its behavior conforms to your conventions, your stack and your guardrails.

Learn more

Advanced table

The shape of Rules

The shape of Rules

Scope
Team RulesRules promoted to apply across a whole organisation and shared consistently between the Cursor IDE, Agent and Bugbot. Press Enter for the full definition.
Lives where
Set from the team dashboard; can be enforced
Use it for
Org-wide guardrails every team's runs must honor
Scope
Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. Press Enter for the full definition.
Lives where
.mdc files in .cursor/rules, versioned and reviewable in the repo
Use it for
Stack conventions, architecture boundaries, the team's house style
Scope
User Rules
Lives where
Per-developer settings
Use it for
Personal preferences that shouldn't be forced on the team
Scope
AGENTS.md
Lives where
Plain markdown in the project root or subdirectories
Use it for
Simple instructions with no frontmatter; a nested file adds more specific guidance
Scope
.cursorrules (legacy)
Lives where
Single file at repo root
Use it for
Older single-file form; modern setups favor structured project rules

Precedence runs Team Rules, then Project Rules, then User Rules when guidance conflicts. Project Rules being versioned in the repo is the key property: they review and ship like code.

Because Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. Press Enter for the full definition. live in the repository, they go through pull-request review like any other change. A new convention gets proposed, debated, merged and from that moment every Agent run in the repo respects it. That is org-wide consistency without a single all-hands.

A file-scoped project rule in .cursor/rules/api-conventions.mdc: frontmatter first, then specific, testable directives
---
description: API handler conventions
globs: src/api/**
alwaysApply: false
---

- Use the existing `Result<T, E>` type for fallible functions; never throw across module boundaries.
- All new HTTP handlers go in `src/api/` and must register in `src/api/router.ts`.
- Database access only through the repository layer in `src/db/repos/`; no raw SQL in handlers.
- Prefer `zod` schemas for request validation; reuse schemas from `src/schemas/` when one exists.
Learn more

Optional practice

Test yourself on Rules and standardization

QWhy are Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. Press Enter for the full definition. (versioned in the repo) a stronger standardization lever than asking each developer to maintain their own User Rules?