MCP + SKILLS FOR GROUP VIBECODING IN ONE REPO

The swarm of parallel agents needed shared state, but each wrote to it from its own session — after a failed git pull the state could drift and agents worked against different versions of the architecture. Instead of inventing a sync protocol, I built it on git with a 3-second cooldown against commit spam and client-side retries, and made the 'brain' server the single source of truth: every agent calls get_all before touching anything. A whole class of conflicts disappeared, because nobody works on stale state anymore.

The overnight loop runs on several machines at once, each on its own module — with no coordinating server, backend or queue. Who runs the merge, and when? How do you avoid doing it twice? What if one PC doesn't finish by morning? I built the whole coordination on primitives the team already has — files in git: each PC writes a done/<module>.json marker and pushes when finished; the coordinator is picked by 'last one turns off the lights' — whoever counts a full set of markers or hits the wake-up timeout does the merge; a merge.lock file committed to the repo guards against a double merge, and on timeout the merger only consolidates modules with a marker, explicitly noting the interrupted ones in SUMMARY.md instead of pulling in potentially broken branches. Honestly: a lock via git is a best-effort mutex, not a critical section — with 2–5 machines a race ends at worst in a rejected push, and I accepted that trade-off knowingly.

Each researcher used to start with the full hackathon context, so token cost grew linearly with the number of modules — and transcripts and web content carried a prompt-injection risk. I trimmed the contexts: the skill hands a researcher only the 3–5 fields of its own module, and the get_all tool returns a compact ~1K-token summary instead of the full state JSON. The agent itself is hardened — it ignores instructions embedded in content, sticks to a source whitelist (Context7 > GitHub > Playwright), and never executes anything from the web.

The overnight loop keeps a change only if it doesn't break tests — but I generate the tests from the spec, before the code exists. Naively: on night one the baseline is 100% red, so every change looks 'regression-free' and the loop keeps garbage, while importing a non-existent module can blow up the whole test run. I defused it with two coupled mechanisms: spec-only tests start with an auto-activation block that pings the module's first endpoint and switches it to it.skip until the module is alive — the baseline is 0 failures, and tests switch themselves on when the endpoint starts responding; on top of that, the gate counts regressions, not failures: before the loop I record the already-red tests and reject an experiment only when a previously green test turns red. The third rule is hard: the loop never touches anything visual, because nobody takes screenshots at night — logic, types and tests only.