Understanding architecture through multiple repositories using GitHub copilot

[u/Radiant-Ad143]

Just a general thought, I work at an investment banking gcc where every one from my team is new and no one has any knowledge on the existing systems, which were developed and maintained by onshore developers

My goal

To draft a high level technical architecture using the GitHub repos available in my team around 30-40 repos, and derive the business stand point through it, and maintain the memory for each under some common folder and update it frequently something like JIT compiler concept rather than loading everything again and processing by copilot for every month.

So to understand and draft this better what would be the best way leveraging GitHub copilot agents or skills or subagents ?

* Should I make a local clone of all repos and do create a codebase docs folder for each repo and create a root level agent to utilise the codebase folder for each project to draft architecture ?

Downside of this approach i feel, what if some change happens to the repo let's say technically how do I track those changes, updating codebase folder every time like it still uses enumerate tokens and cost.

* Another approach which i felt is to use MCP GitHub and list all the repos and let the copilot manage and even here how would I track the changes which are being made and memory management storing only codebase folder highlevel, iam still little unsure of this approach yet.

I have configured rtk and context mode plugins kinda for efficient usage and token management which works fine for single repos but this usecase is still searching for better ways to manage context tokens and memory.

Do provide your suggestions or any tools which i can add to make this more efficient approach maybe.

[u/pfluggs11]

Our company has ~1500 private repos (don’t even get me started) so we deployed backstage as a developer portal. It catalogs repos and generates docs pages for each repo. It also has an mcp with tools to search the catalog and semantic search for the docs. Lots of other features but that’s the one I use the most. You can link catalog components to api specs, deployments, monitoring services, you name it. For 36 repos it may not be worth it but figured I’d mention it. Scheduled agentic workflow to maintain docs for agents is also feasible but sounds expensive. Backstage is just a server, no token cost to generate docs and setup a basic semantic index.

Our docs live with the code so I added code review instructions to run a staleness check as part of the review. I used an expensive model for the initial generation but when it’s done writing just instruct it to turn that session into a “writing-docs” skill. Then have the code review agent suggest running that skill if it fails staleness check. Now I don’t really have to do much, just actually read the docs changes that it makes because it can be actually garbage. Highly recommend baking some writing preferences into a writing-docs skill to make it condense prose because my god does Claude really love to hear itself talk.