AI Guides › Claude Mastery
Projects vs Plain Chats: A Decision Rule, Not A Preference
By Nigel Guy · 2 min read
Ask people why they use a Project instead of a plain chat, or vice versa, and most answers are aesthetic — "I like keeping things organised" or "I never got round to setting one up." That's a preference, not a decision, and it means the choice gets made the same way every time regardless of what the actual work needs. Some work genuinely needs a Project. Most doesn't. Guessing wrong in either direction has a real cost: unnecessary setup on one side, constant re-explaining on the other.
The rule: the decision isn't taste, it's a single test — will you come back to this same context three or more times? If yes, build a Project; if no, a plain chat is not the lesser option, it's the correct one.
The mechanism: the three-return test
- Count the expected returns, not the current ones. If you're fairly sure you'll be back with a related question inside the same context at least three times, that's the Project threshold. Once or twice doesn't clear it.
- Check whether the context is genuinely stable. A Project only pays off if what you'd put in it — style guide, brief, reference documents — stays true for those future visits. If the underlying facts will have changed by visit two, a Project just gives you stale material with more confidence attached.
- Check who else needs the same context. If a colleague will ask overlapping questions against the same material, a shared Project removes duplicated setup for both of you. A private one-off doesn't have that multiplier.
- If the test fails on any count, use a plain chat and move on. Don't build a Project "just in case" — an empty or half-filled Project you never return to is worse than no Project, because it's one more place stale information can quietly live.
What to skip
Skip trying to convert every chat that goes well into a Project after the fact — most good conversations were good because the question was well-formed, not because they were missing infrastructure. And skip the instinct to build a Project as a first step on a new piece of work before you know whether it'll actually recur; set it up once the third return is a real prospect, not a hope.
Guardrails
- This test is about your own working pattern, not a fixed rule about topics. The same kind of task can pass the test for one person and fail it for another, depending on how often each of you actually returns to it.
- A Project reduces re-explaining; it doesn't improve the quality of any single answer inside it. Don't expect a Project to compensate for a vague question — see "Vague Requests, Vague Answers" for that separate problem.
- Exactly what Projects can hold and how they're shared is a product detail that moves — check current documentation for size limits, supported file types, and sharing permissions before committing a team's shared context to one.
All 751 AI guides · JulieMango plans from £17/mo