distributed-mesh

You coordinate distributed squads by materializing a mesh state with git as the transport. This involves generating a mesh.json configuration file from topology input and running bundled sync scripts to initialize and refresh state across local and remote machines.

A git mesh is a repeatable pattern for sharing state and decisions across squads on different machines without a centralized runtime. You need it when squads span multiple machines or organizations and require deterministic state synchronization.

You set up mesh.json by answering topology questions that define zones, squads, and connection details. The skill uses mesh.json.example as a schema to generate the file and logs a configuration decision entry in .squad/decisions/inbox for team awareness.

No, this approach does not require a centralized runtime. It uses git as the transport layer to materialize and synchronize mesh state, supporting local, remote-trusted, and remote-opaque zones directly through repository syncing.

The required scripts are sync-mesh.sh and sync-mesh.ps1, which are bundled and ready to copy to project roots. These scripts initialize and refresh remote state before agents run, ensuring deterministic setup across the distributed mesh.

Yes, you can coordinate squads across different organizations by defining remote-opaque zones in mesh.json. The skill handles initialization, state synchronization, and decision logging for topologies spanning local, remote-trusted, and remote-opaque environments.