Cross-repo Agent work is too fragmented—Matt Pocock uses a Home Repo as headquarters

Anyone with five or more repos has probably run into this scenario: start a coding agent separately in each repo, and configure its own skills, AGENTS.md, and toolchain in each one. When a feature needs changes across three repos, the agent can only see the current directory, and halfway through planning you have to manually move context around.

Matt Pocock posted a video on X explaining the solution he has used for several months. He said he originally thought the approach was too boring and too obvious to be worth posting.

This pattern is called Home Repo. One git repo holds the skills, AGENTS.md, shared docs you use across projects, and navigation pointers to other repos. The agent starts from the Home Repo and, when it needs another repo, follows the pointer to open or clone it.

It solves three concrete annoyances: steering files and toolchains get a single unified entry point; all agents can start in the same place; and large changes spanning multiple repos can be completed in one session.

Matt Pocock provides a set of prompts you can paste directly into an agent, in four steps.

Step one, inventory the repos. Find all git repos under your home directory, skip dependency directories, and record each one's path, remote, whether it is public or private, and the time of the last commit. Then have the agent ask you in rounds: which repos the Home Repo should point to, where it should live, whether it is for personal or team use, and whether your harness loads AGENTS.md or CLAUDE.md on startup.

Step two, inventory shared materials. In the selected repos and the user-level skill directory (for example ~/.claude/skills), list every skill (folders containing SKILL.md), every AGENTS.md and CLAUDE.md, and every document written for agents. Put each item into one of four buckets: shared, common across repos; duplicate, repeated in multiple places, keep the newest after diffing; repo-specific, code, commands, or domain knowledge that belongs only to one repo; installed, installed from a public skill repo or marketplace.

Step three, produce a plan table. For each item, where it is now and where it should go. Move shared and duplicate items into the Home Repo and keep only one latest version; keep repo-specific items in their original repo; keep installed items installed. Below the table, include the Home Repo's AGENTS.md, one pointer per line.

The pointer looks like this:

Storefront (Next.js app): ~/repos/acme/storefront. Clone from git@github.com:acme/storefront.git if missing.
Payments API: ~/repos/acme/payments-api. Read its AGENTS.md before changing it.
AI Hero: ~/repos/ai/ai-hero (git pull to view latest, likely out of date)

Step four, execute. Create the Home Repo and AGENTS.md, copy the shared items in, and keep skill folders intact. Then go to each child repo, create a new branch, delete the copies that have been moved out, and leave repo-specific content untouched. Finally, commit in the Home Repo; whether to push is up to you.

There is a scale threshold. At around 20 repos or fewer, one pointer per line is fine. At around 400, having the agent read pointers line by line is already too much; split them into files by business domain, and have AGENTS.md point only to those files. At thousands of repos, there are too many consumers of skills, and a skills marketplace is more appropriate.

Matt Pocock gave brief answers to a few common questions in replies.

Someone asked whether per-repo CLAUDE.md files disappear. He said they remain; they only describe things specific to that repo.

Someone asked how to version skills across repos. He replied: don't; just put them in the home repo.

Someone asked what to do when a shared skill conflicts with repo-specific instructions. He replied: fix the conflict.

Someone asked whether this is a personal repo and can't be used to share skills with a team. He said a team can share the same Home Repo, with everyone contributing to it—that's the whole point.

Someone else used submodules to put the Home Repo into other repos for distribution. Matt Pocock said that works; with 5 to 10 repos, the submodule approach is fine, and plain pointers do the same thing without having to deal with submodules.

Technically, there is nothing new about this pattern; it is just a directory convention plus a navigation file. The real time sink is the inventory: skills and config scattered everywhere, which are shared, which are unique to a repo, and which already exist in three duplicates. Matt Pocock says it is boring and obvious, probably because the pain is concentrated in this step.