Team Rules vs Personal Rules: When to Split

Two Types of Rules for Different Purposes

Team rules are: coding conventions the entire team agrees on, committed to the repository, and enforced by CI. Examples: "Use React Server Components by default." "Validate all inputs with Zod." "Use Drizzle ORM, not Prisma." "Test with Vitest and React Testing Library." These rules ensure: every developer (and their AI tools) produces consistent code. Team rules live in: CLAUDE.md (committed to git), .cursorrules (committed), copilot-instructions.md (committed). Changing team rules requires: a PR reviewed by the team.

Personal rules are: individual workflow preferences that do not affect the shared codebase. Examples: "Provide brief explanations before code." "Always show file paths in suggestions." "Use concise variable names in examples." "Default to verbose error messages during debugging." These rules affect: how the AI communicates with you, not what code it generates. Personal rules live in: global Claude Code settings (~/.claude/CLAUDE.md), Cursor global rules (Cursor Settings > Rules for AI), or personal .cursorrules in home directory. Personal rules are: not committed to the repository.

The split matters because: team rules enforce consistency (everyone follows the same conventions). Personal rules enable productivity (each developer interacts with AI their preferred way). Mixing them: team rules in personal settings means new developers do not get the conventions. Personal preferences in the repo mean: the team debates individual communication style in PRs. Keep them separate: team conventions in the repo, personal preferences in global settings.

What Belongs in Team Rules vs Personal Rules

Team rules (committed to repo): technology choices ("Use TypeScript, React, Tailwind"), architectural patterns ("Server Components default, use client for interactivity"), library selections ("Zustand for state, TanStack Query for server data"), naming conventions ("camelCase functions, PascalCase components, UPPER_SNAKE constants"), testing requirements ("Vitest, minimum 80% coverage, test files alongside source"), error handling ("Result types for expected, throw for unexpected"), security rules ("parameterized queries, Zod validation, no secrets in code"), and file structure ("feature folders with co-located components, tests, and hooks").

Personal rules (global settings, not committed): communication style ("Be concise, skip explanations unless asked"), output format ("Show file paths as relative from project root"), learning preferences ("Explain TypeScript generics in detail when used"), workflow preferences ("Always create a git branch before making changes"), and editor-specific behavior ("In Cursor Composer, show diffs for review before applying"). These preferences: affect how the AI interacts with the individual developer but produce the same code output regardless of who is coding.

The litmus test: would a different developer's preference for this rule change the code output? If yes: team rule (it affects what code is generated). If no: personal rule (it affects how the AI communicates but not the code). "Use async/await" = team rule (changes code output). "Be verbose in explanations" = personal rule (changes AI communication, not code). "Use Zustand" = team rule. "Show me alternative approaches before implementing" = personal rule.

• Team rules: technology, patterns, libraries, naming, testing, security, structure — affect code output
• Personal rules: communication style, output format, learning, workflow — affect AI interaction
• Litmus test: does a different developer's preference change the code? Yes = team. No = personal
• Team rules: committed, reviewed in PRs, enforced by CI. Personal: global settings, not committed
• "Use async/await" = team (code output). "Be concise" = personal (AI communication)

The Global + Project Hierarchy

Claude Code hierarchy: global rules (~/.claude/CLAUDE.md) apply to all projects. Project rules (project/CLAUDE.md) apply to one project. Project rules: add to and can override global rules. A developer with global: "Be concise, skip preamble" and project: "Use TypeScript strict, React Server Components" gets: concise communication (global) with TypeScript React patterns (project). The project rules handle: team conventions. The global rules handle: personal preferences.

Cursor hierarchy: global rules (Cursor Settings > Rules for AI) apply to all projects. Project rules (.cursorrules at project root) apply to one project. Same model: global for personal, project for team. Cursor also supports: workspace rules that override project rules for specific workspace configurations. The three levels: global (personal) < project (team) < workspace (team override). Most developers: use global + project only.

The hierarchy prevents conflict: project-level team rules override global personal preferences where they overlap. Global: "Prefer verbose explanations." Project: "Be concise in code generation." Result: the AI is concise for code (team rule wins in the project context). The team's convention takes priority in the project; the developer's preference applies outside projects or in areas the team rules do not cover. No manual conflict resolution needed — the hierarchy handles it.

• Global: personal preferences, applies to all projects (~/.claude/CLAUDE.md or Cursor settings)
• Project: team conventions, applies to one project (CLAUDE.md or .cursorrules in repo)
• Project overrides global: where they overlap, team convention wins in the project context
• No conflict: hierarchy resolves automatically — project > global for the same standard
• Global covers: areas the project rules do not address (communication style, workflow)

Common Mistakes and How to Fix Them

Mistake 1: personal preferences in the committed rule file. The CLAUDE.md says: "Always explain your reasoning before writing code." Developer B finds this annoying and changes it to: "Skip explanations, just show the code." PR conflict about communication style — not about code standards. Fix: move communication preferences to personal global settings. The committed CLAUDE.md: only team conventions that affect code output.

Mistake 2: team conventions in personal global settings only. A developer configures their global rules with all the team conventions. Result: only that developer's AI follows the conventions. New team members: start with generic AI behavior. The conventions are: in one person's head, not in the repository. Fix: move team conventions to the committed CLAUDE.md. Every developer (and every new team member) gets the conventions automatically.

Mistake 3: no personal rules at all. Every developer uses only the committed team rules. Result: the AI communicates the same way with every developer (the default style). Developers who prefer concise output: get verbose. Developers who want explanations: get terse. Nobody's AI interaction is optimized for their workflow. Fix: each developer configures personal global rules for: communication style, output format, and workflow preferences. The AI adapts to each person while following the same team conventions.

• Mistake 1: personal style in committed file → PR conflicts about preferences. Fix: personal goes global
• Mistake 2: team conventions in personal only → only one dev gets them. Fix: commit team rules to repo
• Mistake 3: no personal rules → AI interaction not optimized per developer. Fix: configure global settings
• Rule of thumb: if it affects code = committed. If it affects AI communication = personal global
• New developers: team rules from repo (automatic). Personal rules: they configure themselves

Practical Setup: Team + Personal

Step 1: write the team CLAUDE.md (committed to repo). Content: project stack, framework patterns, library choices, naming, testing, security, file structure. Length: 500-1500 words (see the optimal length article). This file: every developer and every AI tool reads on every interaction. It is: the team convention source of truth for AI-generated code.

Step 2: each developer configures personal global rules. Claude Code: create ~/.claude/CLAUDE.md with personal preferences. Cursor: open Cursor Settings > Rules for AI, add personal rules. Content: communication style ("Be concise, lead with the code"), output preferences ("Show file paths relative to project root"), workflow ("Suggest tests after implementing a feature"), and learning ("Explain new TypeScript patterns when you use them"). These rules: are not committed anywhere, each developer owns their own.

Step 3: verify the hierarchy. In the project: the AI should follow team conventions (test: ask it to create a component, verify it follows the committed CLAUDE.md patterns). Outside the project: the AI should follow personal preferences (test: open a scratch file, verify it communicates in your preferred style). If the project rules override personal preferences correctly: the setup is working. Both layers active simultaneously, zero conflict.

• Team CLAUDE.md: committed, 500-1500 words, stack + patterns + conventions
• Personal global: ~/.claude/CLAUDE.md or Cursor Settings, communication + workflow preferences
• Verify: team conventions apply in project, personal preferences apply outside or in gaps
• New developer onboarding: git clone gives team rules. Personal rules: 5-minute global setup
• Result: consistent code (team rules) + optimized AI interaction (personal rules)

Comparison Summary

Summary of team rules vs personal rules.

• Team rules: committed to repo, affect code output, team-reviewed, CI-enforced
• Personal rules: global settings, affect AI communication, individually configured, not committed
• Litmus test: changes code output = team. Changes AI interaction = personal
• Hierarchy: project (team) > global (personal). Team conventions override personal where they overlap
• Mistake 1: personal style in repo (PR conflicts). Mistake 2: team conventions only in personal (not shared)
• Setup: committed CLAUDE.md (team) + ~/.claude/CLAUDE.md (personal). Both active simultaneously
• New developers: team rules from git clone (automatic). Personal rules: 5-minute self-setup
• Result: consistent code across the team + optimized AI interaction per developer