Team Claude Rules: Sharing Configurations Across Your Team

The Team Consistency Problem

Without shared rules, different engineers get different behavior from Claude. One developer's Claude always writes TypeScript; another's defaults to JavaScript. One gets clean REST API patterns; another gets a mix of styles.

A shared CLAUDE.md in version control solves this. Every developer on the team — and every CI pipeline — uses the same Claude behavior.

The Two-Layer Strategy

The most effective approach combines personal and team rules:

Personal Rules (~/.claude/CLAUDE.md)

Communication style, editor preferences, personal tools. These are yours and not shared with the team.

Team Rules (project root CLAUDE.md)

Tech stack, coding conventions, architecture decisions. Committed to git — applies to the whole team.

Setting Up Team Rules

Start by running a short workshop with your team to capture your most common Claude corrections. Ask everyone:

What do you find yourself correcting Claude on most often?
What architectural decisions should Claude always know about?
What are the "never do this" rules for our codebase?

CLAUDE.md

# Acme Engineering — Claude Rules
# Last updated: 2025-01-15
# Maintainer: @engineering-team in #claude-rules Slack channel

## Project
E-commerce platform built on Next.js 15 App Router, TypeScript, Prisma + PostgreSQL.
Monorepo with apps/web, apps/admin, packages/ui.

## Non-Negotiables
1. NEVER skip TypeScript types — no `any`
2. NEVER modify the database schema without a team discussion first
3. NEVER add new npm packages without opening a PR first
4. ALWAYS run `npm run test` before committing

## Code Style (enforced by ESLint/Prettier — these are additional rules)
- Named exports everywhere
- React: Server Components by default, "use client" requires justification
- API routes: Zod validation at the input boundary
- Error handling: typed Result<T> pattern (see lib/result.ts)

## Architecture Decisions
- Auth: NextAuth.js v5 — don't use other auth libraries
- Email: Resend — not nodemailer or SendGrid
- File storage: Cloudflare R2 — not AWS S3
- Payments: Stripe — no other payment processors

## Getting Help
If unsure about a pattern, check our engineering handbook at notion.so/acme/handbook
or ask in #engineering Slack before implementing.

Maintaining Team Rules Over Time

Assign a CLAUDE.md maintainer (or rotate the responsibility). When the team adopts a new pattern or drops a library, the CLAUDE.md should be updated in the same PR.

Add a Last updated date to the top of your CLAUDE.md. This helps teammates know if it's current and creates a healthy forcing function to review it regularly.

Consider adding a lint rule or CI check that warns when CLAUDE.md hasn't been updated in more than 90 days. A stale CLAUDE.md is often worse than none.

Onboarding New Engineers

A well-maintained CLAUDE.md doubles as onboarding documentation. New engineers can read it to understand the project's conventions before writing a single line of code.

Consider structuring the team CLAUDE.md so it also serves as a "new engineer quick reference." Add links to the engineering handbook, design system, and architecture decision records.