Team Collaboration

Team collaboration in Cursor rests on shared configuration rather than individual skill: project rules, MCP settings, prompt files, and slash commands committed to version control, plus dashboard-managed Team Rules that outrank both project and personal rules. The result is that a new developer’s agent output matches a veteran’s on day one.

Eight engineers all use Cursor and the output quality varies wildly. One developer’s AI-generated API routes include error handling, validation, and logging. Another’s are missing error handling entirely. A third keeps getting var instead of const because their personal rules override the project settings. One agent writes semicolons, another does not; one scatters any types, another writes strict TypeScript.

The AI-generated code looks like it was written by five different people because it was configured by five different people. The fix is not better prompting on each machine — it is moving the configuration into the repository, where it is reviewed, versioned, and identical for everyone.

What a coordinated Cursor team setup gives you

• A committed .cursor/rules/ directory that makes AI-generated code consistent across the whole team
• Team Rules configuration for Cursor’s Team and Enterprise plans, and the precedence order that decides which rule wins
• Shared MCP configuration so every developer’s agent has the same tools
• Reusable prompt files and slash commands that encode your team’s best practices
• An onboarding checklist that gets a new developer productive with Cursor in a day
• An AI-assisted pre-review process that spends human review time on judgment instead of checklists
• A security policy that balances productivity with compliance

Shared project rules in version control

This is the single most important team practice: project rules belong in the repository, not in individual developer settings. Every rule in .cursor/rules/ is available to every developer who clones the repo, and every agent conversation runs under the same constraints.

mkdir -p .cursor/rules

The starter rule every team needs

Begin with one always-applied rule that names the stack and the non-negotiables:

Tip

Copy-paste: starter rules for team consistency

Create .cursor/rules/project-standards.mdc:

---
alwaysApply: true
---

Project: [Your project name]
Stack: [Your tech stack]

Code standards:
- TypeScript strict mode, no `any` types
- All public functions must have JSDoc comments
- Error handling: use AppError from @src/lib/errors.ts
- Logging: use logger from @src/lib/logger.ts, never console.log
- Tests: Vitest, test files adjacent to source

When creating new files, check for existing patterns before inventing new ones.
Reference @src/routes/users.ts for API patterns.
Reference @src/components/UserProfile.tsx for component patterns.

Splitting the rules that grow

The starter rule stays short because it is always applied. Everything longer belongs in its own file, so the agent loads it when it is relevant instead of on every message:

.cursor/rules/code-style.md

## Code Style

- TypeScript strict mode. No 'any' types except where explicitly documented.
- Named exports only. No default exports.
- Functional components with hooks for React.
- camelCase for variables and functions. PascalCase for types, interfaces, and components.
- Use async/await. Never use .then() chains.
- All async functions must have try-catch error handling.
- Prefer fetch over axios for HTTP requests.
- Use pnpm for all package manager commands.

.cursor/rules/testing.md

## Testing Conventions

- Use vitest for all unit and integration tests.
- Test files live next to the code they test: src/services/__tests__/user.test.ts
- Use descriptive test names that explain the scenario: "should return 404 when user does not exist"
- Mock external dependencies (database, APIs) but not internal modules.
- Aim for 80% code coverage on new code.
- Always test error cases, not just happy paths.

.cursor/rules/architecture.md

## Architecture Rules

- API routes in src/api/ handle HTTP concerns only (parsing, validation, response formatting).
- Business logic goes in src/services/. Services never import from src/api/.
- Database operations go in src/repositories/. Services use repositories, never raw queries.
- Shared types go in src/types/. Types are the only thing that every layer can import.
- Do not create circular dependencies. If service A needs service B, inject it as a parameter.

Copy-paste git commit for initial rules

git add .cursor/rules/
git commit -m "Add Cursor project rules for consistent AI behavior

Adds code style, testing, and architecture rules that apply to
all AI-generated code. These ensure consistency across team members."

Keeping the rules alive

Treat rules like code, because they rot like code:

• Rule reviews in PRs: adding or modifying a rule goes through the same review as any other change
• Rules updated from mistakes: when a human review catches a pattern the agent got wrong, update the rule in the same PR so it cannot recur
• A quarterly audit: remove outdated references and add the patterns the team started using since

Tip

Copy-paste prompt for rule maintenance:

Review the rules in @.cursor/rules/ and identify:
1. Rules that reference files or patterns that no longer exist in the codebase
2. Rules that contradict each other
3. Patterns we use frequently that are not documented in any rule
4. Rules that are too long (Cursor recommends keeping rules under 500 lines) and should be split

Output a summary of recommended changes.

Team Rules, managed from the dashboard

Cursor’s Team and Enterprise plans add Team Rules, managed centrally from the Cursor dashboard and applied to all team members across all projects.

Team Rules or project rules?

Use Case	Team Rules	Project Rules
Organization-wide coding standards	Yes	No
Security and compliance requirements	Yes	No
Project-specific architecture patterns	No	Yes
Technology-specific conventions	No	Yes
Communication style preferences	Yes	No

Setting them up

1. Open the Cursor dashboard at cursor.com/dashboard
2. Navigate to the team content tab
3. Click “Add Rule” to create a new team rule
4. Write the rule as free-form plain text (Team Rules do not support globs, alwaysApply, or rule types)
5. Choose whether to enforce the rule (prevents team members from disabling it)
6. Enable the rule to make it active

Which rule wins

The precedence order is Team Rules > Project Rules > User Rules. An enforced Team Rule overrides any conflicting project or personal rule, which is what makes it the right home for the standards that must not vary: security practices, error handling patterns, compliance requirements.

Standardizing MCP configuration

If your team uses MCP servers (database, GitHub, Jira), commit the configuration so every developer has the same tools available. Use the maintained servers — the old @modelcontextprotocol/server-github and @modelcontextprotocol/server-postgres npm packages are both deprecated (“no longer supported”). GitHub’s first-party server now ships as a remote endpoint, and the reference Postgres server moved to the archive:

.cursor/mcp.json

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer ${GITHUB_TOKEN}" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@henkey/postgres-mcp-server", "--connection-string", "${DATABASE_URL}"]
    }
  }
}

The GitHub entry uses the hosted github/github-mcp-server (https://api.githubcopilot.com/mcp/); for an air-gapped or self-hosted team, swap it for the Docker stdio build from that same repo. For Postgres, @henkey/postgres-mcp-server (or crystaldba’s postgres-mcp) is maintained and read-aware. Document the required environment variables in your README or onboarding guide — each developer supplies their own tokens, but the server configuration is shared.

Shared prompts and custom commands

Prompt files anyone can reference

Save the prompts your team runs repeatedly as files in the repo:

mkdir -p .cursor/prompts

.cursor/prompts/new-endpoint.md

Create a new API endpoint following these project conventions:

1. Route handler in src/api/[resource]/route.ts using the pattern in @src/api/users/route.ts
2. Service layer in src/services/[resource].ts using the pattern in @src/services/user.ts
3. Type definitions in src/types/[resource].ts
4. Vitest tests in src/services/__tests__/[resource].test.ts
5. Zod validation schema for request body
6. Proper error handling using our AppError class from @src/lib/errors.ts

Run pnpm test after implementation to verify everything passes.

.cursor/prompts/pre-pr.md

Review and fix all issues before this PR is ready:

1. pnpm run typecheck -- fix TypeScript errors
2. pnpm run lint -- fix linting issues
3. pnpm run test -- fix test failures (do not modify assertions)
4. Remove any console.log/debug statements
5. Verify all new exports are added to index files
6. Check that no sensitive data (API keys, passwords) is committed

Summarize all changes made.

Team members pull these into any agent conversation with @.cursor/prompts/new-endpoint.md. The prompt encodes the team’s conventions, so the newest member produces the same shape of output as the longest-serving one.

Slash commands for the workflows everyone runs

Custom slash commands live in .cursor/commands/ and are invoked with a / prefix. They are the right form for a workflow with no arguments that everybody runs the same way.

Note

Custom commands are currently in beta in Cursor. The feature and its frontmatter syntax may change, so pin the behavior you rely on in a team rule and re-check after major Cursor updates.

Create .cursor/commands/review.md:

---
description: Review code changes for quality, security, and consistency
---

Review the current changes (use git diff to see them) and check for:

1. **Security**: SQL injection, XSS, hardcoded secrets, missing auth checks
2. **Error handling**: All async operations have try/catch, errors use AppError format
3. **Testing**: New logic has corresponding tests, edge cases are covered
4. **Patterns**: Code follows existing patterns in the codebase (check similar files)
5. **Performance**: No N+1 queries, no unnecessary re-renders, no blocking operations

For each issue found, provide:
- The file and line number
- What the issue is
- A specific fix

Use only search tools -- do not make any edits.

And .cursor/commands/pr-description.md:

---
description: Generate a PR description from current changes
---

Analyze the current branch changes (compare against main) and generate a PR description with:

1. **Summary**: 2-3 sentence overview of what changed and why
2. **Changes**: Bulleted list of specific changes, organized by area
3. **Testing**: How these changes were tested
4. **Migration notes**: Any database changes, environment variable additions, or breaking changes

Use git diff main...HEAD to see all changes. Do not make any edits.

Onboarding a new developer

Most of onboarding happens by cloning: .cursor/rules/, .cursor/commands/ and .cursor/prompts/ arrive with the repo, and dashboard Team Rules apply automatically. What is left is the machine setup and the first few hours of guided practice.

Copy-paste onboarding checklist

# Cursor Onboarding Checklist

## Day 1 Setup (2 hours)

1. Install Cursor: `brew install --cask cursor`
2. Import VS Code settings: Cmd+Shift+P > "Import VS Code Settings"
3. Install shell commands: Cmd+Shift+P > "Install cursor command in PATH"
4. Configure Auto-Run: Settings > Cursor Settings > Agents > Auto-Run. Choose Run in Sandbox (recommended) or Ask Every Time, and add the team Command Allowlist from this doc. Do not enable Run Everything.
5. Set default model to Claude Sonnet 5
6. Clone the repo and verify indexing completes (should take under 5 minutes)
7. Verify project rules load: open agent, ask "What rules apply to this project?"
8. Set up required environment variables for MCP servers

## Day 1 Practice (2 hours)

1. Use Cmd+K to add error handling to any function in the codebase
2. Use agent mode to implement a small bug fix from the backlog
3. Use @.cursor/prompts/pre-pr.md to run the pre-PR checklist
4. Try the Tab completion flow: write two test cases manually, let Tab generate the third
5. Generate a commit message using the sparkle icon in Source Control

## First Week

1. Complete one feature using the test-driven agent workflow
2. Use Ask mode to understand one unfamiliar module
3. Try a background agent for generating test coverage on a module
4. Review and improve one project rule based on your experience

Two things are worth doing in person rather than on the checklist: have them run one task in Ask mode before touching Agent mode, so they build a model of the codebase first, and pair on their first Agent mode task to demonstrate what an effective prompt looks like in this repo.

Keeping the practice improving

Give five minutes of one weekly standup to Cursor. Each week, one person shares a prompt that worked unusually well, a workflow they found, a problem they could not solve (the team often can), or a suggestion for a new project rule.

That is the feedback loop that keeps the shared configuration from going stale: the best prompts land in .cursor/prompts/, the recurring corrections become rules, and the whole team moves rather than one enthusiast.

Reviewing AI-generated code as a team

AI-generated code needs a different review lens. The agent follows patterns well but misses business logic, introduces security gaps, and over-engineers simple things.

What to watch for in AI-generated PRs

• Hallucinated imports: packages that are not in your dependencies
• Inconsistent patterns: a different pattern than the one that exists, especially where rules are incomplete
• Missing edge cases: the happy path handled well, the error paths not at all
• Over-engineering: abstractions, caching, or error handling the feature does not need yet
• Security blind spots: SQL injection through string concatenation, missing auth checks, hardcoded test credentials left in production code

The pre-review pipeline

Before requesting a human review, every team member runs the AI pass:

1. The developer finishes the feature
2. They run @.cursor/prompts/pre-pr.md to fix linting, types, and tests
3. They run Bugbot on the branch or PR (Cursor’s automated bug detection)
4. They run the team review prompt below
5. They fix everything found in steps 2-4
6. They open the PR for human review

This pre-review catches most of what a human reviewer would otherwise flag, which frees the human to look at architecture decisions, business logic correctness, and design trade-offs — exactly where AI is weakest.

The prompts that drive it

The saved /review command above is what most people run day to day. Paste the longer prompt instead when you want the review to consult the committed rules explicitly and hunt for architecture violations such as circular dependencies:

Copy-paste team code review prompt

@git diff main

Review this PR as a senior engineer on this team. Reference our project rules in @.cursor/rules/ for standards.

Check for:
1. Architecture violations (direct database access from routes, circular dependencies)
2. Missing error handling on async operations
3. Type safety issues (any types, missing null checks)
4. Test coverage gaps for new functionality
5. Naming inconsistencies with existing code
6. Security issues (unvalidated input, exposed credentials, SQL injection)

For each issue found, explain why it matters and suggest a specific fix.

The last check before submitting is narrower and mechanical — the things that are embarrassing rather than architectural:

Tip

Copy-paste prompt for pre-submission self-review:

Before I submit this PR, review all my changes and check for:

1. Any imports of packages not in package.json
2. Any TODO comments or placeholder values I need to fill in
3. Any console.log statements that should use the logger
4. Any hardcoded URLs, API keys, or test values
5. Any missing error handling on async operations
6. Any new files that are missing test coverage

Run `npm run build` and `npm test` to verify everything passes.

A security policy for AI tools

Write the policy down as a rule so it is enforced by the same mechanism as everything else, and review it during onboarding:

.cursor/rules/security.md

## AI Security Policy

### What the AI Can Access
- All source code in the repository
- Development and staging databases via MCP (never production)
- Public documentation and APIs
- CI/CD logs and build artifacts

### What the AI Must Not Do
- Access production databases or servers
- Commit or push code without human review
- Store API keys, passwords, or secrets in code
- Disable security middleware or authentication checks
- Modify .env files or deployment configurations

### Privacy Requirements
- Enable Privacy Mode for all proprietary code
- Do not paste customer data into agent conversations
- Do not reference internal company documents by URL
- Review all AI-generated code for accidentally exposed credentials

### Auto-Run Restrictions
- Set Auto-Run Mode to Run in Sandbox or Ask Every Time. Never enable Run Everything.
- Restrict the Command Allowlist to test, build, lint, and file-creation commands only.
- Keep git push, deploy, npm publish, and any credential-touching commands off the allowlist so they always require approval.
- Do not rely on a denylist. Cursor deprecated the command denylist in 1.3 (it was trivially bypassable); the sandbox plus a tight allowlist is the supported safety model.

On a Team or Enterprise plan, promote the non-negotiable half of this to an enforced Team Rule. A security standard that an individual can disable in their own settings is a suggestion.

When team conventions break down

People get different output despite the shared rules. User Rules have the lowest precedence, so they cannot override Team or Project Rules — but uncommitted local rule files can still be in play. Check for rule files that never made it into the repo, and where a personal preference genuinely conflicts with a project rule, settle it as a team and update the rule rather than letting both exist.

Rules go stale as the codebase evolves. Make rule updates part of the change itself: when you refactor a pattern a rule references, update the rule in the same PR.

Too many rules slow the agent down. Rules consume context tokens. Thirty rules with alwaysApply: true means every conversation starts with significant overhead. Audit which ones truly need to be always-applied rather than glob-scoped or agent-decided.

The AI review is too noisy. Refine the prompt with your exceptions: “Our project intentionally uses ‘any’ types in the GraphQL resolver layer — do not flag these.” The more specific the prompt, the fewer false positives, and the more likely people keep running it.

Nobody knows which commands exist. The / prefix lists them in chat, but new team members do not know to look. Document them in the README or contributing guide alongside the prompt files.

The onboarding checklist goes out of date. Give one person the job of updating it whenever Cursor ships a significant release or the team changes a workflow, and review it quarterly at minimum.

MCP server tokens expire. Set calendar reminders for renewal and document the rotation process in the onboarding guide. Short-lived tokens from your organization’s secret management system are better than long-lived ones in a .env.

Where to go next with team collaboration

• Custom Rules and Templates — a deeper dive into building the rules your team needs
• Privacy and Security — enforce security practices through Team Rules
• Token Management — manage costs across a team of Cursor users
• Code Review — the review surfaces this pipeline plugs into