---
title: "Cursor Rules for Product Managers, a Guide"
description: "Cursor rules keep a generated change inside the lines you care about. The four rule types, when each loads, and how a product manager writes one that holds."
canonical_url: "https://builderscamp.com/guides/tools/cursor-rules-for-product-managers"
date_published: "2026-09-18"
date_modified: "2026-09-18"
author: "Andre Albuquerque, Tiago Pedro da Costa"
publisher: "Builders Camp"
guide_class: "tools"
---

# Cursor rules for product managers: keeping a generated change inside the lines

**TL;DR:** A Cursor rule is a markdown file that injects persistent instructions at the start of the model's context, and the four types differ mainly in when they load: always, on a matching file path, when the agent judges them relevant, or only when you @-mention them. Writing good ones is product work, because the hard part is deciding which constraints are genuinely always true.

## What problem does a rule actually solve?

Large language models do not carry memory between completions, so every session starts from nothing and every constraint you care about has to arrive with the prompt. Rules are how you stop retyping them. Cursor inserts rule content at the start of the model context, which makes them persistent, reusable guidance rather than something you remember to mention when you happen to think of it.

For a product manager, that description undersells what is happening. A rule is a written-down decision that currently lives in somebody's head. "Customer-facing strings never get hard-coded, they go through the localisation file." "Every tracked event follows the object-action naming convention." "Nothing in the checkout flow ships without a flag." Each of those is a product constraint that an engineer has been enforcing by remembering it. Writing it as a rule moves it out of memory and into the repository, where it is reviewable, arguable, and applied consistently whether or not that engineer is in the room.

## The four types, and why the difference matters

Cursor has four. **Project rules** live in `.cursor/rules`, are version-controlled, and are scoped to the codebase. **User rules** are global to your own Cursor environment and follow you across projects. **Team rules** are managed centrally from the dashboard and are available on Team and Enterprise plans. **AGENTS.md** is a plain markdown file for people who want the effect without the frontmatter.

The split that matters for a product team is project versus user. A constraint that belongs to the product belongs in the repository, where a teammate inherits it by cloning and can argue with it in a pull request. A preference that belongs to you, how verbose you like explanations, which model you reach for first, belongs in user rules, where it will never quietly change somebody else's output. Mixing the two is the usual reason a rules file becomes a graveyard nobody trusts.

One mechanical trap costs people an afternoon: project rules must use the `.mdc` extension. A plain `.md` file sitting in `.cursor/rules` is ignored entirely, because it has no frontmatter to specify `description`, `globs`, and `alwaysApply`. The rule is not broken, it is invisible, which is worse.

## When does a rule load, and who decides?

Three frontmatter fields interact to produce four behaviours, and choosing the wrong one is how a rules file gets bloated.

| Setting | When the rule loads |
|---|---|
| `alwaysApply: true` | Every session. Globs and description are ignored |
| `alwaysApply: false` plus `globs` | When a matching file is in context |
| `alwaysApply: false` plus `description` | When the agent judges it relevant |
| Neither field set | Only when you @-mention it in chat |

Globs use the patterns you would expect: `**/*.ts` reaches every TypeScript file in the project, `src/components/**/*.tsx` reaches one directory tree, and multiple patterns are comma separated. The reason to prefer a glob over always-applying is not tidiness. Every always-applied rule occupies context in every session, competing with the code the agent actually needs to read, so an unscoped rules file is a tax you pay on every single request.

## A worked example: three rules a product manager should own

Take a checkout flow at a company with a localisation process, an analytics convention, and a nervous finance team. Three constraints, three different load behaviours, written the way a product manager would state them.

The **always-applied** rule holds the stop lines, the things that are true everywhere and whose violation is expensive. Set `alwaysApply: true` and keep it short: never hard-code customer-facing text, never modify a file under `generated/`, and always summarise any change that alters a price, a plan name, or a billing interval at the top of the response. Three lines. If a fourth is only true sometimes, it does not go here.

The **glob-scoped** rule holds conventions that only matter in one place. Point `globs` at your analytics directory and state the naming convention with an example, plus the rule that a new event needs an owner and a description. It costs nothing on the ninety percent of sessions that never open that directory, and it is unmissable on the ten percent that do.

The **description-scoped** rule holds the domain knowledge that a newcomer would need and an agent cannot infer. Write `description: Checkout and payment flow conventions` and then explain, in prose, that a failed payment retries three times before the subscription is marked past due, that the trial state is distinct from the active state, and that anything touching the flow needs the flag. The agent reads the description and pulls the rule in when it is working on something related, which is roughly when a new engineer would ask a colleague the same question.

Notice what none of these require: you did not write code, you wrote down decisions. The hard part was deciding which constraints are genuinely always true, and that is the same judgment call product managers make when they write a definition of done.

## Rules are context, not enforcement, and the difference costs money

A rule raises the probability of the behaviour you want. It does not guarantee it, because it is text at the start of a context window competing with everything else in that window. Writing a rule and then treating the constraint as handled is the trap, and it is exactly the trap a product manager is most likely to fall into, because in every other part of the job writing the policy down is most of the work.

Cursor's answer for anything that must hold regardless is hooks: spawned processes defined in `hooks.json` at the project or user level, communicating over stdio, running before or after stages of the agent loop, and able to observe, block or modify behaviour. The documented uses include scanning for secrets, gating risky operations such as SQL writes, and injecting context at session start. Hooks need someone who can write a script, so the practical division of labour is that the product manager decides which constraints are advisory and which are absolute, and an engineer implements the absolute ones.

The second safeguard is procedural rather than technical. Use Plan Mode before a change of any size, read the plan against your own rules, and reject it there rather than in the diff. A plan that violates a rule you wrote is cheap to fix. A merged change that violates it is not.

## What a rules file looks like six months in

The failure pattern is predictable. Somebody adds a rule after every incident, nobody ever deletes one, and within two quarters the always-applied section is 300 lines of accumulated caution that the agent is reading in full on every request. The fix is a review cadence, not restraint at the moment of writing: once a quarter, read the always-applied set and ask of each line whether it is still true and still project-wide. Anything that fails either test moves to a glob, moves to a description, or goes.

That review is a product manager's job more than an engineer's, because the question is not whether the rule is technically correct but whether the constraint it encodes still reflects how the product works.

## Where this fits in the Builders Camp catalogue

Building with Cursor covers rules directly as part of team standards and configuration, alongside `AGENTS.md`, slash commands, and the Ask, Plan and Agent workflow, across 1 week and 2 live sessions taught by Tiago Pedro da Costa, Co-founder and CTO of Zumer. Its stated audience is developers and product-minded developers, which is worth knowing before you enrol.

The same idea appears in the no-code path, which is the version most product managers reach for first. Building with Lovable teaches a structured prompting framework built on briefs and guardrails, with Knowledge Files playing the role that a rules file plays in a code editor: durable context the tool reads on every build instead of a constraint you restate in every prompt. The Vibe Coding Expert Track carries both, for someone who wants the code-first and no-code approaches side by side rather than picking blind.

## Write the rule you have already explained twice

The first rule worth writing is not the one you think is most important, it is the one you have explained to somebody twice this month. That repetition is the signal: a constraint you have to restate is a constraint that is not written down anywhere the work can see it. Open `.cursor/rules`, make one `.mdc` file, put that single constraint in it, and see whether the next generated change respects it.

[See the Building with Cursor bootcamp](https://builderscamp.com/bootcamps/building-with-cursor?utm_source=guide&utm_medium=organic&utm_campaign=cursor-rules-for-product-managers)

For the modes these rules feed into, [Cursor for product managers](https://builderscamp.com/guides/tools/cursor-for-product-managers) covers Ask, Plan and Agent as separate jobs, and [context architecture](https://builderscamp.com/guides/glossary/context-architecture) covers the wider question of what an agent should be able to see at each step.

## Frequently asked questions

### What are the four types of Cursor rules?

Project rules live in .cursor/rules, are version-controlled and scoped to the codebase. User rules are global to your own Cursor environment. Team rules are managed from the dashboard on Team and Enterprise plans. AGENTS.md is a plain markdown alternative to .cursor/rules for people who do not want frontmatter.

### Why is my rule being ignored?

The most common cause is the file extension. Project rules must use the .mdc extension, and a plain .md file inside .cursor/rules is ignored by the rules system because it carries no frontmatter to specify description, globs and alwaysApply. If you want plain markdown, use AGENTS.md instead.

### When does each rule actually load?

Four behaviours, set by three frontmatter fields. alwaysApply true means the rule is always included and globs and description are ignored. With alwaysApply false and globs set, the rule attaches when a matching file is in context. With a description and no globs, the agent pulls it in when it judges it relevant. With neither, the rule loads only when you @-mention it.

### Can a product manager write a rule without writing code?

Yes. A rule is a markdown file with a few lines of frontmatter and a list of plain-language statements. Writing one is closer to writing a definition of done than to programming. The harder part is deciding which constraints are actually always true, which is product work rather than technical work.

### Do rules guarantee the agent obeys them?

No. Rules are context inserted at the start of the model's context, which raises the probability of the behaviour you want without enforcing it. For a constraint that must hold regardless, Cursor has hooks, which are spawned processes that run before or after stages of the agent loop and can observe, block or modify behaviour.

### How many rules is too many?

Every always-applied rule sits in the context of every session, so the file competes with the code the agent needs to read. Keep the always-applied set to constraints that are genuinely project-wide, and move anything conditional to a glob or a description so it loads only when it is relevant.

### Where should a team's rules live?

In the repository, as project rules, so they are version-controlled and reviewed like any other change. Personal preferences belong in user rules where they will not surprise a teammate. Team rules from the dashboard suit constraints an organisation sets centrally, and are available on Team and Enterprise plans.

## Sources

- [Cursor Docs: Rules](https://cursor.com/docs/context/rules)
- [Cursor Docs: Hooks](https://cursor.com/docs/hooks)
- [Cursor Docs: Plan Mode](https://cursor.com/docs/agent/plan-mode)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.