One Project Per Outcome, Not One Giant Catch-All
What it is
An organising rule: create a separate Project per distinct outcome or client, rather than dumping everything into one catch-all Project whose mixed context dilutes every answer.
Why it works
A Project's power is its shared context — but that only helps if the context is coherent. Pile unrelated work into one Project and the files, instructions, and history pull answers in conflicting directions. Splitting by outcome keeps each Project's context tight, so the model draws only on what's relevant to the task in front of it.
When to use it
As soon as you notice a Project spanning genuinely different bodies of work, or answers in it getting vaguer as unrelated material accumulates.
When not to use it
Closely related workstreams that share the same files and rules — over-splitting those just fragments context that belonged together.
Prompt
I currently keep <describe what's in the Project>. Should this be one Project or several? Split by distinct outcome or client, and tell me which files and instructions go with each.Example
Breaking a bloated 'Work' Project into 'Client A', 'Client B', and 'Internal Docs' makes each thread pull only its own guidelines instead of a blur of all three.
Common mistakes
- Running every project through one 'everything' Project.
- Splitting so finely that related work loses its shared context.
- Leaving stale files from an old effort in an active Project.