Cursor Rules Hierarchy: Scope, Precedence, and Conflicts

Cursor applies rules at multiple scopes: global rules that apply to every file, project-level rules that apply to a whole workspace, and rules scoped to specific files or directories. When two rules cover the same file, Cursor uses a hierarchy to decide which instruction takes priority. Understanding that hierarchy prevents unexpected behavior and helps you write rules that do what you intend. Tools like fenbs give teams a place to record the decisions behind that hierarchy, so the reasoning is available to the next assistant working on the project.

The hierarchy matters most in large projects where different teams own different directories, and in monorepos where one package has conventions that differ from another. A frontend rule about component structure should not override a backend rule about service boundaries, and vice versa. Scope is the first tool for keeping them apart.

How Cursor loads rules at different scopes

Global rules live in Cursor's settings and apply to every file in every project. They are the right place for instructions that hold regardless of context: code safety rules, the language you want responses in, or a note about never modifying auto-generated files.

Project rules live in the .cursor/rules/ directory at the workspace root. They apply to the current project and are checked into version control with the code. Each rule file can have a glob pattern that further narrows which files it applies to. See cursor rules globs for how patterns work.

Subdirectory rules live in .cursor/rules/ directories inside a subdirectory. They are more specific than project-level rules and apply only to files below that directory. In a monorepo with separate frontend and backend packages, each package can carry its own rules without affecting the other.

Which rule wins when two apply to the same file

As a general principle, more-specific rules take priority over less-specific ones. A rule scoped to src/api/**/*.ts takes precedence over a project-wide rule for all TypeScript files, which in turn can override a global rule — when the rule format supports that override. Always verify the current behavior against the Cursor documentation for your version, as precedence details can change between releases.

The practical effect is that a subdirectory rule can customize or tighten a project rule for its own context. A project might have a general rule that says "use async/await"; a specific package might add "also use the project's custom error handler in every async function". The more specific rule adds to the general one without replacing it, as long as the instructions do not contradict each other.

What happens when two rules contradict each other

When instructions conflict — one rule says to use tabs, another says to use spaces — the assistant sees both. It may follow the more specific rule, follow the most recently loaded one, or ask for clarification. The safest approach is to avoid contradictions by treating scopes as layers: the project rule sets the default, and subdirectory rules add specifics without reversing the default.

A contradiction that appears in the rules usually reflects a real disagreement that has not been resolved by the team. Fixing the rules requires deciding which instruction is correct for each context, and recording that decision somewhere it will persist. If you let the assistant choose, it may choose differently in different sessions, which makes the rule unreliable.

# .cursor/rules/typescript.mdc (project-level)
---
globs: **/*.ts
---
Use async/await throughout. Do not use .then() chains.

# .cursor/rules/ inside apps/api/ (subdirectory-level)
---
globs: **/*.ts
---
In addition to the project async rule, wrap every async call in the
project's ApiError handler. Import it from lib/errors.ts.

How to audit your rule hierarchy

Open a file that you expect to receive multiple rules and check the Cursor context panel to see which rules are active. Compare the list to what you expected. If a rule is missing, the glob may not match the file path. If an unexpected rule appears, trace it back to its file and decide whether to scope it more narrowly.

• List every rule file at the project level and note its glob. Do any globs overlap on the same file types?
• Open a representative file from each major directory and check which rules load.
• For each conflict you find, write the resolution as a project decision before changing the rules. That way the reasoning is preserved if the rules change again.
• When a new package or directory is added, check whether existing rules accidentally reach it and whether it needs its own rules.

How to do this with fenbs

1. Create a free account and add a project for the repository where your Cursor rules live.
2. For each resolved conflict in your rule hierarchy, add a decision in fenbs: name the rule involved, which takes priority, the scope, and the person who decided it.
3. Record standing rules like "subdirectory rules always add to project rules, never replace them" in Decisions and rules with standingRule set, so every future assistant reads them as a firm constraint.
4. When someone proposes changing the hierarchy — moving from tabs to spaces, or removing a global rule — record the proposal as an open decision in fenbs and wait for a person to sign off before updating the rule files.
5. Connect your AI tools from Integrations so assistants read the current decisions before starting work in the codebase.

Hierarchy problems that scope alone cannot fix

Some instructions are impossible to scope cleanly because they apply to a concept that crosses file boundaries. A rule about "never call the database from a request handler" involves both the handler file and the database layer. Trying to capture that in a glob that targets handler files only solves half the problem.

For these cross-cutting concerns, the rule file is only part of the answer. The other part is a recorded decision that explains the boundary: why it exists, what counts as a violation, and who the team should ask when a new case arises. That kind of explanation belongs in a project decision rather than a rule file, because it cannot be expressed as a file pattern. The cursor rules library shows how to organize rules and decisions together.