How to Split One CLAUDE.md Into Separate Workstations
At some point, one CLAUDE.md file stops being able to hold everything. It’s got “reply in the same thread as the last email” sitting a few lines above “always build a branding card for every blog post,” and neither rule is wrong; they just have nothing to do with each other. Once you’re using Claude for more than one kind of work, and most people end up doing that fast, the fix isn’t a smarter file. It’s more files, each one scoped to a job. Here’s how to actually build that.
What a workstation is
A workstation is just a subfolder with three things inside it: a CLAUDE.md, a MEMORY.md, and an empty resources folder for whatever reference material that job needs. AI Blog Posts is one workstation on this setup. Email HQ is another. Each one only holds the rules and history for its own job, so the email rules never get a vote on how a blog post gets written, and vice versa.
The four sections every workstation CLAUDE.md needs
Build it in this order:
Identity. One paragraph saying who Claude is in this workstation, what kind of request routes here, and what doesn’t. This is the part that keeps a workstation from creeping into jobs it wasn’t built for.
Resources. A table of reference files and when to read them. The blog workstation has one row: read voice-principles.md before writing anything. As the workstation grows, more rows get added, but it starts empty and fills in as you actually need files.
Workflow. Numbered steps for the primary task this workstation handles. Keep it simple at first. You’ll refine the steps once you’ve watched it run a few times and noticed where it guesses wrong.
Editorial rules. This section always opens the same way: a line pointing back to the shared voice-principles file, so every workstation writes in the same voice before anything domain-specific gets layered on. After that opening line, add the rules that only apply here, like the blog’s “avoid AI-detector flags” rule or email’s “match the formality of the message you’re replying to.”
What goes in the workstation’s MEMORY.md
Two sections: Contacts, for the people relevant to that specific domain, and Key Decisions, for the reasoning behind choices made along the way. You don’t write this file by hand. Claude populates it as you work, the same way it would update any other memory file, just scoped to this one folder instead of your whole life.
The routing map is what makes it automatic
None of this helps if you have to remember which folder to point Claude at every time you ask for something. That’s the job of the routing map, a short table that lives in your root CLAUDE.md with two columns: the workstation name, and the condition that sends a request there. Something like “route to AI Blog Posts when I want to brainstorm, draft, or edit posts for the blog.” Ask for a post idea and that row fires. Ask for a client reply and a different row fires instead, pulling in Email HQ’s rules along with it. Adding a new workstation later is just adding a row.
Building one yourself
- Make the subfolder, named for the workstation.
- Add the CLAUDE.md with the four sections above, in that order.
- Add the MEMORY.md with the Contacts and Key Decisions headers, left empty to start.
- Add the empty resources folder.
- Add one row to the routing map in your root CLAUDE.md so future requests find their way here without you having to say the folder name out loud.
That’s the whole setup. The workflow and editorial rules stay thin at first and get more specific the more you actually use the workstation.
Why this beats one giant file
The payoff isn’t tidiness for its own sake. It’s that a rule built for one job literally cannot fire in another, because Claude is only loading the rulebook for the workstation the routing map pointed it to. The blog’s “no bullet points in this style of post” rule can’t accidentally suppress a bulleted list an email actually needs. You’re not asking Claude to weigh every rule you’ve ever written against every task in front of it. You’re handing it the one rulebook that applies, and leaving the rest closed.
