Cursor Rules for Teams
A complete guide to setting up shared rules that encode discipline-specific expertise while maintaining cross-functional awareness.
Your marketing writer asks Cursor to draft a feature announcement. The output reads like API documentation. Your backend developer asks for database optimization help. The suggestions ignore your ORM conventions. Same tool, same codebase, wildly different needs.
Cursor rules solve this—but most teams treat them as developer-only documentation. They're missing the bigger opportunity: rules that help AI understand not just how to write code, but how different disciplines think about the same product.
Beyond Technical Documentation
Most Cursor rules guides focus on code conventions: "use TypeScript strict mode," "prefer functional components," "follow this API pattern." These are valuable. There are excellent resources for that baseline.
But cross-functional teams need more. When a product manager uses Cursor to draft requirements, or a marketer crafts release notes, or a designer documents component behavior—they need AI that understands their discipline's perspective while respecting the whole team's standards.
The Cross-Functional Opportunity
Four Types of Team Rules
After organizing rules across multiple repositories, patterns emerged. Teams benefit from four distinct rule categories:
Communication Rules
Standards everyone follows. 'Explain like I'm 5'—no acronyms unless universally understood. Clear naming conventions. These apply everywhere, all the time.
Persona Rules
Who is the AI being? A backend specialist who thinks in database optimization? A user-facing content writer who prioritizes clarity? Match the AI's voice to the task.
Domain Rules
Marketing copy patterns. Technical documentation standards. Design system conventions. Each discipline has its own expertise to encode.
Technical Rules
Code patterns, API conventions, testing requirements. The foundation most teams start with—and should keep building on.
Communication Rules: The Foundation
Communication rules are "always apply" rules—they shape every interaction regardless of who's using Cursor or what they're building.
Example: The 5th-Grader Rule
The principle: No acronyms unless previously spelled out. Clear communication is a competitive advantage.
Why it matters: A codebase used by frontend engineers, backend engineers, AI agents, designers, and product managers. An acronym obvious to one discipline may be meaningless—or mean something different—to another.
"RCA" could be "Root Cause Analysis" to an engineer or "the electronics brand" to someone else. Spell it out.
When AI follows communication rules, its output naturally works across disciplines. Marketing copy doesn't accidentally use developer jargon. Technical docs don't assume reader expertise.
Persona Rules: Teaching AI to Think Differently
Persona rules define how the AI should approach problems. They encode the mindset of a specialist, not just their technical patterns.
| Persona | How They Think |
|---|---|
| Backend Developer | Optimizes for database performance, API consistency, security implications |
| Frontend Developer | Considers component reusability, user experience, accessibility |
| Product Marketer | Focuses on user benefits, clear value propositions, avoiding technical jargon |
| Technical Writer | Prioritizes completeness, accuracy, progressive disclosure |
| Security Reviewer | Questions trust boundaries, data exposure, credential handling |
The power comes from combination. A marketer writing release notes can have AI that understands marketing voice while also knowing the technical product details. The AI holds both perspectives simultaneously.
Cross-Pollination Effect
Domain Rules: Discipline-Specific Expertise
Domain rules encode what makes good output within a discipline. They're the accumulated expertise of specialists, made accessible to AI.
Example: Content Writing Rules
These rules mean a product manager asking Cursor to help draft feature copy gets output that sounds human. The AI absorbed content expertise without the human needing to specify it each time.
Organizing Rules at Scale
As rule libraries grow, organization matters. A flat folder of 30+ rules becomes unnavigable. Teams benefit from categorical structure:
├── communication-standards.mdc # Always apply
├── 00-ai-onboarding.mdc # Session context
│
├── workflow/ # Development process
│ ├── daily-workflow.mdc
│ ├── github-flow.mdc
│ └── code-review-guidelines.mdc
│
├── frontend/ # React, components
│ ├── react.mdc
│ └── component-patterns.mdc
│
├── content/ # Writing standards
│ ├── ai-content-writing.mdc
│ └── documentation-practices.mdc
│
└── integrations/ # External services
├── analytics-events.mdc
└── slack-integration.mdcFolder structure signals intent. A marketer sees the content/ folder and knows where to find relevant rules. A developer navigates to frontend/. Both can find communication standards at the root.
The Always-Apply Pattern
Some rules should apply to every session, regardless of task. Cursor supports this with frontmatter configuration:
--- description: Communication standards - applies everywhere globs: alwaysApply: true --- # Communication Standards > No acronyms unless previously spelled out. These standards apply to all code, documentation, and collaboration...
Always-apply rules are your team's non-negotiables. They encode culture, not just conventions. When a new team member starts using Cursor, they automatically inherit the team's communication standards.
Getting Started
You don't need to build a comprehensive rule library immediately. Start with what hurts:
Rules compound. Each new rule makes Cursor more effective for the whole team. The investment pays dividends every time AI produces output that requires less correction.
Cursor rules are usually framed as developer tooling. They're actually team knowledge infrastructure. When different disciplines contribute their expertise to rules, AI becomes a genuine collaborator—one that can think from multiple perspectives without constant guidance.
The best AI assistance isn't just technically correct. It's contextually aware of how the whole team works.
Building your rule library?
I'm happy to share our team's rules structure and discuss what's worked. Reach out if you're setting up Cursor for a cross-functional team.