A friend asked me to help rebuild her website. Maya runs Remote Work Europe — country guides and resources for people working remotely across Europe. The site had been on Squarespace for years. She wanted it on something she could actually control. I said I’d help.
I started the migration on my own — pulling content out of Squarespace, rebuilding in Astro, pushing to a staging server on my VPS so Maya could see progress. Standard solo work. What wasn’t standard was what happened next: Maya was using Claude Code too, on her own machine, making her own changes. And the way we were sharing work was… WhatsApp.
We’d each run Claude, get it to do something, then send each other the outputs as markdown attachments. “Here’s what my Claude did to the nav.” “Here’s the updated about page.” Then we’d each paste the other’s changes into our own local copy. Independently. Manually.
It worked, sort of. But there was lag. I’d make infrastructure changes, push to staging, and Maya wouldn’t see them until I messaged her. She’d rewrite content and I wouldn’t know until she sent it over. We were two people with capable AI assistants, coordinating through a group chat like it was 2015.
Git doesn’t onboard people. Setup docs do.
The obvious fix was a shared GitHub repository. Less obvious: Maya had never used GitHub before.
This is where Claude earned its keep. I wrote a setup document — how to install Claude Code, how to run the site locally, how to sync changes to GitHub, how to keep private things private. Not instructions for Maya to follow step by step. Instructions for Maya’s Claude to follow, so she could say “set me up” and her AI would handle the git configuration, SSH keys, and first push.
That’s a meaningful distinction. I wasn’t teaching Maya git. I was giving her Claude enough context to handle git on her behalf. She didn’t need to learn branching or staging or remotes. She needed to say “push my changes” and have it work.
A file both sides agree to read
With both of us in the same repo, the next problem was coordination. I could see Maya’s commits in the git log, but my Claude couldn’t tell why she’d changed something, or what she was planning next. Git tells you what happened — not what the other person was thinking.
What I went with: a markdown file in the repo root called COLLAB.md. Both Claudes read it when they start a session. Both update it when they finish. Git history is the audit trail.
The file has a few sections: what’s been done recently, what’s flagged for the other person, what’s in progress and shouldn’t be touched. Nothing fancy — just enough shared state that neither Claude starts a session blind.
When I finished a batch of work — say, restructuring the navigation or setting up the deployment pipeline — I’d update COLLAB.md with what changed and why. When Maya’s Claude picked up the repo next, it read the file and knew what had shifted. Same in reverse.
I’d also considered building an RSS feed into the site — a machine-readable channel that either Claude could fetch via URL. It would have worked, but it would have meant maintaining infrastructure that existed purely for agent coordination. A markdown file in a repo we already shared was simpler.
Here’s roughly what the file looks like:
# COLLAB.md
## Recent Changes
- Jim: Restructured nav to use dynamic routing (Mar 9)
- Maya: Rewrote all 26 country guide intros (Mar 10)
## Flags for Other Person
- @Maya: Image paths changed — old /img/ prefix is now /assets/
- @Jim: Cookie consent component needs styling review
## In Progress (Don't Touch)
- Jim: Deployment pipeline — testing SSH keys
- Maya: Partner hub page layoutTwo Claudes, different instincts
We never formally divided the work — it happened naturally.
Maya’s Claude handled the content — introductions for all 26 country guides, the about page, a partner hub, cookie consent, disclaimer components, blog updates. Her Claude made content decisions: tone, structure, what readers need to see first.
My Claude handled the plumbing — migration, search, deployment pipeline, image compression, redirect rules, fixing things that broke after Maya’s changes landed. The kind of work where the output is invisible when it’s done right.
COLLAB.md tracked the boundary. When Maya’s commits landed and something in the nav conflicted with the deployment setup, my Claude could see from the file what she’d intended. When I changed how images were handled, her Claude could see why files had moved.
One coworking session to ship
We’d been working asynchronously for weeks. Then we had one face-to-face coworking session and pushed the site to production.
That session is where I discovered Maya’s hosting provider had an API. Shared hosting — the kind of setup where you normally upload files through a control panel. But the API let us set up SSH deployment and adjust DNS records from the command line. My Claude found the endpoints, worked out the authentication, and we had a deployment pipeline running within the session.
We migrated the redirect rules from Squarespace, switched the DNS, watched the site go live. Two Claudes, one coworking afternoon, and a site that had been on Squarespace for years was running on infrastructure we controlled.
The audit that ran itself
After that session, Maya kept pushing content. New pages, new components, updates across the site. When I pulled her latest batch of commits, my Claude ran a build, dispatched an audit agent to check site health, and reported back: build clean, no broken references, no orphaned links — two small infrastructure issues and two content decisions to flag for Maya.
I fixed the infrastructure issues, wrote up the content flags in COLLAB.md, pushed. Done.
The repo itself — CLAUDE.md for project instructions, COLLAB.md for coordination state — carried all the context both Claudes needed. Neither of us had to brief the other’s AI on what the project was about. The files did it.
Git was already a protocol
I’d been thinking about agent coordination as a tooling problem — that multiple AI agents collaborating must need protocols, a message bus, something purpose-built for the job.
It didn’t. The answer was a text file and git.
COLLAB.md works because it leans on what’s already there. Git already tracks who changed what and when. Markdown is already readable by both humans and AI. The discipline of pull-before-work and push-after-work already exists — we just added a file that both sides agreed to read and update.
There’s no orchestration layer. No central coordinator. Just two people with their own Claudes, a shared repo, and a convention: read the file, do your work, update the file.
What I keep coming back to: we went from swapping markdown over WhatsApp to a shared repo with a coordination file, and the difference was immediate — fewer gaps, fewer surprises, less time spent catching each other up. I’m not sure yet whether that scales beyond two people or whether we got lucky with the scope. But the principle — check whether the tools you already use have enough surface area before building something new — that part I’m confident about.
Next
- Does this scale past two people? Probably not without more structure around the COLLAB.md format — sections per person, maybe conflict resolution conventions. Haven’t tested it.
- What breaks first? My guess is merge conflicts in COLLAB.md itself. If both people update the same section between pulls, git can’t resolve it automatically. Hasn’t happened yet, but it will.
- Could the Claudes update COLLAB.md automatically via hooks? A PostToolUse hook that appends to a “recent changes” section would remove the manual step. Haven’t built it because the manual update forces a moment of reflection about what actually matters for the other person to know.
The site is live at remoteworkeurope.eu if you want to see what two Claudes co-piloted.
