Open Claude Code One Level Up

Every AI coding tool makes the same assumption: the unit of work is a repository. You open the agent inside a repo, it reads that repo, it edits that repo. Clean model. Wrong model.

Look at actual work. At one company I know well, the backend is around twelve microservices, each in its own repo. At my current job, every feature touches at least two repos: a service and a front. The issue tracker doesn't care about repo boundaries. "Add the endpoint, then consume it" is one task to a human and two unrelated worlds to an agent that lives inside a single repo.

For months my answer was the obvious bad one: open a session in repo A, explain the context, do half the work, open a session in repo B, explain everything again, do the other half, and personally carry the state between them like a courier. The human becomes the integration layer. That's backwards.

Seba's move

The fix wasn't my idea. A coworker, Seba, did something simple that I haven't stopped thinking about since: he stopped opening Claude Code inside the repos.

He made a plain folder. Not a git repo, just a directory. Inside it, he cloned the microservices, all of them, side by side. Then he opened Claude Code in the parent folder and asked for implementations from up there. The agent could see every repo at once. Ask it how a change in the billing service affects the notification service and it reads both, because both are right there. No more interrogating repos one at a time and joining the dots by hand.

That single move (open the session one level up) turned out to be the whole trick. Everything else is furniture.

What I added: the furniture

A session that can see twelve repos still forgets everything when it ends. So I started adding state to the parent folder, the way you'd furnish an empty room:

The rule that makes it work: state lives at the level that owns it.

If you're thinking "isn't that a monorepo?", no. A monorepo is one repository with shared build tooling. A meta-repo wires child repos together with submodules or manifest files. Both couple the repos to the structure. The workspace layer couples nothing. The child repos are untouched and don't know the layer exists. There's no workspace build, no lockfile, no tooling. The layer holds memory; the repos keep the code.

Which is also why adopting it costs nothing: mkdir, clone your repos into it, open Claude Code in the parent. If it doesn't help, delete four markdown files and you're back where you started.

The toolkit detects the terrain on its own

This part matters because nobody wants to configure modes by hand. When my toolkit's onboarding runs, the first thing it does is figure out what kind of ground it's standing on:

Three modes, zero flags:

Workspace mode. No .git at this level but two or more child directories are git repos: this is a workspace folder, not a codebase. Instead of dying with "not a git repo" (what most tooling does), it builds the root INDEX.md (repo, what it is, stack, last activity) and offers full per-repo onboarding packages on demand.

Team repo mode. The repo commits its own CLAUDE.md or .claude/ content: someone else owns the tooling here, and my onboarding notes are personal, not team deliverables. Every artifact silently switches to its *.local.md variant, and they get excluded through .git/info/exclude instead of .gitignore. That distinction is small and load-bearing: .gitignore is a committed, shared file, so editing it would put MY tooling in THEIR diff, which is exactly what this mode exists to avoid. .git/info/exclude does the same job and never leaves my machine. My teammates have no idea any of this exists, which is the point.

Classic mode. A normal repo I own: artifacts get committed normally and become part of the project's own memory.

There's one more piece of automated etiquette. On the very first onboard of any repo, the toolkit asks a single question: should commits here carry the Co-Authored-By: Claude trailer? Some repos want transparent AI attribution in the history (my public toolkit does); some teams want a clean log, or haven't decided a policy. The answer gets recorded once in the conventions file under a GIT ETIQUETTE section, the commit skill reads it from there forever, and the question never comes back. And if the repo's own CLAUDE.md already legislates attribution, the toolkit doesn't even ask: the repo's law wins over my recorded preference.

A cross-repo day

Here's what a normal task looks like now. An issue comes in on the tracker. The agent has credentials to read it directly, so I don't paste anything: I give it the issue number and it pulls the description itself. Most of our issues touch the service and the front, and because the session sits above both repos, it maps the change across them in one pass: this endpoint here, this consumer there.

Then it explains the plan before implementing. I ask my questions, correct what it misread, and only after that does code get written.

The detail I didn't expect to enjoy: the team's repo has its own CLAUDE.md, written by people who are not me, and it says humans commit by hand, the agent doesn't. My personal layer has opinions about commits too. The layers don't fight. The repo's rules win inside the repo, my workspace rules apply everywhere else, and the agent respects both without being reminded. Before anything gets pushed it reviews its own diff and fixes what it finds, which is a sentence I would not have believed two years ago.

Coming back after days

The real test of any memory system is abandonment. Leave a workspace for a week, come back cold, and see what survives.

What survives is everything. The todos file has the running record of which issues we've done and which are open. DECISIONS.md has what we chose and why, including the approaches that didn't work, which is the half people never write down. STATUS.md says where we stopped. I open the session and ask "where are we?" and it answers, correctly, from files, not from vibes. If main moved while I was away, it pulls, updates the state everywhere, and we continue.

The closest analogy I have: it's like working with an assistant who kept perfect minutes of every meeting you've ever had, and never gets tired of you asking what happened last Tuesday.

The part I didn't see coming

Here's the strange one. I maintain a toolkit of sixteen skills for Claude Code, things like spec-first task intake, hypothesis-first debugging, reviewed commits. I built them as slash commands you invoke by name.

I don't invoke them anymore. Any of them. Claude reads each skill's one-line description at session start and activates the right one from my natural language. I say "there's a bug in the sync" and the debugging discipline kicks in on its own, hypothesis first, no command typed. I spent weeks building sixteen commands and now I type zero of them. I automated myself out of my own toolkit, which I'm told is what success looks like.

The lesson under the joke is real, though: commands are a transition phase. You write them to make a discipline explicit. Once the descriptions are good enough for the agent to self-select, the discipline becomes ambient and the names stop mattering. The methodology outlives the interface.

What's still broken

Cost. A session that sits above twelve repos and keeps rich state is a session that eats tokens, and if you prefer the most capable model for analysis (I do), you feel it in the bill.

What I actually want is routing: the expensive model for the architectural reasoning, cheaper models for the mechanical middle, without me micromanaging the choice. Eval-driven model routing exists as a product category for production API workloads, but nothing yet does this well for interactive agent sessions. It's the obvious next layer, and someone is going to build it. Until then my mitigation is unglamorous: keep the state files small and let indexes stand in for re-reading repos.

Try it

The shape is free and vendor-neutral: a folder, your repos inside it, four markdown files at the root, and the discipline of opening the session at the top. Any agent that reads files can use it.

If you want the version with the furniture pre-built (the three-mode terrain detection, the cross-repo task list, the hook that tells you where you left off the moment the session opens), my toolkit is public:

/plugin marketplace add mauroepce/claude-workspace
/plugin install claude-workspace@mauroepce

The full write-up of the layer is in the repo's FRAMEWORK.md.

Credit

The original move (sessions above the repos, not inside them) belongs to Seba, who saw the microservices problem clearly before I did. My contribution is the state layer on top, the automated terrain detection, and writing it down. Most good workflow ideas start as something a coworker does casually while you take notes.

---

Feedback welcome via GitHub issues or LinkedIn.