Using Claude Code in a Large Monorepo: Practical Questions About Structure, Discoverability & Workflow

Hey Guys!

I’m a software engineer working in a large enterprise monorepo with a diverse stack: .NET (legacy and modern), multiple Vue.js front-end apps, a custom E2E testing framework, and a lot of ASP.NET code. Our team has historically been split between front-end and back-end devs.

So far, we’ve been using Claude Code mainly on the front end, where we have some, commands, and sub-agents configured. We also have a few CLAUDE.md files scattered in places like the Database/ and API/ folders, but nothing consistent or centralized yet.

We’re now starting to explore Claude for back-end development too, and we want to professionalize our setup across the entire monorepo. We're experimenting with spec-driven development and trying to get the most out of Claude’s agentic features—but we have some practical questions:

Where should CLAUDE.md files live—monorepo root, per app, per package?

How should .claude/ directories be structured when working across multiple apps and shared libraries?

Should developers always open Claude from the root of the repo, or are there smarter ways to organize entry points?

How are you making Claude-related files (rules, commands, specs) more discoverable for human developers?

Any tips for managing full-stack feature work that spans front-end and back-end?

How are you using Claude to modernize legacy code or shift toward more full-stack collaboration?

We’re at the stage of turning a promising experiment into a solid, maintainable setup—and would love to hear how others are doing this at scale.

Thanks in advance!

1 comment

AI Developer Accelerator

skool.com/ai-developer-accelerator

Master AI & software development to build apps and unlock new income streams. Transform ideas into profits. 💡➕🤖➕👨‍💻🟰💰

Leaderboard (30-day)

+54

+30

+20

+14

+12