integrationlisted

# integration The glue-layer umbrella for robium. Once `architect` has picked a stack and `environments` has decided how a single module runs reproducibly, something has to decide how the *modules* find and talk to each other, and how they're packaged so the whole system starts up as one thing. This skill owns three tightly related decisions: where the module boundaries are, what comms crosses each boundary, and how Dockerfiles/docker-compose package and wire the result. It does not decide the stack (`architect`) or a single module's env reproducibility (`environments`) — it decides how already-chosen modules become a running system. ## When to use this skill - Wiring two or more components together and the question is "how should these talk" — a planner to a controller, a perception node to a policy, a sim to an app container. - The trigger phrases in the description: 'containerize this', 'dockerfile', 'docker compose', 'how should these modules talk', 'connect the planner to the controller'. - Any multi-process or multi-container robotics system, even a simple two-container sim+app pair. - Cross-references — go to the sibling skill instead when the question is: - The overall stack hasn't been chosen yet → `architect` (load first; it routes here once the stack and modules are known). - A single module's reproducibility (uv vs Docker, GPU passthrough, base image) rather than how modules talk to *each other* → `environments`. This skill assumes eac