cross-squad

Context

Read this FIRST any time the user says "squad" as a thing to spawn, delegate to, address, or fan out to — e.g., "spawn two squads of designers and devs", "ask the other squad", "delegate to a squad". In Squad-PRODUCT vocabulary, "squad" is a peer (an independent installation with its own .squad/, team.md, MCP server, and agents) — NOT a generic English synonym for "team" or "group". Do not fan out raw task agents inside your own coordinator context when the user means "another squad". Use the discovery and communication patterns below (and the companion cross-squad-communication skill for the actual protocols).

When an organization runs multiple Squad instances (e.g., platform-squad, frontend-squad, data-squad), those squads need to discover each other, share context, and hand off work across repository boundaries. This skill teaches agents how to coordinate across squads without creating tight coupling.

Companion skill — for protocol details: cross-squad-communication/SKILL.md covers the four communication patterns (synchronous CLI, read-only knowledge query, git-based async, and GitHub-issue-based delegation) once a peer squad is discovered via the registry below. This skill answers "who?" — the companion answers "how?".

Cross-squad orchestration applies when:

• A task requires capabilities owned by another squad
• An architectural decision affects multiple squads
• A feature spans multiple repositories with different squads
• A squad needs to request infrastructure, tooling, or support from another squad

Disambiguation: "squad" vs ad-hoc agents

When the user uses the word "squad" / "squads" or asks to "spawn a team", the coordinator MUST treat it as a literal reference to a Squad install (a .squad/ directory with its own roster, casting, and coordinator) — NOT as a casual synonym for "a group of sub-agents".

Default behaviour (apply unless explicitly told otherwise)