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:

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.

Cursor suggests keeping each rule under 500 lines and adding rules when you see the agent make the same mistake again.

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.
- 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.

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.