Cursor rules for a team: project rules, team rules and shared memory

To share Cursor rules with a team, commit them to the repository as project rules in .cursor/rules/ (or a plain AGENTS.md), and use Team Rules from the Cursor dashboard for rules that apply to every repository. Rules are instructions. For what the team has decided and learned, which changes week to week, add a shared ledger over MCP that every teammate's Cursor, and any other agent, reads before a change.

The four kinds of Cursor rules

From Cursor's rules docs, checked on 30 October 2026:

Kind	Where	Shared with the team?
Project rules	.cursor/rules/*.mdc in the repo	Yes, through git
AGENTS.md	The repo root and any subfolder	Yes, through git; Claude Code and Codex read it too
Team Rules	The Cursor dashboard (Team and Enterprise plans)	Yes, every repository; admins can enforce them
User Rules	Your Cursor settings	No, only you

When rules disagree, Team Rules come first, then project rules, then user rules.

A project rule the whole team gets

Project rules must use the .mdc extension; a plain .md file in .cursor/rules is ignored. The front matter decides when a rule applies:

---
description: Conventions for the checkout service
globs: src/checkout/**/*.ts
alwaysApply: false
---
- Validate every request body with zod at the route.
- Prices are integers in cents; never use floats for money.
- Read @src/checkout/README.md before changing the payment flow.

• alwaysApply: true: in every chat.
• globs only: when a matching file is in context.
• description only: when the agent judges it relevant.
• Neither: only when someone @-mentions the rule.

If your team doesn't all use Cursor

.cursor/rules is read only by Cursor. If some of the team use Claude Code, Codex or another agent, put the shared rules in AGENTS.md: Cursor reads it (including nested ones in subfolders), Codex reads it, and Claude Code reads it when the repository has no CLAUDE.md. Keep Cursor-specific, file-scoped rules in .cursor/rules.

What rules don't do well

Rules are static text that someone has to edit. They're a poor fit for:

• Why a decision was made. The rule says "no captcha on checkout"; the reason, and the numbers behind it, don't fit in a rule.
• What was tried and reverted. Writing every lesson into a rule makes it long and less likely to be followed.
• Work in progress. Which tasks are open, and which agent has taken one.
• Things learned today. A teammate's agent finds out the staging database is read-only; until someone edits a rule, nobody else's agent knows.

Add a shared ledger to every teammate's Cursor

RepoMemory is an MCP server with one ledger per project. On the Team plan, every key on the account reads and writes the same ledgers. Add it to the project's .cursor/mcp.json, with each person's key coming from their own environment so no key is committed:

{
  "mcpServers": {
    "repomemory": {
      "url": "https://api.repomemory.dev/mcp",
      "headers": {
        "X-API-Key": "${env:REPOMEMORY_KEY}"
      }
    }
  }
}

Cursor fills in ${env:NAME} in url and headers from the environment. Then add an always-applied rule, .cursor/rules/project-memory.mdc:

---
alwaysApply: true
---
## Project memory (RepoMemory, project "acme/shop")
- At the start of a session, call `brief` for the project: it returns every guardrail, the open tasks and the latest decisions. Never break a guardrail. If a guardrail contradicts the repository's rules or what you were asked, don't pick one quietly: say so and ask.
- Before planning a change, removing code that looks unneeded or retrying an approach, call `recall` with words about the change. Follow what it returns.
- When a change is reverted, a fix took real digging, or you choose one approach over another, call `record_entry` (kind lesson or decision) saying what happened, why, and what to do instead, with your name in `agent`.

Now a lesson one teammate's agent records reaches everyone's next session, and a rule nobody should break can be a guardrail, which brief hands every agent at the start of a session.

When a guardrail and a rule disagree

RepoMemory doesn't read your rules, so brief can't spot a clash. The agent sees both; ledger entries come back as notes the user's instructions outrank. The rule above has the agent name the clash and ask; a person then edits the rule or supersedes the guardrail.

Limits to know

RepoMemory's recall matches words, not meaning, so agents should recall with the words of the change ("captcha checkout"). It's hosted only. The Team plan is $50 a month for 20,000 new entries; recall is free. See pricing and the docs.

---

First published on repomemory.dev. I build RepoMemory, so weigh my take on it accordingly.