One Project per Context, Not One for Everything

Organising Claude Projects around distinct bodies of work — one per client, product, course, or ongoing topic — so each project's knowledge and custom instructions describe exactly that context, rather than piling everything into one general-purpose project.

A project's power is that its knowledge and instructions apply to every chat inside it. That's an asset when the context is coherent and a liability when it isn't: mix three clients' documents and conflicting style rules in one project, and Claude reaches for the wrong reference or applies the wrong voice. Splitting by context keeps each project's knowledge relevant to every conversation it holds, and lets the instructions be specific ('this client prefers British English, formal tone') instead of watered down to cover everyone. Clean boundaries mean every chat starts from context that actually fits.

As soon as you're doing more than one distinct kind of ongoing work in Claude: multiple clients, several products, separate research threads, work versus personal. The moment you'd have to write 'for Client A, do X; for Client B, do Y' in shared instructions, split them.

If all your work genuinely shares one context and one set of conventions, a single project is simpler — don't fragment for its own sake. And don't spin up a project for a one-off chat that needs no standing context.

I do these distinct kinds of ongoing work in Claude: <list them>. Help me decide how to split these into projects: which deserve their own project, which can share one, and for each project, what knowledge and custom instructions belong in it so every chat inside starts from the right context.

A freelancer had one 'Work' project holding three clients' brand guides and a tangle of contradictory instructions. Claude kept blending voices. Splitting into a project per client — each with only that client's guide and tone rules — meant every chat opened in the right voice with the right references, and the instructions could finally be specific instead of hedged.

Give each project a short 'what this project is and isn't' line at the top of its instructions, so both you and Claude stay inside its boundaries. When two projects start needing to reference each other constantly, that's a signal the split was drawn in the wrong place — reconsider the boundary rather than duplicating shared material into both.

• Dumping every client and topic into one project, then wondering why Claude cites the wrong document.
• Writing conditional instructions ('if it's for X…') inside a shared project instead of splitting into separate ones.
• Over-splitting into dozens of thin projects, so standing context is scattered and nothing has enough to be useful.