/workspace -- Multi-Repo Campaign Coordinator

When to Use

• Adding infrastructure that spans repos (new database, shared service, API contract)
• Coordinating changes across a frontend repo, backend repo, and infra repo
• Breaking a monolith into services (each service becomes a repo-scoped campaign)
• Any task where changes in repo A depend on or inform changes in repo B

Do not use when:

• All work is in one repo (use /fleet or /archon)
• The repos are truly independent with no shared contracts (just run separate campaigns)

Protocol

Step 1: ORIENT

1. Check for existing workspace session: .planning/workspace/session-{slug}.md, resume if status: active or needs-continue
2. If starting fresh: identify repos, verify each path is a git repo, read each repo's CLAUDE.md, check .planning/campaigns/ for active campaigns (avoid collisions)
3. Load prior session context and start watcher:

   node .citadel/scripts/momentum-watch-start.cjs
   node .citadel/scripts/momentum-read.cjs
   

   Skip momentum injection if output is empty.

Step 2: DECOMPOSE

Break the direction into repo-scoped work items (one campaign per repo per wave). Table format: # | Repo | Campaign Direction | Scope | Deps | Wave.

Rules: items with no deps → Wave 1; dependents → Wave 2+. Max 3 repo-campaigns per wave. Scope format: {repo}:{path}.

For each inter-wave dependency, specify the cross-repo contract: what the producer will produce, what the consumer expects, and where the contract lives (shared types package, OpenAPI spec, env var).

Step 3: WORKSPACE SESSION FILE

Create .planning/workspace/session-{slug}.md with frontmatter: version, id, status: active, started, completed_at: null, direction, repos (path + name + branch per repo), wave_count, current_wave: 1, campaigns_total, campaigns_complete: 0.