How to Share Cursor Rules Across Your Team

Cursor rules are a great way to teach the AI how your codebase works — until you try to share them: dialed in on one laptop, empty or three versions behind on another. If you want to share Cursor rules with your team so every developer's AI behaves the same way, you need more than a file committed to one repo, and this guide walks through why rules drift and what actually keeps them in sync.

Why Cursor rules drift across a team

Cursor reads instructions from a few different places, and they don't all travel together:

• Project Rules live in a .cursor/rules/ folder (older setups use a single .cursorrules file at the repo root). These are committed with the code, so in theory the whole team gets them.
• User Rules are global, set in each person's Cursor settings. They apply to every project and never leave that person's machine.
• Ad-hoc instructions get pasted into chat and disappear when the thread ends.

The result is drift. The teammate who wrote the rules has tuned User Rules plus a local .cursor/rules/ they keep editing; everyone else has whatever was last committed — often stale, sometimes missing entirely. Multiply that across ten repositories and the "same" rule now exists in ten slightly different versions. And none of it helps the teammate who opened the same project in Claude Code or Windsurf, because those tools read different files.

The common ways teams share Cursor rules

1. Commit the rules to the repo

Putting .cursor/rules/ under version control is the right first move. It gives you history, code review on changes, and a copy that ships with the project.

The limits show up at scale. Rules are per-repo, so a convention you want everywhere ("always use our logging wrapper") has to be copied into every repository and updated in every one when it changes. It's also Cursor-specific — the file does nothing for teammates on other agents. And it never touches User Rules, so personal overrides keep drifting silently.

2. A shared rules folder or dotfiles repo

Some teams keep a central repo of rule files and copy or symlink them into each project. This centralizes the source, but now you're maintaining copy scripts, and the copies still go stale the moment someone forgets to pull. You've moved the drift, not removed it.

3. Copy-paste in Slack, Notion, or chat

The most common approach is also the weakest: the "good prompt" lives in a Slack thread or a Notion page, and people paste it in when they remember. There's no version, no owner, and no guarantee two developers are using the same text. This is exactly the scattered state Cursor rules were meant to fix.

A better model: one versioned skill library, read over MCP

The fix is to stop treating instructions as files glued to one tool and start treating them as shared, versioned artifacts that any agent can read on demand.

This is what Agent Skills make possible. A skill is a named, reusable block of Markdown instructions — the same idea as a Cursor rule, but tool-agnostic. If the concept is new, start with what are agent skills. Store those skills in one library, give it a version history, and let each developer's agent pull the current version at runtime instead of carrying a local copy.

The connective tissue is MCP (Model Context Protocol), the open standard Anthropic introduced in late 2024 that Cursor, Claude, and most major agents adopted through 2025. MCP lets an agent call out to an external server for context. Point every teammate's Cursor at the same MCP-backed skill library and they all read the same instructions — no committed copies, no stale User Rules. When a rule changes, it changes once, for everyone. For the mechanics, see connect an agent to a skill library over MCP.

Roget is built for exactly this: store your skills once, version every change, share them privately with your team, and connect any agent over MCP.

How to set it up

1. Extract your rules into skills. Take what's in .cursor/rules/ and your User Rules and turn each distinct convention into its own skill: one for code style, one for testing, one for your API patterns. Small, single-purpose skills are easier to reuse than one giant file.
2. Put them in a shared library. Store the skills somewhere with access control and version history, so a change is reviewable and reversible.
3. Connect each agent over MCP. Add the library's MCP server to each developer's client. In Cursor that's an entry in .cursor/mcp.json; other tools use their own config, but the server is the same.
4. Reference skills by name. Once connected, a developer asks the agent to apply a skill by name and it fetches the current version — the same text for everyone.

Keeping everyone in sync

The payoff is that "in sync" stops being something you enforce and becomes the default. Because the library is versioned, you can see who changed a skill and when, roll back a bad edit, and trust that the version a teammate's agent loaded this morning is the one you shipped. New hires get the team's accumulated conventions on day one by connecting one server, instead of hunting through repos and Slack threads. And because the skills are read over MCP rather than baked into Cursor, the same library works when someone switches to Claude Code or ChatGPT — the instructions follow the developer, not the tool.

Cursor rules are worth writing. They're just worth writing once, in a place every agent on your team can reach. Browse public skills in the Roget directory and start your own shared library.