cross-squad · git:20260404.53eddac · 2026-04-04 · sha256 8af1185908056cfa
cross-squad git:20260404.53eddacA
Immutable. This exact content never changes and is served at /api/v1/blob/8af1185908056cfa.
---
name: "cross-squad"
description: "Pathfinder patterns for multi-repo squad orchestration — HQ command, squad-to-squad protocol, fleet dispatch, and Unix-style AI composition"
domain: "orchestration, multi-repo, fleet"
confidence: "low"
source: "first capture from blog Part 8 — Pathfinder: When AI Squads Learn to Talk to Each Other"
---
## Context
When squads grow beyond a single repository, they need patterns for cross-repo communication, fleet-wide orchestration, and composable pipelines. This skill captures the "Pathfinder" patterns discovered when tamresearch1 became the HQ for a fleet of squads spanning multiple repos and machines.
These patterns apply when:
- One repo orchestrates work across multiple child repos (fleet command)
- Independent squads need to share decisions, skills, or status
- AI-powered steps mix with deterministic CLI tools in pipelines
- A watch loop monitors multiple repos simultaneously
- Tasks must route to specific machines based on capabilities (GPU, memory)
## Patterns
### 1. Squad HQ Pattern
One repo acts as fleet command, orchestrating squads across multiple repositories. Issues filed in HQ get triaged and routed to child squads.
**Structure:**
```
tamresearch1/ ← HQ repo (fleet command)
├── .squad/
│ ├── fleet.json ← registry of child repos
│ ├── decisions/ ← fleet-wide decisions
│ └── agents/
│ └── ralph/ ← fleet-aware Ralph
├── squad-pr/ ← child: Squad CLI development
├── blog-repo/ ← child: blog content
└── infra-repo/ ← child: infrastructure
```
**Fleet registry (`fleet.json`):**
```json
{
"hq": "tamirdresher/tamresearch1",
"children": [
{
"name": "squad-cli",
"repo": "tamirdresher/squad-pr",
"capabilities": ["typescript", "cli", "sdk"],
"labels": ["squad:cli"]
},
{
"name": "blog",
"repo": "tamirdresher/blog-repo",
"capabilities": ["content", "markdown"],
"labels": ["squad:blog"]
}
]
}
```
**HQ routing:** When an issue arrives at HQ, the coordinator examines labels and content, then files a child issue in the appropriate repo:
```bash
# HQ receives: "Add built-in skill for cross-squad patterns"
# Coordinator routes to squad-cli repo:
gh issue create --repo tamirdresher/squad-pr \
--title "[from-hq] Add cross-squad built-in skill" \
--body "Routed from HQ issue #42. Context: ..." \
--label "squad:cross-squad"
```
### 2. Squad-to-Squad (S2S) Protocol
How independent squads communicate without tight coupling. Four mechanisms:
**a) Shared decisions format:**
Every squad writes decisions in the same format to `.squad/decisions/inbox/`. When a decision affects another squad, the originating squad files a cross-repo issue referencing the decision.
```markdown
### 2026-03-14: Adopt markdown as universal interface
**By:** Picard (tamresearch1)
**What:** All cross-squad data exchange uses markdown
**Why:** Every agent can read/write it, git tracks it, humans can review it
**Affects:** squad-cli, blog-repo, infra-repo
```
**b) Cross-repo issue filing:**
Squad A files an issue in Squad B's repo when work crosses boundaries:
```bash
# Squad A (blog) needs a CLI feature from Squad B (squad-cli)
gh issue create --repo tamirdresher/squad-pr \
--title "[s2s:blog→cli] Need --fleet flag for watch command" \
--body "Blog squad's Ralph needs fleet mode. See blog#78 for context." \
--label "squad:s2s"
```
**c) Shared skills library:**
Skills earned in one squad are available to others. When a squad learns a reusable pattern, it gets promoted to the built-in skills library so all squads benefit:
```
Squad A discovers pattern → writes SKILL.md locally
→ PR to squad-cli repo → merged as built-in skill
→ all squads get it on next `squad init` or `squad reskill`
```
**d) Status polling:**
Ralph checks multiple repos on each watch cycle, aggregating status across the fleet:
```bash
# Ralph's fleet poll cycle
for repo in $(jq -r '.children[].repo' .squad/fleet.json); do
gh issue list --repo "$repo" --label "squad:active" --json number,title
done
```
### 3. Unix Philosophy Applied to AI Squads
Squads as composable Unix-style tools. The key insight: markdown is the universal interface (text in / text out), and AI-powered steps slot into pipelines alongside deterministic tools.
**Core principles:**
- **Text in / text out** — Markdown as the universal interface between steps
- **Single responsibility** — Each squad owns one domain
- **Composable pipelines** — Mix deterministic CLI steps with AI-powered steps
**Example pipeline:**
```bash
# Deterministic + AI pipeline
dir docs/*.md \
| sed 's/\.md$//' \
| squad ask "Analyze these doc names and suggest missing topics" \
| squad ask "For each missing topic, write a one-paragraph outline" \
| lint-markdown
```
**Mixed pipeline with explicit AI steps:**
```
INPUT (file list)
→ deterministic: find + filter
→ AI: ANALYZE (identify patterns, suggest improvements)
→ deterministic: lint + format
→ AI: REWRITE (apply suggestions)
→ deterministic: test + commit
```
**Why this works:** Each step consumes text and produces text. The AI steps are interchangeable — swap models, swap agents, swap squads. The deterministic steps provide guardrails and validation between AI steps.
### 4. Fleet Dispatch
The watch command's fleet/hybrid mode for multi-repo monitoring. Ralph runs in one repo but watches the entire fleet.
**Fleet watch cycle:**
```
Every 5-10 minutes:
1. Pull HQ repo
2. Read fleet.json for child repos
3. For each child repo:
a. Check open issues with squad:* labels
b. Check PR status (pending reviews, failing CI)
c. Check .squad/cross-machine/tasks/ for pending work
4. Aggregate status → write to .squad/log/fleet-status.md
5. Route urgent items → file issues or notify
```
**Hybrid mode:** Ralph on the laptop monitors issues and lightweight tasks. GPU-heavy or resource-intensive work gets routed to DevBox or cloud VMs via the cross-machine coordination pattern.
```bash
# Start fleet watch (monitors HQ + all children)
squad watch --fleet
# Hybrid: laptop watches, DevBox executes GPU work
squad watch --fleet --route-gpu=devbox
```
### 5. Cross-Machine Coordination
Machines publish capability manifests so the fleet dispatcher routes work to the right hardware.
**Machine capabilities (`machine.json`):**
```json
{
"name": "devbox",
"capabilities": {
"gpu": true,
"gpu_model": "NVIDIA A100",
"memory_gb": 64,
"cpu_cores": 16
},
"accepts": ["gpu_workload", "heavy_build", "model_training"],
"poll_interval_seconds": 300
}
```
**Routing logic:** When a task requires GPU, the fleet dispatcher checks machine manifests and routes to a capable machine. Tasks flow through git (`.squad/cross-machine/tasks/`), results flow back the same way.
```
Laptop (no GPU) → creates task YAML → git push
→ DevBox Ralph pulls → validates → executes on GPU
→ writes result YAML → git push
→ Laptop Ralph reads result
```
See the `cross-machine-coordination` skill for full task/result YAML schemas, security model, and execution details.
## Anti-Patterns
- **Tight coupling between squads** — Don't depend on another squad's internal `.squad/` structure. Use issues and PRs as the communication protocol. Manifests are the public API.
- **Skipping HQ routing** — Don't have squads talk directly when there's an HQ. Route through HQ so there's a single audit trail and consistent triage.
- **Sharing full context dumps** — Send only what the target squad needs: a concise description, acceptance criteria, and a link back. Not your entire decision history.
- **Hardcoded repo paths** — Use `fleet.json` or manifest discovery. Repos move, orgs change, forks happen.
- **AI steps without guardrails** — In composable pipelines, always sandwich AI steps between deterministic validation (lint, test, schema check). Never chain AI → AI → AI without a checkpoint.
- **Ignoring the text interface** — If a step produces binary output or requires structured RPC, it breaks the Unix composition model. Convert to markdown/text at boundaries.
- **Circular delegation** — Track delegation chains. If Squad A delegates to B which delegates back to A, something is architecturally wrong. Escalate to HQ.
- **Fleet watch without rate limiting** — Polling N repos every 5 minutes can hit GitHub API limits. Use conditional requests (ETags) and back off on 403s.
## References
- Blog Part 8: "Pathfinder — When AI Squads Learn to Talk to Each Other"
- Skill: `cross-machine-coordination` — Full task/result YAML schemas, security model, execution isolation
- Skill: `agent-collaboration` — Single-repo collaboration patterns (decisions, cross-agent comms)
- File: `.squad/fleet.json` — Fleet registry (when using HQ pattern)
- File: `.squad/cross-machine/tasks/` — Cross-machine task queue