Skip to content
← Alle indlægRead in English
DAmeta-repoagentic-development

Project twenty starts with the first nineteen

I start projects in one shared workspace, split them out when they mature, and keep what we learned available to the next one.

Project twenty starts with what we learned from the first nineteen. That is the real benefit of my workspace — not that a coding agent can find all my repositories.

The experience accumulates instead of evaporating when I start something new.

I started thinking about this after Kasper Juunge wrote about his meta-repo. He described the difference between a monorepo and a meta-repo: a monorepo gathers code that belongs together. A meta-repo can gather many unrelated repositories and the context an agent needs to work across them.

That is close to the setup I have ended up with. But meta-repo no longer quite covers what I use it for.

Part repository, part workshop, part memory

My workspace contains agentics.dk, the blog, shared documentation, external repositories, and a projects folder full of products and experiments.

Some projects are small proofs of concept that still live directly inside the workspace. Others have matured into independent private GitHub repositories and come back as submodules. They get their own history and release cycle, while the agent can still see them alongside everything else.

My usual flow now looks like this:

  1. I get an idea and start it in projects.
  2. From the beginning, the agent can see the patterns, tools, and decisions already present in the workspace.
  3. If the project develops a life of its own, I create a private GitHub repository and move it there.
  4. I add that repository back as a submodule, so it remains part of the shared workspace.

The project can become independent without forgetting where it came from.

The experiments are turning into a portfolio

Over the past six months, projects has grown to include:

  • pks-agent-inbox, pks-agent-share, pks-agent-coach, and pks-agent-booking
  • pks-agent-registry, pks-agent-git, pks-agent-tunnel, and pks-agent-gateway
  • pks-agent-release, pks-agent-otel, pks-agent-domain, and pks-aspire-coolify
  • pks-agent-ftp, pks-agent-photogrammetry, DronePoul, and HeyPoul

Since March alone, I have added 18 projects as submodules in the workspace.

The number matters less than the fact that these projects no longer develop independently.

Email functionality from the booking project has been reused on agentics.dk. The push pattern from coach moved into the platform. The release and container setup from the registry project has become the reference used to assess the other products.

That is ordinary code reuse, but it is also decision reuse: What worked? What was painful? Which structure could the agent actually navigate? Which release failures should we avoid repeating?

The session files are the important part

I usually start the Claude session at the root of the workspace, even when the task ends up inside a submodule. The session can move between the project, agentics.dk, blog material, and shared notes without me manually packing the context each time.

But the meta-repo is only half of the setup. The session files need to survive too.

I work inside a devcontainer where Claude's entire configuration directory lives on a Docker volume:

"mounts": [
  "source=claude-code-config-${devcontainerId},target=/home/node/.claude,type=volume"
],
"remoteEnv": {
  "CLAUDE_CONFIG_DIR": "/home/node/.claude"
}

That keeps the session history intact when the container is rebuilt. Claude stores sessions as JSONL files under ~/.claude/projects/, grouped by the directory where each session began. When I start from the meta-repo root, the sessions are stored in the same place regardless of which repositories the agent edits along the way.

There is one more setting that is easy to miss. Claude cleans up old sessions after its retention period. A persistent volume does not help if the application later deletes the files inside it. In my global ~/.claude/settings.json, I therefore keep sessions for a year:

{
  "cleanupPeriodDays": 365
}

One year is my minimum; longer if there is room. I still back up ~/.claude. Persistence, retention, and backup solve three different problems.

On top of those raw session files, I built pks brain, a small CLI pipeline that can ingest them and make prompts, tool calls, touched files, and errors searchable:

pks brain ingest
pks brain search "release workflow"

You do not need to build that part on day one. The first useful step is simply to keep the session files and work from a shared root. Otherwise you have gathered the code while still discarding much of the learning between sessions.

Anything worth reusing can later be promoted into wiki notes, decisions, skills, or shared instructions. When I start a new project, the agent can find more than a similar implementation. It can also find the discussion about why we chose it and what went wrong afterwards.

It is compound interest, applied to experience.

Across isolated repositories, I can reuse a library. Here I can reuse the reasoning behind the library too.

The first time costs a long session, a few dead ends, and some new rules. The next project inherits the solution. If that project improves the pattern, the improvement becomes available to the next one again.

After enough rounds, the projects start fitting together in ways I did not plan at the outset.

AGENTS.md is mostly a map

Kasper also mentioned that AGENTS.md takes on a different role in a meta-repo. I recognise that.

The most important instruction at the root of my workspace is not whether we use tabs or spaces. Its first line sends the agent to a map of the workspace:

Read solution/repository-layout.md before choosing workspace scope, creating a top-level directory, or moving work between products, external repositories, or customer areas.

That map explains where the platform lives, where independent products belong, which folders contain customer work, and how to handle a submodule without confusing ownership.

The local repositories can still have rules of their own. The root only explains how the agent should move safely between them.

My AGENTS.md is probably not the right file for anyone else to copy. Its folders and rules are specific to my workspace. The useful idea is more modest: give the agent one place to start and a map from there. Then the conversation can begin with the problem instead of a guided tour of the filesystem.

The downside: mistakes compound too

Shared context is not an unconditional win.

The same effect works against me when the starting point is wrong. A quick workaround may be copied into five projects before anyone notices. If ownership between the root repository and a submodule is unclear, an agent can quickly end up committing to the wrong repository.

So I try to keep the boundaries fairly strict:

  • Proofs of concept are allowed to be messy while we learn.
  • A project gets its own repository when it develops its own identity and lifecycle.
  • Shared knowledge is promoted into documentation, skills, and decisions instead of being copied blindly.
  • Workspace-level instructions focus mainly on navigation and ownership.

I still do not want all my code in one giant repository. The code is allowed to move out. I just want to be able to find the experience again.

The next project does not start from zero

I did not begin with a plan to build a meta-repo. I simply kept starting small projects in the same place. When they matured, I gave them repositories of their own without sending them completely out of sight.

Now I can see that the structure itself has become an asset.

Every new project produces software, of course. It also produces context, rules, skills, release patterns, and a history of decisions. All of that stays behind and makes the next project a little cheaper to think through, a little faster to start, and a little harder to drive completely off course.

That is the part of the meta-repo idea I find most interesting: the agent can see all the folders, but it can also find what we learned inside them.