{"slug": "the-meta-repo", "title": "The Meta Repo", "summary": "A developer describes the concept of a \"meta repo\" — a workspace that helps coding agents understand and work across multiple separate repositories, including non-code projects. The meta repo serves as a home base for agents, providing context and instructions via an AGENTS.md file to teach agents how to operate within the developer's world.", "body_md": "Some time ago, someone I follow on LinkedIn wrote about the idea of a \"meta repo\" for coding agents.\n\nAt 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.\n\nA 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.\n\nThose repositories do not even have to contain code.\n\nFor 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.\n\nThe 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.\n\nYou can ask it to do things like:\n\n\"Implement this feature in the same way it is implemented in that other repository.\"\n\nThis makes it possible to remix ideas, architectures, workflows, and implementation patterns across projects without manually explaining everything each time.\n\nThe meta repo becomes a kind of home base.\n\nI 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.\n\nFrom 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.\n\nThis also changes the role of the AGENTS.md file.\n\nIn 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.\n\nIt can explain how to work effectively within the entire workspace.\n\nFor 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.\n\nThe goal is not simply to tell the agent how to write code.\n\nThe goal is to teach the agent how to operate inside your world.\n\nHere is what the AGENTS.md for my meta repo looks like today:\n\n```\n# Agent Workspace\n\nKasper's top-level workspace — opened here to navigate across repos, brain-dump with\neverything in context, or coordinate cross-repo changes.\n\n- `Code/` — git repos, organized `Code/<owner>/<public|private>/<repo>`.\n- `Projects/` — non-code material (research, media, docs).\n\n## Code/ layout\n\nPath encodes GitHub owner + visibility. `<owner>` is the GitHub owner\n(`kasperjunge` = personal, `computerlovetech` = work (my companys org), others = external clones).\n\n    Code/<owner>/<public|private>/<repo>\n\n## Shortcuts\n- Personal blog (kasperjunge.com): `Code/kasperjunge/public/kasperjunge.com`.\n\n## Rules\n- 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.\n- `CLAUDE.md` is a symlink to `AGENTS.md`; edit `AGENTS.md` only.\n- When editing `AGENTS.md`, add only the exact fact asked — no examples, no parentheticals, no listings, no rationale.\n- 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.\n- 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.\n\n- **Worktrees (do BEFORE first edit):** for any non-trivial task in a `Code/` repo, `git worktree add .worktrees/<branch> -b <branch>` and work there; never edit `main` directly. Gitignore `.worktrees/` if needed. Once the branch is merged, remove the worktree (`git worktree remove .worktrees/<branch>`), then in the main checkout `git checkout main && git pull` and delete the merged branch (`git branch -d <branch>`).\n```\n\n", "url": "https://wpnews.pro/news/the-meta-repo", "canonical_source": "https://kasperjunge.com/blog/the-meta-repo/", "published_at": "2026-07-12 19:10:12+00:00", "updated_at": "2026-07-12 19:35:21.406306+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-tools"], "entities": ["Meta", "LinkedIn", "Git", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/the-meta-repo", "markdown": "https://wpnews.pro/news/the-meta-repo.md", "text": "https://wpnews.pro/news/the-meta-repo.txt", "jsonld": "https://wpnews.pro/news/the-meta-repo.jsonld"}}