Cursor Rules for Team Workflows

If your team keeps fixing the same thing three different ways, you do not have a speed problem. You have a convention problem, and Cursor rules are the cleanest way to solve it. A Cursor rule is a scoped instruction file at .cursor/rules/*.mdc that tells Cursor, Anysphere's AI code editor, how to behave in a specific repo, folder, or kind of task.

Think of a rule file as a note you leave next to the code so every agent run starts from the same place. The trick is to keep each one small and easy to review. A rule nobody can read in a sentence is a rule nobody will trust.

Split one big rule into scoped files

The old habit was a single root .cursorrules file that tried to cover everything. It grows, it goes stale, and eventually nobody can tell what is always on versus what only applies to one task.

The fix is to break that one file into a few .mdc files with narrow globs and a clear description each. Cursor then attaches the right rule at the right moment, and your reviewers can see exactly why a change followed a given convention.

A good test: if you cannot name a rule's job in one sentence, it is doing too much. Split it.

Keep subagents inside a fence

Cursor subagents work well when the parent task is clear and the boundaries are spelled out. They drift when the team assumes the subagent will infer repo norms on its own.

So write the fence down. Put durable, repo-wide conventions in AGENTS.md, keep the task-specific instructions in the request itself, and let the subagent work inside those lines. You get fewer surprise edits and far less back-and-forth in review.

One habit pays off every time: ask the subagent to return a short summary of files changed, assumptions made, and open risks. That summary is what a reviewer reads first.

A rule file you can copy today

Here is a small starter you can drop in and adapt. It is deliberately short, because a short rule is one a reviewer will actually read.

---
description: Apply to backend service code and shared API contracts.
globs:
  - "services/api/**"
  - "packages/contracts/**"
apply: auto
---

- Prefer small diffs that preserve existing interfaces.
- If a change touches auth, data shape, or public API behavior, ask for a human review before merge.
- Use AGENTS.md for repo-wide ownership and architecture rules.
- If a task needs external data or tickets, check the approved MCP connector list first.
- When a subagent is used, return a short summary of files changed, assumptions made, and open risks.

For adoption, keep it human. A repo owner proposes the rule, one reviewer from the owning area checks the scope, and the file lives beside the code it governs. Reject anything too broad, too vague, or impossible to test in a real run.

Review only the new diff

Cursor's changelog says Bugbot now reviews in about 90 seconds on average, down from about 5 minutes, finds 10% more bugs per review on average, and costs about 22% less per run, as of June 10, 2026. That speed only helps if the review stays focused on what actually changed.

So review the delta, not the whole file again. Look at the new diff since the last pass and stop re-litigating code you already approved. Old code that was fine yesterday is still fine today.

When MCP connectors enter the picture, the blast radius widens, because the editor can now reach external systems. Review each connector, its scope, and the data it can touch before it joins a team workflow. The official MCP specification is direct about consent, control, and tool safety, and Cursor's docs point you to the same discipline.

Common questions

• What are Cursor rules?

  Cursor rules are scoped instruction files that tell Cursor how to behave in a repo, folder, or class of task. The current model is .cursor/rules/*.mdc, not one giant root file. Scoped rules are easier to review, easier for Cursor to attach at the right moment, and easier to retire when the codebase moves on.

• Should we still use a .cursorrules file?

  Use the layered .cursor/rules model first, and treat a root .cursorrules file as legacy if your team still carries one. Cursor's docs now center the scoped approach, which stays aligned with repo structure. In practice, one narrow rule per concern is enough, and it is far easier to keep current than a single growing file.

• How do Cursor rules help a team ship faster?

  They make the expected behavior visible before the agent writes any code, which cuts rework. Instead of catching a style or scope mistake in review, you prevent it at the source. The agent reads the rule, follows the convention, and the reviewer spends time on real risks rather than re-explaining house norms run after run.

• Where do subagents and MCP connectors fit?

  Subagents handle scoped sub-tasks inside boundaries you set in AGENTS.md and the request. MCP connectors give the editor access to outside systems, so each one needs an explicit consent and least-privilege check. Keep both on a short leash: a named owner, a clear scope, and a review gate before anything reaches shared code.

Try one rule this week

Pick the one part of your repo that gets rewritten the most, and write a single scoped .mdc rule for it. For the wider workflow around subagents and reviews, see /topics/subagents-and-skills and bring it to your next training session.

Further reading

• Cursor docs: agent overview
• Cursor docs: rules
• Cursor docs: skills
• Cursor docs: mcp
• Cursor docs: enterprise
• Cursor docs: changelog
• MCP docs: specification 2025-11-25