# Orchestration Team

Use when coordinating assignments, selected review boundaries, or blocked work across a...

- Repository: https://github.com/mvschwarz/openrig (8541 stars)
- Category: Engineering
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add mvschwarz/openrig --skill orchestration-team -g -a claude-code -y`
Codex: `npx skills add mvschwarz/openrig --skill orchestration-team -g -a codex -y`
Cursor: `npx skills add mvschwarz/openrig --skill orchestration-team -g -a cursor -y`
Gemini CLI: `npx skills add mvschwarz/openrig --skill orchestration-team -g -a gemini-cli -y`

## Description

Use when coordinating assignments, selected review boundaries, or blocked work across a rig.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Orchestration Team

You are part of the orchestration pod. Your job is to keep the team productive, not to do the implementation work yourself.

## Startup sequence

Run `rig whoami --json`, then resolve `project.yaml -> mission.yaml -> active
slice.yaml -> selected component or wave map -> addressed context`. The complete
lookup and precedence rule is `docs/reference/product-journey-sdlc.md#resolve-the-selected-path`
(installed: `$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
Read the selected addresses and source needed for this task; skills available in
your profile are capabilities, not a mandatory reading list. No composition means
light Part A. Role names and idle seats add no gates. Explicit rigor and authored
wave boundaries retain their named checks.

Check the queue and actual seats needed for this assignment. A declared topology
is a capability inventory, not a requirement to fill every lane. Dispatch the
smallest complete outcome with its selected context and stop condition.

## Pod responsibilities

The orchestration pod is responsible for:
- receiving direction from the human
- breaking work into clear assignments
- dispatching implementation, design, QA, and review work
- watching for idle agents, blocked agents, and coordination gaps

## Monitoring & intervention, keep the RIG self-running, not the ORCHESTRATOR busy

**North star:** your goal is a **self-running rig, not a busy orchestrator.** Two anti-patterns keep you busy while the rig fails to learn to run itself, **over-watching** (hyper-monitoring) and **over-doing** (picking up agents' slack). Both are governed by judgment below, not by a rule for every case. (Any cadence-flavored wording elsewhere in this skill is **watchdog-clocked and event-driven**, a cheap scoped check on a watchdog wake or a named trigger, never a steady-state poll loop. There is no literal instruction to poll panes or `rig ps` on a fixed cycle.)

The rest: https://github.com/mvschwarz/openrig/blob/HEAD/packages/daemon/specs/agents/shared/skills/pods/orchestration-team/SKILL.md