The Meta Repo — Kasper Junge

The Meta Repo

July 12, 2026

Some time ago, someone I follow on LinkedIn wrote about the idea of a "meta repo" for coding agents.

At first, I confused it with a monorepo and thought, "Yes, I already know what that is." But a meta repo and a monorepo are not the same thing.

A monorepo contains multiple projects within a single repository. A meta repo, on the other hand, acts as a workspace that helps an agent understand, access, and work across many separate repositories.

Those repositories do not even have to contain code.

For example, I have a sub-repository in my meta repo for my businesses. It contains useful context, reminders, instructions, and information about how I work. This allows an agent to get up to speed quickly whenever I want to discuss business-related tasks.

The meta repo also manages access to my software projects. This is especially useful because an agent can easily reference patterns across my own repositories as well as other open-source projects.

You can ask it to do things like:

"Implement this feature in the same way it is implemented in that other repository."

This makes it possible to remix ideas, architectures, workflows, and implementation patterns across projects without manually explaining everything each time.

The meta repo becomes a kind of home base.

I rarely use the desktop or Finder on my computer anymore. Instead, I open a terminal inside my meta repo and begin typing or speaking, depending on where I am and how I want to work.

From there, the agent has the context it needs. It can navigate to the relevant repository, locate the right documentation, understand how the different projects relate to each other, and begin working with far less onboarding.

This also changes the role of the AGENTS.md file.

In many projects, AGENTS.md is primarily used to describe coding standards, formatting rules, and project-specific conventions. Those things are still useful, but inside a meta repo, the file can serve a broader purpose.

It can explain how to work effectively within the entire workspace.

For example, my meta repo includes instructions for how agents should use Git worktrees across my repositories. It can also describe where different kinds of information live, how projects are connected, which repositories should be used as references, and how the agent should navigate the workspace.

The goal is not simply to tell the agent how to write code.

The goal is to teach the agent how to operate inside your world.

Here is what the AGENTS.md for my meta repo looks like today:

# Agent Workspace

Kasper's top-level workspace — opened here to navigate across repos, brain-dump with<br>everything in context, or coordinate cross-repo changes.

- `Code/` — git repos, organized `Code///`.<br>- `Projects/` — non-code material (research, media, docs).

## Code/ layout

Path encodes GitHub owner + visibility. `` is the GitHub owner<br>(`kasperjunge` = personal, `computerlovetech` = work (my companys org), others = external clones).

Code///

## Shortcuts<br>- Personal blog (kasperjunge.com): `Code/kasperjunge/public/kasperjunge.com`.

## Rules<br>- This top level is a git repo (tracks `skills/`, `AGENTS.md`, `docs/`, agr config); `Code/` and `Projects/` are gitignored, and repos under `Code/` are individually versioned.<br>- `CLAUDE.md` is a symlink to `AGENTS.md`; edit `AGENTS.md` only.<br>- When editing `AGENTS.md`, add only the exact fact asked — no examples, no parentheticals, no listings, no rationale.<br>- Answer as concisely as possible — without compromising on substance — to be mindful not to drain my cognitive capacity with walls of text and info dumps.<br>- Do only what was asked. State relevant facts plainly and don't take speculative or unrequested actions; if something beyond the request seems warranted, say so and get agreement first.

- **Worktrees (do BEFORE first edit):** for any non-trivial task in a `Code/` repo, `git worktree add .worktrees/ -b ` and work there; never edit `main` directly. Gitignore `.worktrees/` if needed. Once the branch is merged, remove the worktree (`git worktree remove .worktrees/`), then in the main checkout `git checkout main && git pull` and delete the merged branch (`git branch -d `).