Set Cursor Agent Conventions for Teams

Do not start by adding every Cursor agent surface at once. For a team repo, treat Cursor agent mode, rules, skills, subagents, and MCP as one operating convention: what the agent may know, what it may do, who reviews output, and where the convention lives. That is the practical work behind Cursor’s Agent docs for an engineering team, and it is the part I keep boring on purpose in a Cursor workshop.

A backlog item named “Cursor, Cline, and DeepSeek” should become a repo convention, not a tool grab bag. Cline or DeepSeek may be useful context in someone’s environment, but the team can only enforce the Cursor parts it owns: Cursor rules, Cursor skills, cursor custom agents, MCP access, and review gates. I keep a broader set of examples under Subagents and skills, but this note stays with the convention you can paste into a repo.

Put durable repo knowledge in the repo

Cursor agents work better when the stable facts live close to the code. Put architecture boundaries, package ownership, test commands, and forbidden shortcuts in AGENTS.md or scoped rule files instead of repeating them in chat.

For a pnpm monorepo with apps/web and packages/ui, the root convention can say that shared components must change in packages/ui first, then apps/web can consume them. A nested AGENTS.md under packages/ui can add the local rule that visual changes need Storybook coverage before a Cursor agent opens a pull request.

Keep prompts for the task. Keep durable rules in files that other engineers can review.

Choose the smallest Cursor surface that fits

Use the narrowest surface that can carry the work. More agent structure can help, but it also creates routing, naming, and review overhead.

This is where the Review step in our methodology matters. Delegate a bounded job to the cursor agent, but make the review rule explicit before you trust the result.

Package repeated work as skills

Use Cursor skills when the team keeps asking for the same procedure. A good skill carries the steps, scripts, examples, and checks that would otherwise live in a senior engineer’s head.

A useful migration skill might say how to add a new database field, which codegen command to run, which fixtures to update, and which test command proves the change. The skill should not be a vague instruction to “follow project style.” Cursor skills earn their place when they reduce repeated explanation.

The description matters because it is part of the activation surface. Write it like you would name a good internal tool: specific enough that the right agent reaches for it, boring enough that nobody has to guess.

Keep MCP access narrow

MCP is the integration layer that lets Cursor reach outside the repo. That can be powerful, but it also widens the blast radius.

Start with read-only access for docs, issues, design references, or internal knowledge. Move to write access only when the team has named who approves it, what logs are kept, and how mistakes are rolled back. I would use the same posture described in Add MCP Servers to Cursor Safely: connect the smallest useful system first, then expand after review.

For example, a docs MCP server that lets a Cursor agent read API guidelines is easier to accept than one that can edit tickets, post messages, and update production data. Capability should follow review maturity, not excitement.

Adopt the convention as a pull request

Paste this block into the repo first, then edit it down. The point is not to make a perfect policy. The point is to give Cursor agents, reviewers, and future contributors one shared operating model.

# Cursor agent operating convention

Scope: this repository.

## Durable context
- Keep architecture boundaries, package ownership, test commands, and release constraints in AGENTS.md or scoped AGENTS.md files.
- Keep Cursor-specific reminders in .cursor/rules/*.mdc when they help the agent act correctly in this repo.
- Prefer nested files when a rule only applies to one package, service, or app.

## Skills
- Create a Cursor skill when the same workflow is repeated at least three times.
- Each skill must include when to use it, the commands it may run, the files it may touch, and the checks that prove the work.
- A skill description must be specific enough for an agent to know when to activate it.

## Subagents and custom agents
- Use a Cursor subagent or custom agent only for bounded work with a clear done condition.
- Name the owner team or reviewer for each custom agent.
- Do not create a new agent for one-off prompts.

## MCP
- New MCP servers start read-only unless the owning team approves write access in the same pull request.
- Each MCP entry must name the system, the allowed capability, and the rollback path for mistakes.

## Review gate
- No agent-generated change merges until a human reviewer checks the diff, runs the relevant test or build command, and confirms the agent followed this convention.
- Any pull request that changes agent authority, MCP access, skills, or subagents must update this convention.

Adopt it like code. One engineer proposes the convention in a small pull request, one reviewer from the owning team checks the boundaries, and the file lives beside the repo rules it governs.

The review rule is the enforcement point. If a pull request adds a skill, changes a Cursor rule, adds an MCP server, or gives a cursor background agent more authority, the convention must change in the same pull request.

Run the next agent change as a small PR

Pick one recurring Cursor agent workflow this week, add the convention block, and review the first agent-generated pull request against it. If your team wants practice, hands-on training covers Cursor rules, skills, subagents, MCP, and review habits in a real repo.

Further reading

• Cursor Agent docs
• Cursor rules
• Cursor skills
• Cursor MCP docs

Where to go next

Start from Subagents and skills.