Running Agents Across Multiple Repos: Matt Pocock Keeps Just One Home Repo

Matt Pocock was asked a specific question on X: how to use agents to work across multiple repositories at the same time. His answer is a home repo.

The approach is not complicated. Put all skills, steering files, and wiki in one repository, and run the agent in that repository too. Then write pointers in AGENTS.md to tell the agent where the other repositories are:

For skills, clone mattpocock/skills to ~/repos/skills.
For Sandcastle, clone mattpocock/sandcastle to ~/repos/sandcastle

This solution is so simple it hardly feels like a toolchain discussion, but the more valuable part in the replies is the boundaries.

This structure produces three direct outcomes. Steering files and tools are centralized in one place. All agents have the same starting point. Changes across multiple repositories can be initiated from one entry point. Matt Pocock says this approach is simple and powerful.

Someone in the replies asked how teams use it. Matt Pocock's answer: the home repo belongs to the team, and everyone runs their own agent there. As for permissions, some people worried that one agent can touch all repositories. Matt Pocock asked in return why that should be more nerve-racking than letting a single agent touch a local part of a single repository. The question wasn't expanded on, but the boundary is worth noting: the home repo is an entry point, which does not mean all permissions should be opened unconditionally.

For working on multiple features in parallel in the same repository, someone asked whether to clone multiple copies. Matt Pocock said to use worktrees in each clone. Another person warned that after running this way for a few months, the disk will fill up with unmanaged worktrees. Matt Pocock's answer was direct: clean them up.

Where to put a repository's own build commands also came up in the replies. Matt Pocock does not recommend piling them into the home repo. Repositories that need these commands should keep them, and the home repo should only hold navigation pointers. Instructions for cross-repo tasks go in the home repo as cross-repo issues.

Someone added a detail about Claude Code: a cloned repository's own memory and rules files will not load from additionalDirectories; to load them from --add-dir, you need to set CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1. If you put all steering in the home repo like Matt Pocock does, this limitation does not affect you.

Monorepos also came up. Matt Pocock said monorepos are great too, but they require a lot of tooling and are not always feasible. Another person's approach is to put a .knowledge folder next to the repository, use SQLite FTS and MiniLM vectors for local search, and then use a skill to pull in relevant snippets.

The most memorable point came from Matias Poblete: each repository should still keep a small AGENTS.md containing only what is true for that repository, such as scripts, lint rules, and places not to touch. Otherwise the AGENTS.md in the home repo will gradually turn into a list of exceptions. Matt Pocock agreed.

In practice: navigation goes in the home repo, local rules go in the repository, cross-repo issues go in the home repo, and worktrees are cleaned up after use. Simple solutions work, but you have to fill in the boundaries yourself.

Original tweet: https://x.com/mattpocockuk/status/2120260969750540327