Your CLAUDE.md works for one project. What about the other nine?

A CLAUDE.md per project works. It works right up until you have five projects, then ten, and the same paragraph about how you want commits written, which registrar owns which domain, and which two services talk to each other is sitting in five or ten files, slowly drifting out of sync with itself.

That is the exact wall a developer hit on r/ClaudeAI, moving off ChatGPT after years of accumulated context across "55 interconnected codebases." The mega-prompt approach breaks the moment you switch projects, because Claude is still holding conventions from the last one. The thread's answers converged on the same fix from a dozen different angles: stop trying to fit everything in one file, and stop copying the same file everywhere.

The two layers

Per-project. A small CLAUDE.md in the repo: stack, naming, deploy commands, the gotchas that would otherwise cost someone an afternoon. This is the schema the Karpathy LLM wiki pattern already gives you: short, specific to this codebase, ignored past a screen or two if you let it grow.

Cross-project. Your preferences. Infrastructure and the domains and services you run. Which projects share a database, an API, or a design system. Decisions you already made and the reasoning behind them, so you don't relitigate them in project six. None of this is one project's business, and none of it belongs duplicated into every CLAUDE.md you own.

The two layers fail differently when you mix them up. Cram everything into one repo's CLAUDE.md and the other nine repos never see it. Copy it into all ten and you are now maintaining ten copies by hand, and the first time you update one and forget the rest, an agent in project seven is working off stale rules.

Where the cross-project layer actually lives

Not in a repo. Whichever repo you pick becomes the canonical one by accident, and every other project either misses updates or you're back to copying by hand.

Claude Code gives you two steps out of the repo before you need anything else, and you should take both before reaching for a tool.

~/.claude/CLAUDE.md is user-level memory: it loads in every project on that machine. That is the right home for the small, stable half of your shared layer, the preferences that fit in a screen and are true everywhere.

~/.claude/rules/ is the second step, and it's the one people miss. Personal rules there apply to every project too, and a rule file carrying a paths: frontmatter block only loads when Claude works with files that match. So the obvious objection, that a global file grown to cover ten projects is paying for all ten on every session, has a native answer: scope each rule to the code it concerns and it stays out of the way otherwise. Note that splitting a big file into @path imports does not do this. Imports load at launch just like the file that references them.

Take both steps and you have covered more ground than most write-ups admit. Where they run out is specific, and worth being precise about, because it is the only part something else actually earns:

Knowledge no file path implies. Path scoping triggers on the code Claude reads. Which registrar owns which domain, why you dropped a payment provider two years ago, what a client agreed to on a call: none of that has a glob that matches it, so it loads always or never.

A second machine. Both files live on the machine you wrote them on. A work desktop, a laptop, a cloud session all start empty.

A second assistant. These are Claude Code files. The Claude app doesn't read them, ChatGPT doesn't either, and a lot of this is the same context you'd want in both.

Anything you want written back. You maintain rules by hand. If the useful part of a session should land somewhere without you transcribing it, the store has to be writable.

A knowledge base connected over MCP covers those four, and that is the honest case for it. Your infrastructure note, your standing decisions, your client facts live there once, searchable by topic rather than by file path, and Claude Code in any of your ten repos can read the current version rather than a snapshot from whenever you last copied it. It's also why a shared CLAUDE.md checked into a monorepo isn't the answer: that still lives inside one place you have to be working in.

Two caveats worth knowing up front. A local file is loaded for you, and a knowledge base is fetched on request, which means the model decides when to go and look. That is what the router below is for. And an MCP server is added to the current project by default, so use claude mcp add --scope user if you want it available across every project on the machine.

The router pattern

A pile of context files is only useful if Claude knows which one to open. The pattern that keeps coming up, independently, from people who tried the naive version and fixed it: a short table, sitting at the top of your global instructions, mapping the kind of task to the file that answers it.

When the task involves...        → read this first
Infrastructure, DNS, deploys      → Infra notes
A specific client or project      → that project's note
Coding conventions, commit style  → Preferences note
Decisions already made            → Decision log for that area

Skip the router and an agent either loads everything (expensive, and mostly irrelevant to today's task) or loads nothing (and asks you the same questions again). The router costs one short table and saves both.

Be clear about what it is, though. Nothing in a CLAUDE.md is enforced routing. It is context the model reads and usually acts on, which in practice means most of the time rather than every time. So phrase the entries as instructions rather than trivia, keep the table short enough that it doesn't get skimmed, and say plainly when something is non-negotiable.

If you are hosting the cross-project layer in a knowledge base rather than flat files, the router pattern still applies, it just becomes folders and per-folder instructions instead of a manually maintained index: point Claude at the right folder, and it can pull what's there without you re-explaining the map every session. The daily Claude Code loop covers what that looks like in practice.

Keep preferences and project facts in separate files

This is the split people get wrong most often, because it is tempting to write it all in one note about "how I work."

Preferences barely change. How you want commits written, how you like PRs described, how blunt you want an agent to be when it disagrees with you. Write it once, it is still true in a year.

Project facts decay in weeks. Which stack a project runs, what's deployed where, who owns which service. Mix the two in one file and the first stale fact makes you distrust the whole document, preferences included, even though those are still accurate.

Two files, updated on two different schedules, solves it. The preferences file barely gets touched. The project-facts files get touched constantly, and staleness in one of them doesn't poison the other.

Migrating without dragging years of noise along

If you're moving from ChatGPT specifically, per that same thread, the instinct to skip is exporting the chat history. Years of conversations are mostly noise: the useful fraction is small enough to write by hand once you find it.

The tactic that actually surfaces that fraction: ask the old assistant to list the standing rules it has been following, and why, for each project. The "why" is what matters. Look at your own reasons and you'll find some of them were one-off fixes from a bad afternoon that quietly became permanent rules you'd never have chosen deliberately. A rough filter: keep it only if you'd correct it a second time. Most of what's left fits in a few hundred lines, not a few hundred conversations.

Switching assistants is its own cost beyond just the context migration, chat history, built-in memory, and Projects all stay behind by design. The same fix applies to both problems: put the durable stuff somewhere the assistant reads from, instead of somewhere it lives.

This is what Hjarni is for

Hjarni is a knowledge base with a built-in MCP server. Your cross-project layer, preferences, infrastructure, decisions, goes here once, in folders with their own instructions, instead of copied into every repo's CLAUDE.md. Claude Code in any project can search and read it, and so can the Claude app and ChatGPT, if that's where some of this context is coming from. Add it with --scope user once and every project on that machine points at the same copy.

You're already doing the hard part when you write good per-repo CLAUDE.md files. This is just moving everything that shouldn't be per-repo out of the ten places it's currently duplicated, into the one place it actually belongs.

Give your projects one shared brain. Connect Claude Code in five minutes, and set up session capture so the useful parts of each session land there without you asking. See the full Claude Code setup for the rest.

Curious why this works at all instead of just cramming more into one prompt? Context engineering isn't just for AI teams, it's the same problem, at your scale, with your notes.