Priority Ordering Strategies

Claude reads CLAUDE.md top-to-bottom and assigns decreasing weight as it goes. This is not a documented guarantee — it is an observed behavior that has been confirmed by Anthropic engineers and validated through thousands of hours of production usage. The first 50 lines carry more weight than the next 200. The first section is the loudest voice in the room.

This means ordering is not a stylistic choice. It is an engineering decision with measurable consequences. Put your formatting preferences at the top and your security constraints at the bottom, and you will get beautifully formatted code that violates your security model. Put your security constraints at the top and your formatting preferences at the bottom, and you will get secure code that occasionally needs a manual formatting pass. The tradeoff is obvious once you see it, but most teams never see it because they organize their CLAUDE.md by topic rather than by priority.

The priority ordering algorithm is simple. Ask: if Claude violates this rule, what is the blast radius? Rules with catastrophic blast radius go first — never push to production, never delete the database, never commit secrets. Rules with moderate blast radius go second — always run tests before committing, always use TypeScript strict mode. Rules with cosmetic blast radius go last — use single quotes, prefer named exports, alphabetize imports.

Within each tier, order by frequency of violation. If Claude keeps generating CommonJS imports in an ESM project, that rule goes above the rule about alphabetizing imports — both are in the cosmetic tier, but one fires constantly and the other fires rarely.