Team Collaboration: Tips 106-112

Your team has five developers using Cursor. Each one has different global rules, different model preferences, different prompting styles. One developer’s agent generates code with semicolons; another’s generates code without. One uses any types everywhere; 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. These 7 tips turn individual Cursor setups into a coordinated team workflow.

What You Will Walk Away With

• A committed .cursor/rules/ directory that makes AI-generated code consistent across the entire team
• An onboarding checklist that gets new team members productive with Cursor in a single day
• An AI-assisted code review process that catches issues before human reviewers spend time on them
• Shared prompt templates that encode your team’s best practices into reusable files
• A security policy that balances productivity with compliance requirements

Shared Configuration

Tip 106: Commit Your Cursor Rules to Version Control

This is the single most important team tip. Project rules belong in version control, not in individual developer settings. When rules are committed, every developer and every agent conversation uses the same constraints.

Create the rules directory and commit it:

mkdir -p .cursor/rules

At minimum, create these files:

.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."

Tip 107: Standardize MCP Server Configuration

If your team uses MCP servers (database, GitHub, Jira), commit the configuration so every developer has the same setup:

.cursor/mcp.json

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "${DATABASE_URL}" }
    }
  }
}

Document the required environment variables in your project’s README or onboarding guide. Each developer sets their own tokens, but the MCP server configuration is shared.

Tip 108: Create Shared Prompt Templates

Save commonly used prompts as files in the repo so any team member can reference them:

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 reference these with @.cursor/prompts/new-endpoint.md in any agent conversation. The prompts encode your team’s best practices so that even the newest team member produces consistent output.

Onboarding and Training

Tip 109: Create a Cursor Onboarding Checklist for New Team Members

When a new developer joins the team, they should be productive with Cursor within a day. Create an onboarding document:

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. Enable YOLO mode: Settings > Features > YOLO Mode (use the team allow-list from this doc)
5. Set default model to Claude Sonnet 4.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 (Tip 61)
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

Tip 110: Run Weekly “Cursor Tips” Standups

Dedicate 5 minutes of one weekly standup to Cursor tips. Each week, one team member shares:

• A prompt that worked particularly well
• A workflow they discovered
• A problem they could not solve with Cursor (the team might have a solution)
• A suggestion for a new project rule

This creates a feedback loop where the team continuously improves its Cursor usage. The best prompts and workflows get added to .cursor/prompts/ for everyone to use.

Code Review and Quality

Tip 111: Implement AI-Assisted Pre-Review

Before requesting a human code review, have every team member run an AI review:

1. Developer finishes their feature
2. Developer runs @.cursor/prompts/pre-pr.md to fix linting, types, and tests
3. Developer runs Bug Finder (Cmd+Shift+P > “Bug Finder”)
4. Developer runs the AI code review prompt below
5. Developer fixes issues found in steps 2-4
6. Developer opens PR for human review

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.

This pre-review catches 60-70% of the issues that a human reviewer would flag. Human reviewers can then focus on architecture decisions, business logic correctness, and design trade-offs — the things AI is worst at.

Security and Compliance

Tip 112: Establish a Team Security Policy for AI Tools

Create a security policy that balances productivity with compliance:

.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

### YOLO Mode Restrictions
Allow: test commands, build commands, linting, file creation
Deny: rm -rf, sudo, ssh, curl to external URLs, git push, npm publish, deploy commands

Commit this to your repo and review it during onboarding. Update it as your team’s security requirements evolve.

When This Breaks

Team members override project rules with personal settings: Global user rules take precedence over project rules for some settings. Make sure the project rules document does not conflict with common personal preferences. If conflicts arise, have a team discussion to standardize the convention and update the project rules.

Onboarding checklist becomes outdated: Assign one team member to update the onboarding checklist whenever Cursor releases a significant update or the team changes a workflow. Review it quarterly at minimum.

AI code review is too noisy: If the AI review prompt generates too many false positives, refine it. Add exceptions for known patterns: “Our project intentionally uses ‘any’ types in the GraphQL resolver layer — do not flag these.” The more specific the prompt, the fewer false positives.

MCP server tokens expire: Set calendar reminders for token renewal. Document the token rotation process in your onboarding guide. Consider using short-lived tokens from your organization’s secret management system.

What is Next

You have completed the full 112-tip collection. Your individual workflow is optimized, your team is configured for consistency, and you have the advanced techniques to handle any development challenge.

To continue growing:

• Browse the Cursor Advanced Techniques section for deep dives into agent modes, checkpoints, and automation workflows
• Explore Productivity Patterns for keyboard shortcuts, debugging workflows, and testing strategies
• Check Version Management to stay current with Cursor’s latest features
• Return to this Tips Collection index whenever you need a refresher on specific techniques