This is so interesting. As an Obsidian user I tried to retrain my brain into a no folder structure and just tag everything. It didn't stick. Now with Cowork a folder/project structure is imperative!
So glad you wrote about this topic. You need structure and organization to get real results out of Claude.
I use a different approach where the workspace = cowork project and that’s the full context for the session, e.g. sales, mktg, accounting, etc.
I think both approaches work, I just need to scale more while keeping structure.
We should connect and share our approach one if those days.
Ps: I defined naming conventions and workspaces structure in system md files so it can be enforced -I actually have a skill that audits everywhere for compliance and fixes on the fly 😉
Hi Frank, How do you suggest implementing this structure in a situation where you advise multiple clients? Do you have a separate Workspace for each client or do you have one Workspace with seperate Projects folders for each client? Note that the underlying assumption is that I am providing similar outcomes for each client. Cheers
I love this, maybe as I do something similar for initial files, although with alteration to the numbering. I like to do mine in groups of "10", add refs to the project name, the file, and the "version" using major/minor where major = session and minor = successive save. L00 is my most stable element, so:
00 Branding Project Bible S16_03.md = the project bible for the branding project, session 16, save 3 of the session.
It's the most important and stable of all project docs, so it is my first doc always. Sometimes I'll add 05 Naming conventions if the project has more than those five folders.
L10 is for my next most stable element, often info about stages in simple projects, also split a little apart (10, 12, 14...) so that I can always add something in between if needed. In my largest project, L10 is my inventory of everything else.
Starting at L20, I go up in groups of 5 for "streams of work". In a branding project, I have 20 being the creation of certain types of assets (avatars for instance), and 25 is some character descriptions, while 30 is a different type of product entirely, etc. Within each set of 5, I have sub files at say 31, 32, 33. All of them have "handovers" for the stream.
In a simpler project, L20 is the main product outcomes, and L30 becomes status stuff -- handovers / state from session to session, work logs and/or queues from session to session, etc.
It sounds like a lot, but I can keep it easily to 4-5 files for each "normal" sized project each time, and there's no risk of naming collision if I ever copy a file somewhere to build in a new project. My biggest project (branding) has 11 sub-streams of work, everything sits in the root directory as 32 files, and Claude (and I!!!) can find all of them easily. A little anal over several subfolders, but any cruft is just named normally with letters that sort at the bottom. I also like to use level 99 for archives, but also 80+ for the equivalents of side-quests.
I'd come across something like this called the Interpretive Context Model a few months ago. Great concept and love to see different versions: https://arxiv.org/abs/2603.16021
Folder systems work because Claude reads structure before it reads intent. A well-named directory is cheap prompt engineering: it tells the model what matters without spending a single token explaining it.
I kinda stumbled into this same realization. The folder structure helps but the thing that actually made a difference for me was having Claude maintain a running project log in the folder — just a markdown file where it notes what it did last session. Saves me from re-explaining context every time.
I do something similar but per-project, one folder with a http://CLAUDE.md that just points to the other files instead of dumping everything into context. Cuts down on Claude re-reading stuff it doesn’t need for the task at hand.
This is so interesting. As an Obsidian user I tried to retrain my brain into a no folder structure and just tag everything. It didn't stick. Now with Cowork a folder/project structure is imperative!
BRAVO! An affirming and relevant post indeed. Logical, methodical, effective, and efficient framework, indeed!! Thank you.
So glad you wrote about this topic. You need structure and organization to get real results out of Claude.
I use a different approach where the workspace = cowork project and that’s the full context for the session, e.g. sales, mktg, accounting, etc.
I think both approaches work, I just need to scale more while keeping structure.
We should connect and share our approach one if those days.
Ps: I defined naming conventions and workspaces structure in system md files so it can be enforced -I actually have a skill that audits everywhere for compliance and fixes on the fly 😉
How do i implement this into my Claude projects, I saw the other post on https://artificialcorner.com/p/cowork-setup?utm_source=substack&utm_medium=email
But I dont see instructions on how to set this up?
I would appricate if you can let me know how, like what prompts/commands to use and so on
Hi Frank, How do you suggest implementing this structure in a situation where you advise multiple clients? Do you have a separate Workspace for each client or do you have one Workspace with seperate Projects folders for each client? Note that the underlying assumption is that I am providing similar outcomes for each client. Cheers
A solid folder system for Claude is such an underrated productivity hack. Organization really changes how well AI works.
Is this approach applicable to other AI platforms? i.e. ChatGPT, Grok, etc.
No matter what I do my Claude ends up messy 🤣
Such a practical tip, keeping Claude organized with a clear folder system saves so much time in the long run.
I love this, maybe as I do something similar for initial files, although with alteration to the numbering. I like to do mine in groups of "10", add refs to the project name, the file, and the "version" using major/minor where major = session and minor = successive save. L00 is my most stable element, so:
00 Branding Project Bible S16_03.md = the project bible for the branding project, session 16, save 3 of the session.
It's the most important and stable of all project docs, so it is my first doc always. Sometimes I'll add 05 Naming conventions if the project has more than those five folders.
L10 is for my next most stable element, often info about stages in simple projects, also split a little apart (10, 12, 14...) so that I can always add something in between if needed. In my largest project, L10 is my inventory of everything else.
Starting at L20, I go up in groups of 5 for "streams of work". In a branding project, I have 20 being the creation of certain types of assets (avatars for instance), and 25 is some character descriptions, while 30 is a different type of product entirely, etc. Within each set of 5, I have sub files at say 31, 32, 33. All of them have "handovers" for the stream.
In a simpler project, L20 is the main product outcomes, and L30 becomes status stuff -- handovers / state from session to session, work logs and/or queues from session to session, etc.
It sounds like a lot, but I can keep it easily to 4-5 files for each "normal" sized project each time, and there's no risk of naming collision if I ever copy a file somewhere to build in a new project. My biggest project (branding) has 11 sub-streams of work, everything sits in the root directory as 32 files, and Claude (and I!!!) can find all of them easily. A little anal over several subfolders, but any cruft is just named normally with letters that sort at the bottom. I also like to use level 99 for archives, but also 80+ for the equivalents of side-quests.
I'd come across something like this called the Interpretive Context Model a few months ago. Great concept and love to see different versions: https://arxiv.org/abs/2603.16021
This is good stuff! I'm glad I came across this post because this is exactly what I'm dealing with right now.
Folder systems work because Claude reads structure before it reads intent. A well-named directory is cheap prompt engineering: it tells the model what matters without spending a single token explaining it.
I kinda stumbled into this same realization. The folder structure helps but the thing that actually made a difference for me was having Claude maintain a running project log in the folder — just a markdown file where it notes what it did last session. Saves me from re-explaining context every time.
This info is amazing. THANK YOU for giving it to us.
I do something similar but per-project, one folder with a http://CLAUDE.md that just points to the other files instead of dumping everything into context. Cuts down on Claude re-reading stuff it doesn’t need for the task at hand.