Cursor Rules for Team Automations

Put durable team instructions in .cursor/rules/*.mdc, not in one long prompt or a private chat. For Cursor, Anysphere's AI code editor, rules are the right place to document how agents, skills, reviews, and automations should behave in a repo.

A Cursor rule is a repo-scoped instruction file that gives Cursor Agent durable context for a set of files or workflows. Good cursor rules make Cursor training repeatable for engineering teams because the same guardrails show up every time someone opens the repo.

As of the June 18, 2026 Cursor 3.8 changelog, Cursor Automations can be created with /automate, triggered from GitHub and Slack, and use computer use. That makes your rule system more important, not less: always-on agents need boring, reviewable conventions before they need more autonomy.

Put durable behavior in scoped rules

Create a small .mdc file for each durable team convention. Keep it close to the files it governs when possible, such as .cursor/rules/api-contracts.mdc for backend API work or .cursor/rules/react-ui.mdc for a frontend app.

This matters because Cursor Agent, cursor skills, and review workflows all benefit from the same shared context. A rule can say, for example, that payment code must preserve idempotency keys, add migration notes, and include a rollback plan.

Avoid turning one cursor rules file into a wiki. When a rule covers every file, every framework, and every review habit, it becomes background noise. Split by scope before people start ignoring it.

Use Cursor 3.8 automations after the rule exists

Use /automate only after the team has written the rule that describes the work. For example, before creating a GitHub-triggered automation that labels stale pull requests, write down what counts as stale, who can override it, and what the agent must never close.

The Cursor 3.8 automation flow is useful because you can describe the repetitive task in a local agent session and let Cursor configure triggers, instructions, and tools. GitHub and Slack triggers are especially tempting for team operations because they sit where the work already happens.

The trap is skipping governance because the setup feels conversational. Computer use and external triggers are powerful surfaces. Treat them like production automation: scoped permissions, clear ownership, and a reviewable change history.

Keep AGENTS.md broad and Cursor rules executable

Use AGENTS.md for cross-agent repository boundaries: architecture shape, release rules, ownership notes, and language that should stay true even if the team changes AI tools. Use .cursor/rules/*.mdc for Cursor-specific behavior that should actively guide Cursor Agent in the editor.

A practical split works like this: AGENTS.md says the billing service owns invoices and must never import from the web app; .cursor/rules/billing.mdc tells Cursor to check invoice state transitions, require tests around retries, and ask before touching migrations.

Avoid copying the same paragraph into every memory file. Duplication creates drift. If your repo still has a cursor rules file .cursorrules, treat it as a migration candidate and move the durable parts into scoped .mdc rules as you touch the relevant code.

For teams building deeper patterns around cursor subagents and cursor custom agents, keep the shared primitives boring: rules for constraints, skills for reusable procedures, MCP for external systems, and review checklists for enforcement. The broader training path lives in the related training topic.

Copy this team rule convention

Paste this into .cursor/rules/team-automation.mdc, then edit the paths and review checklist for your repo. It is intentionally small. The goal is not to describe your whole company; it is to make one automation-safe habit easy to review.

---
description: Team guardrails for Cursor Agent, skills, MCP tools, and /automate workflows.
globs:
  - '**/*'
alwaysApply: true
---

# Team Cursor operating rule

Cursor should treat this repository as a shared production codebase.

## Before changing code

- Read the nearest AGENTS.md when present.
- Check for a more specific rule under .cursor/rules before editing.
- Ask before changing public APIs, database migrations, auth, billing, or deployment files.
- Prefer a small diff with a clear test path over a broad cleanup.

## When using skills or custom agent instructions

- Use a skill for a repeatable procedure, such as release notes, migration review, or incident summary.
- Keep repo constraints in rules, not inside the skill body.
- Do not let a specialist agent override ownership, security, or test requirements from this rule.

## When creating an automation with /automate

- Name the owner of the automation in the pull request or setup note.
- Document the trigger: GitHub, Slack, schedule, or manual run.
- List every external tool or MCP server the automation can use.
- Start in suggest-only mode when the workflow touches production code or team communication.
- Require human approval before merging, deploying, deleting, closing, or notifying customers.

## Review checklist

- The change follows the nearest scoped rule.
- Tests or a manual verification path are included.
- The agent explains risky assumptions in the final message.
- Any MCP access is necessary for the task and scoped to the workflow.
- Automation behavior can be disabled or rolled back by a named owner.

This is also a decent starter artifact for a Cursor workshop. People can argue about the concrete lines, which is the point. A convention that survives review is better than a perfect rule file nobody has read.

Adopt it with a small review loop

Have one engineer propose the rule in a pull request, not in chat. Ask a service owner, a security-minded reviewer, and one frequent Cursor user to review it.

Keep the rule in .cursor/rules, and link to any broader AGENTS.md policy instead of repeating it. If the team uses Cursor MCP to reach GitHub, Slack, Jira, Figma, databases, or internal docs, name the allowed systems in the rule or the automation setup note.

The enforcement rule is simple: any PR that adds or changes a Cursor automation must update the matching rule, skill, or review checklist in the same PR. If review quality is your pressure point, pair this with Cursor Review Workflows With Subagents so the agent behavior and human review habit evolve together.

Avoid making platform admins the only people allowed to improve rules. The best cursor rules examples usually come from the engineer who just watched an agent make a plausible but unsafe edit.

Common questions

• Where should Cursor rules live in the repo?

  Cursor rules should live in .cursor/rules as .mdc files, with scoped rules split by workflow or area of the codebase. The practical answer behind cursor rules .cursor/rules documentation is this: put durable instructions in version-controlled rule files, keep them short, and review them like code.

• Do I still need AGENTS.md if I use Cursor rules?

  Yes, AGENTS.md is still useful when your repo needs a tool-neutral operating contract. Put broad architecture boundaries and ownership notes there, then put Cursor-specific instructions in .cursor/rules/*.mdc; the caveat is to avoid duplicating the same rule in both places.

• Should /automate replace cursor skills or custom agents?

  No, /automate should orchestrate repeatable work; skills and custom agent instructions should still describe how specialized work gets done. A good pattern is one automation trigger, one narrow skill or agent role, and one rule file that defines safety limits for the repo.

• What should we do with an old .cursorrules file?

  Treat an old .cursorrules file as a source to migrate, not as the final team convention. Move durable guidance into scoped .mdc files under .cursor/rules, and use the migration to delete stale prompts, duplicate style notes, and instructions that no longer match the code.

• How does MCP fit into Cursor team workflows?

  MCP is the integration layer that lets agents connect to external systems through defined servers and tools. In Cursor, mention MCP access in the relevant rule or automation note so reviewers can see whether the agent is using GitHub, Slack, docs, databases, or another system for the task.

Further reading

• Cursor — Agent
• Cursor — Rules
• Cursor — Skills
• Cursor — MCP
• Cursor — Enterprise
• Cursor — Changelog
• Model Context Protocol — specification

Make the next rule reviewable

Pick one repetitive workflow your team already trusts a human to do, then write the Cursor rule before you automate it. If the rule is clear enough for a teammate to review, it is clear enough for Cursor Agent to follow.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.