One Folder, Many Projects: How Nested Git Repos Unlocked My Agentic Workflow

A small filesystem tweak that quietly fixed the worst part of running a bunch of open source projects: keeping the code, the docs, and the marketing site in sync.

I kept running into the same friction. I’d ship a feature in Coco, then five minutes later realize the README needed an update, the wiki needed a new page, and the marketing site at coco.griffen.codes had a stale install command sitting on the homepage. Three repos, three context switches, three chances to forget one.

For a while I just lived with it. Each project had a sibling folder layout on disk: coco/ next to coco-www/ next to whatever wiki notes I happened to have lying around. When I wanted to update docs after a code change, I’d close the editor, open another window, try to remember the gist of what I just shipped, and start typing. Half the time I’d skip the wiki entirely because the friction was just high enough to defer it.

Then agents got good. And the cost of that fragmentation went from “annoying” to “actively breaking my workflow.”

The problem with sibling folders

When you’re driving an agent through a coding task, context is everything. The model can only reason about what it can see. If your library lives in one folder and your docs live in a folder next door, the agent in your library session has no idea the docs exist. You either have to feed it a second copy of the docs as context (lossy, manual, easy to forget), or you have to spin up a second agent in the docs repo and play telephone between the two.

Both options waste the thing agents are actually good at: holding a lot of context at once and acting on it coherently.

The hack: nested git repos in dotfolders

The fix turned out to be embarrassingly simple. Inside each project’s main repo, I now keep two hidden folders:

• .wiki/ – a clone of the project’s GitHub Wiki repo
• .www/ – a clone of the project’s marketing or docs website repo

Both are full git repositories in their own right, with their own remotes, branches, and history. They just happen to sit inside the parent repo’s working tree. A two-line addition to .gitignore keeps the parent repo from ever trying to track them:

# .gitignore
.wiki/
.www/

The trick that makes this work is GitHub’s wiki itself. Every GitHub Wiki is a real git repository under the hood, accessible at https://github.com/<owner>/<repo>.wiki.git. So setting up a new project workspace looks like this:

cd coco
git clone https://github.com/gfargo/coco.wiki.git .wiki
git clone https://github.com/gfargo/coco-www.git .www
echo ".wiki/\n.www/" >> .gitignore

That’s it. Now the library, the docs, and the marketing site all live inside one folder my editor and my agent can both see at the same time.

Why this changes the agent loop

The first time I tried this on Strut, the difference was immediate. I shipped three small fixes: a config parsing bug, a new flag, and a tweak to the deploy step. Normally that’s three separate “remember to update the docs” todos that I’d file away and probably forget. Instead, after the last commit I just turned to the same Claude Code session and said: “Now look in .wiki/ and .www/ and update anything affected by what we just changed.”

It found the right wiki page, updated the flag reference, caught a stale example in the marketing site’s quickstart, and committed each change to its respective repo. No re-explaining what we’d done. No second agent. No telephone game.

The reason this works so well is that modern context windows are large enough to hold the whole project at once. Three bug fixes plus a wiki page plus a marketing landing page is well within range. So a single orchestrator agent that already knows what shipped can fan out into the sibling directories and make coherent updates across all of them in one pass.

That last part is the part I keep coming back to. The agent doesn’t need to be told what changed because it’s the agent that just changed it. All the context is right there.

The release flow this enables

The workflow I’ve settled into now looks roughly like this:

1. Ship a few changes through the day. Bugs, features, refactors, whatever.
2. When I’m ready to cut a release, ask the agent to draft release notes from the diff since the last tag.
3. With that same context still loaded, have it sweep through .wiki/ and update any affected pages.
4. Same again for .www/: update the homepage copy, the install command, the feature list, whatever’s drifted.
5. Review, push each repo, tag the release.

The whole thing happens in one session. The release notes, the docs update, and the marketing copy all get written by the same model that wrote the code, with the same understanding of what actually changed.

The documentation loop

There’s a bonus benefit I didn’t fully appreciate until I’d been using this setup for a few weeks. Because the wiki is a real git repo and the marketing site can pull from its API, I now have a single source of truth for documentation that flows in one direction.

The pattern: docs are written and versioned in the GitHub Wiki. The marketing site fetches them at build time (or on demand) from the GitHub Wiki API and renders them under /docs. Each rendered page includes a small “edit this page” link that drops the reader straight into the GitHub Wiki editor for that file.

That gives me three things at once:

• Docs that live next to the code, in a real repo, where my agents can edit them in the same session as the code change that triggered the update.
• A polished public docs experience on the marketing site, styled to match the rest of the brand.
• A frictionless contribution path for users: spot a typo on the docs site, click “edit this page,” land in the wiki editor, ship a fix.

Before this, the docs on the marketing site and the docs in the repo would inevitably drift. Now they can’t, because there’s only one of them.

Where this shows up in my projects

I’ve been rolling this layout out across the projects I actively maintain. A few spots where it’s earned its keep:

• Coco ships frequently and the install/usage examples on the marketing site need to track CLI changes. The nested layout means a flag rename never lives more than one session away from the docs that mention it.
• Strut has a chunky wiki because the helper-script-to-agent-toolkit story has a lot of moving parts. Keeping the wiki repo right inside the project means it gets updated as part of the same commit cycle, not as a separate “I should write that up someday” task.
• Spec Shaver and SpecForge are close cousins, and their docs cross-reference each other. Having both wikis cloned locally next to their codebases makes it easy to keep that cross-linking accurate.
• Vercel Doorman and Fargo Flags both have marketing landing pages that show off real CLI output. When the CLI output changes, the screenshots and snippets need to follow. Same workspace, same agent, one pass.

Caveats and trade-offs

A few things worth flagging if you want to try this:

• You’ll have multiple git remotes in one workspace. Your editor’s git UI may get a bit noisy. Most modern editors handle nested repos fine, but it’s worth checking yours.
• Don’t forget the gitignore. If you skip that step, the parent repo will try to track the nested folders and you’ll get into a tangle. The dotfolder prefix is partly cosmetic and partly there to make the gitignore line obvious.
• Agents need to be told the layout. A short note in your project’s AGENTS.md or CLAUDE.md explaining that .wiki/ and .www/ are nested repos for the wiki and marketing site goes a long way. Otherwise the agent may treat them as throwaway folders.
• It only really pays off if you actually have a wiki and a marketing site. If you don’t, there’s nothing to nest. But for any project that’s grown past a single README, this scales nicely.

What’s next

The next thing I want to figure out is whether this layout makes sense to formalize as a template. Something like a griffen-project-template with the gitignore lines, the AGENTS.md notes, and a small bootstrap script that clones the wiki and www repos into place. If that ends up being useful I’ll write it up.

For now, the takeaway is just this: when you’re working with agents, the layout of your filesystem becomes part of the prompt. Putting the things that need to stay in sync inside the same workspace is one of the cheapest, highest-leverage changes I’ve made to my workflow this year. Give it a try if you’re juggling a library, a wiki, and a marketing site across three folders. The friction you stop feeling is real.

If you’ve found a different layout that works for you, I’d genuinely like to hear about it. Drop me a note.