Team vs Personal Rules

There is a clean line between what belongs in project CLAUDE.md and what belongs in your personal config. The project file is a shared contract — it encodes team conventions, architectural decisions, and build/validation commands that every developer needs. The personal file is your private workspace — communication preferences, editor quirks, workflows that only matter to you. Crossing this line in either direction causes problems.

When personal preferences leak into the project file, you get noise. "Always respond in bullet points" is not a team convention. "Use British spelling" is not an architectural decision. Every personal rule you add to the project CLAUDE.md costs your entire team context tokens on every session. Multiply your 50-word preference by ten developers across hundreds of sessions, and you have burned real money on rules that help one person and confuse nine others.

When team rules live only in personal configs, you get drift. If "run tsc --noEmit before committing" lives in your personal file instead of the project file, your teammates will not have that rule. Their Claude instances will skip type checking. The codebase will accumulate type errors that only your sessions catch. Team rules must live in the shared file or they are not team rules — they are suggestions that most people never see.