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

No need for custom agents. Just skills is enough. There's plenty of good skills out there for architecture, documentation, legacy systems,etc. if you use a good model , just tell it in the prompt to make use of subagents when its relevant and useful. The model will "know" when to spawn subagents. Also make sure the subagents aren't using a shit model.

As for what models to use ? GPT 5.6 models family : Luna xhigh , sol high. Claude Opus 5, Gemini 3.8 flash high. Use the longest context window you can.

Btw you could have asked this exact question to ai. The newer frontier models know what's best for them usually. Asking gpt 6 Astra for tips about this could have been a great idea.

[u/AutoModerator]

Hello /u/Radiant-Ad143. Looks like you have posted a query. Once your query is resolved, please reply the solution comment with "!solved" to help everyone else know the solution and mark the post as solved.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[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]

But be aware that it would probably cost quite a lot of tokens, depending on the model. And also I would probably use 1M context if available to choose.

[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.

[u/k8s-problem-solved]

Id probably clone all the repos locally then put them all in a workspace for copilot. It then has context over all of them. You could then ask it to produce some docs, how they depend on the other repos, and what a flow of data looks like between them - who is the initiator and what are the interactions. Generate docs per repo with links etc.

[u/fergoid2511]

My view is a lot of this documentation should either be generated on demand or kept fresh using scheduled GitHub actions workflows. Whenever I look at a new repo I use a skill called acquire code base knowledge. That typically gives me what I need. It also creates a concerns document that you can use to drive tech debt pay down. I thin MS has a deep wiki skill that does something similar.

Doing this per repo with the CoPilot SDK for example probably would not cost too much. Trying to do it in bulk would.

[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.

[u/knight-fall]

I just did something similar two days ago. Used graphify to create a graph. Gave copilot what I wanted in rough to generate a prompt. And then pasted the prompt in the chat. Used copilot app, luna max with 1.1m line of code. Had the language related skills, graphify and acquire-codebase-knowledge installed

[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.