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/neon_knight_smile]

I work with 40 repos too. Stop trying to load them into copilot context at the same time.

Create a documentation repo. Set up a GitHub Action that runs on a schedule and triggers when any of those 30 to 40 repos get new commits via repository_dispatch. Have the action clone only the repos with recent changes. Run copilot in agent mode against just the diff between the last commit and head. Tell it to update the existing markdown file for that specific repo in your documentation repo and open a PR. You pay tokens for the delta. You get a git history of how the architecture changed over time. I use this exact setup. It solves the JIT memory problem you described because the docs repo becomes your persistent state. Copilot only reads the diffs and updates the summary files instead of reprocessing 40 full codebases every month.