Imported from jrgrant/fedora-cosmic-atomic-dx (.copilot/plugins/ai-literacy-superpowers/ai-literacy-superpowers/skills/cross-repo-orchestration/SKILL.md). Install upstream with npx skills add jrgrant/fedora-cosmic-atomic-dx --skill cross-repo-orchestration. Copyright stays with the author.

Cross-Repo Orchestration

When a project spans multiple repositories, the practices that work within a single repo — specification-driven development, harness enforcement, compound learning — must extend across repo boundaries. This skill teaches two patterns for cross-repo coordination, each suited to a different maturity level.

This skill does not cover single-repo agent orchestration (see the orchestrator agent), CI/CD pipeline design, or monorepo tooling.

For worked examples and the sync workflow, consult references/sync-patterns.md.

When to Use

Pattern 1: Git-Mediated Coordination (Level 4)

A single agent (or human) applies changes from an upstream repo to one or more downstream repos using git's standard workflow.

The Workflow

1. Identify what changed upstream — review the changelog, diff, or commit log to determine which exported artefacts were modified
2. For each downstream repo: a. Check out main and pull latest b. Create a feature branch c. Copy or apply the upstream changes d. Update the downstream README if counts or descriptions changed e. Run lint and verify f. Commit with a message referencing the upstream change g. Push and create a PR h. Watch CI checks i. Merge when green j. Clean up the branch

What Gets Synced

Not everything should flow downstream. Define clear boundaries:

Declaring Exports

Document what the upstream repo exports in its README or a dedicated manifest section. At minimum, state:

• Which directories contain reusable artefacts
• What the downstream repos are
• What triggers a sync (e.g. "after any PR that modifies skills/")

Anti-Patterns

Pattern 2: Specification-Mediated Orchestration (Level 5)

At organisational scale, git-mediated sync becomes unwieldy. Repos declare their dependencies through specification manifests, and a platform orchestrator resolves and propagates changes.

Specification Manifests

Each repo declares what it exports and imports:

# .repo-manifest.yml (sketch — not yet a formal standard)
name: ai-literacy-superpowers
version: 0.1.0

exports:
  skills:
    - literate-programming
    - cupid-code-review
    - harness-engineering
    - convention-extraction
    - cross-repo-orchestration
  agents:
    - orchestrator
    - code-reviewer
    - integration-agent
  hooks:
    - constraint-gate
    - drift-check
    - snapshot-staleness

imports: []  # This is a root/platform repo — it imports nothing

A downstream repo declares what it consumes:

name: ai-literacy-exemplar
version: 0.1.0

exports:
  agents:
    - go-implementer  # project-specific, not imported

imports:
  - source: ai-literacy-superpowers
    version: ">=0.1.0"
    artefacts:
      - skills/*
      - hooks/*

Platform Harness Propagation

When the platform repo changes a harness policy (e.g. raises the mutation testing threshold), downstream repos that import that policy inherit the change through their manifest contract. The platform orchestrator:

1. Reads all downstream manifests
2. Identifies which repos consume the changed artefact
3. Opens sync PRs in each affected repo
4. Reports the sync status to the portfolio dashboard

Portfolio-Level Health

Health snapshots aggregate across the portfolio:

Portfolio Health — 2026-04-01

Repos: 12
At L3+: 9 (75%)
Below threshold: 3 (api-gateway, legacy-auth, billing-service)
Enforcement average: 84%
Mutation score average: 76%
Repos with stale snapshots: 1 (legacy-auth, 45 days)

This extends the single-repo harness observability pattern to organisational scale.

Choosing the Right Pattern

Start with git-mediated. Graduate to specification-mediated when the portfolio grows beyond what a single agent can manage.