How I Run a 15-Repo Studio From One CLAUDE.md File
RAXXO Studios is one person. Me. But it runs 15 public repos, a Shopify store, a blog with 167 articles, multiple syndication platforms, and a slash-command library with 18 custom commands. The thing that makes this manageable is not a project management tool or a Notion doc. It is one CLAUDE.md file at the root of my workspace that tells Claude Code everything it needs to know about how I work, what I ship, and what the rules are.
This is the setup that turned my AI assistant from a clever autocomplete into something that actually remembers how I run the studio. Here is how the file is structured, what I put in it, and the memory system underneath that keeps it sharp over time.
Why One File Beats Many
I started with CLAUDE.md files per project. Every repo had its own context, its own rules, its own mini-index. Six months in, I had 15 slightly-different CLAUDE.md files, all drifting apart.
The brand section in raxxo-shop said "primary color is lime". The brand section in raxxo-studio said "primary color is #e3fc02". Both correct. But when I changed the hex a month later, only one got updated. Next session, Claude used the stale color in a new landing page. I caught it in code review, but I had written the config with my own hands and still got it wrong.
The fix was a single CLAUDE.md at the workspace root. One source of truth for everything that applies across every project: brand, voice, folder structure, decision framework, tooling index. Per-repo CLAUDE.md files only exist when a repo genuinely has something different, like a specific deployment target or an unusual stack. Most of my repos do not have their own CLAUDE.md at all. They inherit everything from the workspace root.
The test I use to decide where a rule goes: "Is this true for every single repo I maintain?" If yes, it goes in the root. If it is specific to one repo, it goes there. If it is specific to two or three repos, it goes in all of them with a note that explains the scope.
The Seven Sections of My Root CLAUDE.md
My root CLAUDE.md is just under 200 lines of dense markdown. It has seven sections, in this order.
Who I am. One paragraph with a short bio: my role, tenure, and what RAXXO Studios is. Separately notes that there is a day job that lives in a completely different workspace. This section is 4 sentences and it shapes every decision Claude makes about tone and scope. Workspace layout. A tree of my main folders with one-line descriptions. RAXXOSTUDIOS/ for the 15 public projects. REMINDME/ for company work (local-only, never pushed). _local-assets/ for large media. Pointer to a memory file for the full routing guide. Strict separation rules. The rules that prevent cross-contamination between RAXXO and my other workspace. Different GitHub accounts, different emails, different gitconfig identities. RAXXO content never gets published during weekday work hours. This is the section I added after I almost accidentally pushed an internal tool from the wrong workspace to a public RAXXO repo. Non-negotiable rules. 13 one-line rules. No em dashes. No Pixar references. Currency is 5€ not €5. Every commit message is documentation. Never put credentials in settings.json. This list grows by about one line a month. Each rule is there because I made the exact mistake that rule prevents. Brand visual system. Four lines of quick reference (background color, text color, accent, font), then a pointer to the full brand book and the enforcement hook that blocks commits with bad colors. The full specs live elsewhere because keeping them in CLAUDE.md would bloat the file. Decision framework. A table that maps task types to tools. "Blog post" maps to the /publish chain. "PR review" maps to the pr-review-toolkit plugin. "Deploy" maps to /deploy. This table is the thing I reference most. When I say "write me a blog post" Claude does not have to guess which skill to invoke. The table tells it. Tools summary. Counts of skills, commands, plugins, MCP servers, and hooks, with pointers to the interactive pulse dashboard for the full index. This section is mostly for me, to see at a glance how much infrastructure I have accumulated. It also tells Claude which capabilities are available.The thing I want to underline is that none of this is project-specific. All seven sections apply to every repo I touch. That is why it works as a single file.
The Memory System Underneath
CLAUDE.md holds the rules and the index. The memory system holds the details.
My memory folder has 70 files. Each one is one topic, frontmatter-tagged with a name, description, and type. The types are user, feedback, project, and reference. Claude auto-loads an index (MEMORY.md) at the start of every session and pulls individual memory files when they become relevant.
Examples of what lives in memory.
- `reference_blog_registry.md` has the full list of published articles with topic clusters and affiliate status. When I start a new blog post, Claude checks this file to avoid duplicate topics.
- `feedback_no_stale_numbers_in_assets.md` is the rule that says "no exact article counts in public-facing assets, use 100+ ranges". It was added after I spent an afternoon updating "160 articles" to "163 articles" across 8 different files.
- `reference_brand.md` has the full brand token reference. Colors, fonts, spacing, glass effects. The root CLAUDE.md has the summary. The memory file has the details.
The division of labor between CLAUDE.md and memory is deliberate. CLAUDE.md is the hot context loaded every single session and costs tokens every time. Memory files are loaded only when relevant, based on the MEMORY.md index and the description field of each memory. This keeps the base context lean while giving Claude access to deep detail when a task needs it.
The memory system also stores lessons from mistakes. Every time I correct Claude on something that should be persistent, the correction becomes a memory file. "Never run vercel env pull raw, always use safe-env-pull.sh." That rule is one memory file now. The next time a session starts and I ask about Vercel environment variables, Claude already knows the rule.
How Per-Repo CLAUDE.md Files Actually Help
About five of my 15 repos have their own CLAUDE.md in addition to the workspace root. These are the ones that need truly repo-specific context.
`raxxo-shop/CLAUDE.md` has the Shopify theme ID, the API credentials location, the blog publish flow, and a pointer to the scripts folder. All Shopify-specific. None of this applies to any other repo.
`raxxo-studio/CLAUDE.md` has the Next.js version, the Vercel deployment config, and a note about the two environments (dev and prod). Pure web-app context.
`raxxo-brand/CLAUDE.md` is almost empty. It just says "this repo is the source of truth for brand tokens, see brand-book.md for the full spec". Most of the relevant context is in the brand-book itself.
The rest of my repos have no CLAUDE.md at all. They inherit everything from the workspace root, which is enough for most tasks. If I start needing repo-specific context, I add a CLAUDE.md at that point, not before.
Adding CLAUDE.md files speculatively is a trap. You end up with boilerplate that repeats what is already in the root, which creates the drift problem I started with. Only add a per-repo file when there is something genuinely different to say.
The Payoff in Time Saved
I measured this once. Sessions where I start from a fresh conversation used to take me about 15 minutes of re-briefing before Claude was actually useful. "RAXXO is my studio, the brand is lime and dark, I need blog posts for this topic, here are the style rules, here are the files to avoid..." Every single time.
With CLAUDE.md loaded, zero minutes of briefing. I say "write me a blog post about X" and Claude already knows the voice, the target audience, the affiliate rules, the TLDR format, the publish pipeline, and the places that content cannot use em dashes. I say "deploy to prod" and Claude knows I use /deploy, which uses Vercel, which needs dev first.
Across roughly 200 deep sessions a year, that is 50 hours of re-briefing I do not have to do. Call it a week of full-time work, recovered by writing one markdown file and keeping it current.
The second-order benefit is consistency. When every session starts from the same context, every output has the same voice. My blog posts sound like they are written by the same person because Claude is reading the same style rules every time. Before CLAUDE.md, the voice drifted depending on my mood when I was briefing the session.
Bottom Line
One CLAUDE.md at the workspace root, pointing to a memory system with 70 topic files, is the setup that makes a one-person studio feel like it has structure. It is not a framework, it is not a tool, it is just a markdown file and the discipline to keep it current.
If you work with AI on anything more complex than one project, try the single-root-file approach this week. Put your rules, your brand, your decision framework, and your tooling index in one place. Link out to memory files for the deep details. Delete any per-project CLAUDE.md files that are mostly repeating what the root already says.
The file is not the magic. The magic is never having to explain yourself twice.
Back to all articles
