add-orchestrator

Add Orchestrator

ℹ️ First, set expectations: before anything else, print one short line with this skill's version and its most recent change — the top entry of metadata.changelog above — e.g. add-orchestrator vX.Y — recent: <summary>. Then proceed.

Turn any Trinity-compatible agent into a system-aware orchestrator: an agent that knows what other agents exist (deployed or just sitting in a GitHub repo), what each can do, and can route work to them, batch across them, or roll one out ephemerally, use it, and spin it back down.

🔍 Already installed? /add-orchestrator --check runs a read-only divergence report — per installed skill: upgrade available, back-port candidate (your copy is ahead of the bundle), or a local customization about to be clobbered — before you re-run and overwrite anything. See Check mode below.

Two modes — pick by whether the fleet already exists. Don't force a linear pipeline.

Mode A · Describe & route over an EXISTING fleet   (read-only — the common case)
  live Trinity and/or fleet/sources.yaml ──/discover-agents──▶ system-map.yaml (+ orchestration.md) ──/orchestrate──▶ work
  The map (facts) + orchestration.md (intent) ARE the read surface. No manifest, no deploy. Skip /compose-system.

Mode B · Provision a NEW system   (create agents that today are only catalog repos)
  author orchestration.md §5 ──/compose-system──▶ fleet/system.yaml (SystemManifest) ──deploy──▶ /orchestrate

Artifacts (four layers):
  fleet/sources.yaml       you curate — local paths + github:Org/repo (optional when discovering from live Trinity)
  fleet/system-map.yaml    FACTS (nodes) — descriptive, written by /discover-agents      (Mode A stops here)
  fleet/orchestration.md   NARRATIVE (edges + intent) — human prose + tool-refreshed blocks; imported into CLAUDE.md
  fleet/system.yaml        Trinity SystemManifest — prescriptive, written by /compose-system   (Mode B only)

Maintenance (keep the fleet + its narrative honest over time):
  /sync-fleet-to-head   non-destructively bring in-scope agents to their GitHub HEAD
  /profile-fleet        interview + introspect agents, reconcile reality, correct orchestration.md
  /fleet-reconcile      fold already-verified deltas into every doc surface — no new evidence, one gate

Drive (opt-in project-management layer — Q3 at install):
  /project-init         create/adopt a managed project (epic + workspace) per fleet/project-standard.md
  /project-steward      autonomous sweep: reconcile dispatches, dispatch next work to labeled owners,
                        escalate stalls, age the operator's open loops, write a daily digest —
                        never asks mid-run

Loop closure (standard §12) runs through the whole bundle. Silence is a failure mode, not an outcome, in both directions. Inbound: /orchestrate isn't done until the requester has actually been told the outcome — including when the run failed — and the steward's digest opens with what's now true, what's waiting on the operator, and what happens next unprompted. Outbound: work parked on somebody the fleet can't dispatch to — a client, a vendor, a colleague, an agent in another fleet — is labeled waiting-on:<actor>, aged in every digest under Your open loops, and handed to the operator with a drafted follow-up. The agent drafts; the human sends — nothing in this bundle contacts a third party on the operator's behalf.

Design invariant (do not violate): orchestration is agent-owned. Trinity supplies the substrate (shared folders, agent-to-agent permissions, MCP messaging, cron) but runs no central DAG engine. So the roll-out → work → tear-down lifecycle lives inside /orchestrate — stitched from existing MCP calls — never as a new platform primitive. The multi-agent definition aligns 1:1 with Trinity's SystemManifest (the same YAML deploy_system consumes); this skill does not invent a competing format.

Sibling layer — /add-pipeline: this skill is the inter-agent layer (route / fan out / lifecycle across a fleet); /add-pipeline is the intra-agent one (a population of items crawling through a staged DAG inside a single agent, advanced by that agent's own heartbeat). They compose, same invariant on both sides: /discover-agents surfaces each fleet agent's pipelines (pipelines: per map node, scanned from projects/*/pipeline.yaml), and /orchestrate routes pipeline-shaped work to the owning agent rather than re-sequencing its stages as a cross-agent chain. Conversely, when one pipeline's instances are really isolated tenants, the answer is one agent per tenant via this orchestrator — add-pipeline's "multi-instance, not multi-tenant" boundary points here.