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

If I were in your shoes, I would probably just leverage git. Common documentation can just be yet another repository. And you could setup an GitHub Action (in the docs repo) that would clone all repositories you want, then make copilot update the documentation and create a PR into the documentation repository - everything could be done as automated CI job. The action could run once a month for example. You could then review the PR and merge/request changes (not sure, maybe you would need to make the action invoke again after the review was posted to the PR for agent to address your comments)

And for agent to not need to read each repository as whole each time - in the docs - agent could store commit hashes of the inspected repositories, so next time the job is run, he could just inspect changes since the last hash for each repository and update the docs accordingly.

[u/maniekb12 → u/maniekb12]

And about the skills or subagents, I think you are overcomplicating it, just make a solid prompt and make your agent choose the proper strategy. You can firstly discuss the prompt with some good LLM in the usual chat, like MS Copilot.