Everything in CLAUDE.md gets loaded into every session. That includes the note about a bug you fixed last month and the naming rule for one folder you rarely touch. The file grows, the signal gets buried, and the rules that matter get followed less consistently. Here’s how I’d split it: Keep in CLAUDE.md: the package manager, the build/test/lint commands, architectural constraints the code doesn’t make obvious, conventions that apply to most changes, and mistakes worth remembering across tasks. Keep in the prompt: the specific feature or bug, its acceptance criteria, and any temporary constraint that shouldn’t leak into unrelated work. Scope the rest: if a rule only applies to part of the codebase, put it in .claude/rules/ with a path scope. A migration convention doesn’t need to load while you’re fixing CSS. One more thing people miss: CLAUDE.md is guidance, not enforcement. If something must happen every time, like a check before a certain action, use a hook or an external validation step. Don’t rely on the model remembering a sentence. The rule of thumb: if it applies to almost every task, make it persistent. If it applies to certain files, scope it. If it applies to one task, keep it in the prompt. How are you organizing project instructions as your codebase grows: one CLAUDE.md , path-specific rules, or a mix? submitted by /u/Wise_Choice7014
Originally posted by u/Wise_Choice7014 on r/ClaudeCode
You must log in or # to comment.