Set Up Cursor Rules for Teams
Keep Cursor rules small and scoped; do not turn them into a second README. For Cursor users, the useful move is to put durable repo instructions in .cursor/rules, keep task-specific intent in the chat, and move larger repeatable workflows into skills, subagents, or MCP.
When a teammate asks how to use Cursor rules, I show three moves: create a focused .mdc file, scope it to the files where it matters, and write instructions the agent can verify against the repo. I use this pattern in Cursor training because it gives engineering teams a shared surface without asking every developer to remember the same prompt.
Put durable repo behavior in .cursor/rules
Use a Cursor rules file for conventions that should survive more than one task. Examples include test commands, API layering, naming rules, generated-code boundaries, and review checks.
In a monorepo workflow, I would not write one giant rule for packages/web, packages/api, and e2e. I would create separate rules, such as .cursor/rules/api-service.mdc for the API package and .cursor/rules/playwright.mdc for browser tests.
That keeps the rule close to the files it influences. It also makes review easier, because a pull request can change one rule for one part of the repo instead of touching a broad policy file that nobody wants to read.
Rolling this out in your team?
We train engineering teams on their own codebase in two days. Cursor setup, shared rules and review included.
Decide what belongs in rules, skills, subagents, or MCP
Cursor rules are only one customization surface. As of November 2026, Cursor's docs place rules alongside agent behavior, Cursor skills, subagents, hooks, and MCP, so the boundary matters.
| Need | Use | Reason |
|---|---|---|
| Always remind the agent about repo conventions in a file area | Cursor rules | The instruction is durable and local to the code. |
| Package a repeatable workflow with scripts or reference material | Cursor skill | The work is larger than a reminder and should be invoked when needed. |
| Give a focused agent a role, such as frontend reviewer or migration helper | Cursor custom subagent | The work needs a separate lens, not just another rule. |
| Connect Cursor to GitHub, Jira, docs, databases, or other systems | Cursor MCP | The agent needs external context or actions. Start with read-only access where possible. |
If MCP is part of the workflow, set that boundary separately from rules. I would use a rule to say when to consult an issue or design doc, then follow a safe setup path such as Connect Cursor to MCP Safely for the integration itself.
For a broader map of this part of Cursor, keep Subagents and skills nearby. Rules are the lightest layer in that stack.
Add the first rule in five minutes
Start with a behavior that has already failed twice. A good first rule is not aspirational; it prevents a repeat mistake.
- Pick one narrow area, such as
packages/api/**/*. - Create
.cursor/rules/api-service.mdc. - Add a short description and a file glob so Cursor can attach the rule where it matters.
- Write five to eight instructions in plain language.
- Ask Cursor Agent to make a small change in a covered file.
- Review whether the agent followed the rule without you restating it in chat.
- Tighten the rule if it was ignored, vague, or too broad.
Most Cursor rules examples fail because they sound like team values rather than operational constraints. Write what the agent should do, what it should not touch, and how it should prove the change is safe.
Paste a focused .mdc rule
This is the kind of starter rule I would commit before asking a team to create twenty more. Adjust the paths and commands to match your repo.
---
description: Apply when editing API routes, service files, or database access in packages/api.
globs: packages/api/**/*
alwaysApply: false
---
# API service rule
When changing files in this area:
- Keep route handlers thin. Put business logic in service modules.
- Do not call the database directly from UI or route code outside this package.
- Reuse existing validation helpers before adding a new schema.
- If a database query changes, check the related migration and seed data.
- Run the package test command before handing back the change.
- In the final response, name the files changed and the test command used.
If the requested change conflicts with these rules, stop and ask before editing.
The description is not decoration. It is part of how the rule becomes useful, because it tells Cursor when the rule is relevant.
Keep the body boring. Short imperative lines beat clever policy prose.
Keep rules reviewable
A rule can make an agent more consistent, but it can also preserve a bad habit. Put rule changes through normal code review, especially when they affect security, data access, migrations, or release commands.
In our methodology, this sits mostly in Review and Document. The team delegates work to Cursor, reviews the diff and the agent's reasoning, then documents the durable lesson as a rule only when it should apply again.
Rules also have a maintenance cost. If a rule mentions old commands, deleted packages, or retired architecture, the agent may follow stale instructions with confidence.
Further reading
Ship one rule this week
Pick one repeated review comment and turn it into one scoped rule file, then test it on a small change. If you want to practice this with real repo exercises, our hands-on training covers Cursor rules, skills, subagents, and review habits for engineering teams.
Related research
Train your team on Cursor
Two days on your team's own repository, onsite or remote, with a written proposal before you commit.
Book a callPrefer to measure first? Take the free team check.