You already know how to use the .cursorrules file. But if you're on a team of 5+ people, or maintaining multiple projects of different types, a single-file rule set is far from sufficient.

This article covers the advanced usage of Cursor Rules—making rules truly become the team's "AI coding standard."

1. Cursor Rules Hierarchy

Cursor supports multiple layers of rules:

~/.cursor/rules/          ← Global rules (all projects)
  └── global.md
project/
  ├── .cursorrules         ← Project-level rules (old format, still supported)
  └── .cursor/
      └── rules/
          ├── base.mdc     ← Project base rules
          ├── frontend.mdc ← Frontend-specific rules (activated on demand)
          ├── backend.mdc  ← Backend-specific rules
          └── testing.mdc  ← Testing rules

Rule priority: project rules > global rules; more specific rules override more general ones.

2. .mdc Format: Automatically Triggered Rules

The new .mdc format is far more powerful than .cursorrules, supporting automatic activation by file type:

markdown

description: React component development standards
globs: ["src/components//*.tsx", "src/pages//*.tsx"]
React Component Standards
Naming Conventions
Component file names and function names must use PascalCase
Props interfaces must be named {ComponentName}Props
Event handler functions must be named handle{EventName}
Code Structure
Component file structure: imports → types → component → exports
No more than 200 lines; split into subcomponents if exceeded
Do not write business logic inside components; extract to hooks
State Management
Server state: React Query
Client global state: Zustand
Form state: React Hook Form + Zod
Prohibitions
No any types
No inline styles (unless dynamic values)
No complex logic in JSX; extract to variables

This rule only activates automatically when opening TSX files under src/components/ or src/pages/, without interfering with other files.

3. Team Rule Sharing Solutions

Option 1: Commit Rule Files to Git

Create rule files in the .cursor/rules/ directory and commit them directly to the code repository. Team members automatically get the same AI-assisted rules after cloning.

Suggested rule file structure:

.cursor/rules/
├── 00-project-overview.mdc   # Project overview (always active)
├── 01-code-style.mdc         # Code style (all files)
├── 02-react-components.mdc   # React component standards (tsx files)
├── 03-api-routes.mdc         # API route standards (app/api/ directory)
├── 04-database.mdc           # Database operation standards (/db/ directory)
└── 05-testing.mdc            # Testing standards (**/*.test.* files)

Option 2: Script-Based Unified Sync

If the team has multiple projects, maintain a "rules center" repository and sync with a script:

bash
#!/bin/bash
sync-cursor-rules.sh
RULES_REPO="git@github.com:your-org/cursor-rules.git"
TEMP_DIR=$(mktemp -d)
git clone $RULES_REPO $TEMP_DIR
cp -r $TEMP_DIR/rules/* .cursor/rules/
rm -rf $TEMP_DIR
echo "Rules synced!"

4. Advanced Rule Techniques

4.1 Inject Project Context with Rules

markdown

description: Project architecture context (active for all files)
globs: ["**/*"]
Project Overview
This is a B2B SaaS project that helps businesses manage AI tool subscriptions.
Core Concepts
Organization: Enterprise account, can have multiple Users
Subscription: Subscription record, linked to Organization and Plan
Plan: Subscription plan (Free/Pro/Enterprise)
Tech Stack
Frontend: Next.js 15 + TypeScript + Tailwind CSS v4
Backend: Supabase (PostgreSQL + Edge Functions)
Auth: Clerk
Deployment: Vercel
Important Conventions
All database operations go through functions in src/lib/db/
API routes do not query the database directly
User permission checks are done in the middleware layer

4.2 Rules to Prevent Common Mistakes

markdown
Security Checklist (automatically checked when generating code)
When generating code involving the following scenarios, you must actively check:
SQL Injection: All database queries must use parameterized queries
XSS: User input must be escaped before HTML rendering
CSRF: APIs that modify state must verify the source
Privilege Escalation: Users can only access their own data; add userId filtering in queries
Sensitive Data: Logs must not contain passwords, tokens, or phone numbers

4.3 Example Code in Rules

Good rules include "do this" and "don't do this" comparisons:

markdown
API Error Handling Standards
✅ Correct approach:

typescript export async function GET(req: Request) { try { const data = await fetchData(); return Response.json({ data }); } catch (error) { console.error('[API Error]', error); return Response.json({ error: 'Internal server error' }, { status: 500 }); } }

❌ Prohibited approach (no error catching):

typescript export async function GET(req: Request) { const data = await fetchData(); // No try-catch return Response.json({ data }); }

5. Rule Maintenance Tips

Regular review: Check rules monthly to ensure they are still accurate (rules may become outdated after tech stack upgrades)

Team collaboration: Rules should be a team consensus, not set by one person

Incremental addition: Start with the most important rules; don't write hundreds of lines at once (Cursor can't read them all)

Test rule effectiveness: After writing rules, have Cursor generate some code to see if it meets expectations

---

Further Reading

Claude Code Complete Tutorial

Windsurf vs Cursor vs Claude Code Comparison

GitHub Copilot Advanced Tips 2026