NEW: Claude Code Security — research preview →

Team Collaboration

Shared rules, AI pair programming patterns, PR workflows, and onboarding automation for teams.

Read time: 9 min

title: "Team Collaboration" description: "Shared rules, AI pair programming patterns, PR workflows, and onboarding automation for teams." section: "Full Guide" readTime: "9 min"

Team Collaboration

Cursor's impact compounds when the team shares rules, patterns, and workflows — not just individual developers acting independently.

Shared Config in Git

Commit your AI config alongside your code. New devs inherit the full setup automatically.

What to commit:

.cursor/
  rules/
    01-code-style.mdc
    02-testing.mdc
    03-pr-review-checklist.mdc
  skills/
  hooks.json
  mcp.json
AGENTS.md
.cursorignore

Never commit secrets in mcp.json; reference environment variables instead (for example ${env:DATABASE_URL}).

Add this to your onboarding docs:

After cloning:
1. Open the repo in Cursor
2. Project rules and AGENTS.md load automatically
3. Run: npm install
4. Check Customize for rules, skills, hooks, and MCP servers

Team Rules and Privacy

On Team and Enterprise plans, admins can create Team rules in the Cursor dashboard. They support glob patterns, can be saved as drafts, and can be enforced so members can't disable them. Precedence is Team, then Project, then User; all applicable rules merge and earlier sources win on conflicts.

Admins can also turn on Privacy Mode for the whole team from the dashboard (Settings) and optionally enforce it. With Privacy Mode, Cursor says your code is never used for training by Cursor or other model providers. It is on by default for Enterprise teams. Cursor's hooks can also be managed at team and enterprise level.

Putting Team Knowledge Where the Agent Reads It

Keep team knowledge in version-controlled files the agent loads on its own: rules for constraints, AGENTS.md for context, skills for workflows. Architecture decision records work well as a manual or glob-scoped rule.

Rule: Architecture Decision (.cursor/rules/adr-orders.mdc)

---
description: Event sourcing decisions for order state; read before touching order features
globs: src/orders/**
alwaysApply: false
---
 
# ADR-001: Event Sourcing for Orders
 
Status: Accepted
 
## Decision
Use event sourcing for order state management.
 
## Why
- Full audit trail required by compliance
- Undo/replay capability for support workflows
 
## Tradeoffs
- Higher initial complexity
- All devs need to understand event patterns
 
## When building order features, always:
- Reference @src/events/ for existing event types
- Emit events via EventBus, not direct DB writes
- Test with event replay scenarios

Onboarding prompt (new dev, first session):

I'm new to this repo. Walk me through the project structure and conventions,
using AGENTS.md and the rules in .cursor/rules/. Then suggest a good first task.

AI Pair Programming

Two patterns that work well for teams.

Driver-Navigator

Human plans the approach, AI implements. Use Plan Mode (Shift+Tab) to agree on the plan first:

Navigator (human):
1. We need pagination for the search results
2. Use cursor-based pagination (not offset) — see ADR-005
3. Max 50 items per page
4. Return: results[], nextCursor, hasMore

Driver (Cursor Agent):
@src/api/search.ts @src/types/pagination.ts

Implement cursor-based pagination per above spec.
Follow existing pattern in @src/api/orders.ts (already has pagination).

Parallel Exploration

Same problem, different approaches, isolated from each other. In the IDE, prefix a task with /worktree to run it in an isolated git worktree, or use /best-of-n to run the same task across several models, each in its own worktree:

/best-of-n sonnet,gpt,composer add caching to the search endpoint

Compare the results, then bring the winner into your main checkout with /apply-worktree. Best-of-N only compares; it doesn't merge anything. Use /delete-worktree when you're done.

PR Review Workflow

Before opening a PR — self-review. Attach your changes with @Commit (working-state diff) or @Branch (diff against main):

@Branch
@.cursor/rules/03-pr-review-checklist.mdc

Self-review this PR before I submit it.
Check each item in the PR checklist.
Flag anything that needs fixing.

PR checklist rule (.cursor/rules/03-pr-review-checklist.mdc):

---
description: PR review checklist; use when reviewing or preparing a pull request
alwaysApply: false
---
 
# PR Review Checklist
 
## Automated
- [ ] All tests pass
- [ ] No TypeScript errors
- [ ] No lint errors
 
## Code Quality
- [ ] No `any` types
- [ ] No magic numbers (use named constants or design tokens)
- [ ] Error and loading states handled
 
## Security
- [ ] All API inputs validated with Zod
- [ ] No secrets or credentials in code
- [ ] Authorization checks on all protected routes
 
## Testing
- [ ] Unit tests for new utilities
- [ ] Integration test for API changes
 
## Performance
- [ ] No N+1 queries
- [ ] No unnecessary large client imports

During review (as reviewer):

@Branch

Code review this PR.

Check for:
1. Logic errors or edge cases
2. Security issues (OWASP Top 10)
3. Missing tests for the changed behavior
4. Violations of our conventions (see the rules in .cursor/rules/)

For each finding: file path + line + explanation + suggested fix.

Bugbot

Bugbot is Cursor's automated PR reviewer. It reviews pull request diffs for bugs, security issues, and code quality problems, comments with explanations and fixes, and runs on each PR update. Connect your repositories in the Cursor dashboard and enable it per repository. Comment cursor review or bugbot run on a PR to trigger a review manually. Give it project context in .cursor/BUGBOT.md (root file always applies; nested files apply to their directories). Note that regular .mdc project rules don't apply to Bugbot. Findings can open directly in Cursor, and Autofix can spawn a Cloud Agent to push fixes.

Cloud Agents

Cloud Agents run in isolated cloud VMs with your repo and environment, so many can work in parallel without your machine staying online. Start one from the Cursor desktop dropdown (Cloud), cursor.com/agents, Slack, Linear, or by commenting @cursor on a GitHub or Bitbucket PR or issue. They need a paid plan, source control connected by an admin, and read-write repo access. They can open PRs with artifacts like screenshots and logs, and they run command-based hooks from .cursor/hooks.json.

Onboarding Automation

New devs can onboard themselves with AI guidance:

# Day 1 prompt for new dev
"I'm new to this codebase. Help me set up.

@package.json
@.env.example

1. Walk me through the project structure
2. What's the recommended first setup command?
3. What are the 3 most important conventions to know?
4. What's a good first task I could tackle?"

After completing the first feature:

"I'm about to open my first PR.
@Branch
@.cursor/rules/03-pr-review-checklist.mdc

Walk me through the checklist. Check each item against my changes."

Making It Stick

Common blockers and fixes:

ProblemFix
Rules ignoredCheck the file is .mdc in .cursor/rules/, and that the frontmatter matches the rule type you intended (alwaysApply, globs, description)
Devs not using CursorMake rules help (not block) — rules that guide, not just warn
AGENTS.md diverges from realityTreat it like code — require a PR to change it
Context drift in long sessionsStart a new chat per task (add it to your team process doc)
Inconsistent patterns across teamReview recurring review findings monthly and update rules
Rule only wanted for some peopleUse user rules for personal preferences; keep project rules for team standards