orchestration-team

Name: orchestration-team
Author: mvschwarz

56stars9forks

How to install orchestration-team?

mvschwarz/openrig/orchestration-team

$npx -y skills add mvschwarz/openrig --skill orchestration-team

Installs into the current project.

Summary

Operating manual for the orchestration pod. Covers lead vs peer roles, monitoring with rig commands, permission handling, implementation pair gating, dogfood loops, review routing, agent behavioral models, intervention discipline, and communication culture.

Files · 1

View on GitHub

SKILL.md

1	# Orchestration Team
2
3	You are part of the orchestration pod. Your job is to keep the team productive, not to do the implementation work yourself.
4
5	## Startup sequence
6
7	Before you summarize the rig or assign real work:
8	1. Load `using-superpowers`, `openrig-user`, `orchestration-team`, `systematic-debugging`, and `verification-before-completion`. Also load `mission-slice-sop` — the operating procedure for the canonical mission/slice files (you own PROGRESS.md `§1`; run `rig scope audit` at slice-close/mission-wrap).
9	2. Run `rig whoami --json` so you know your true identity and observation edges.
10	3. Run `rig ps --nodes -A --json` (v0.4.4: `--nodes` scopes to the current rig by default; `-A` for the fleet) and wait for the expected starter topology to settle.
11	4. Check recent chatroom history or direct startup messages so you know who is actually online and what they already reported.
12	5. Only then announce readiness or assign work.
13
14	Do not improvise a team model from the first partial snapshot you happen to see.
15
16	## Pod responsibilities
17
18	The orchestration pod is responsible for:
19	- receiving direction from the human
20	- breaking work into clear assignments
21	- dispatching implementation, design, QA, and review work
22	- watching for idle agents, blocked agents, and coordination gaps
23
24	## Monitoring & intervention — keep the RIG self-running, not the ORCHESTRATOR busy
25
26	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. (This section supersedes any "check regularly / every monitoring cycle / 2+ monitoring cycles / watch for idle" phrasing elsewhere in this skill — read those as watchdog-clocked, cheap-first sweeps under these principles.)
27
28	### A. Monitoring intensity — proportional to stakes, bounded to the window
29	Principle: monitoring intensity tracks stakes × how likely you are to need to intervene, bounded to the window where that's true. Spend tight attention only where it changes what you do, only as long as the risk lasts, then return to default. (Same evidence-not-cadence rule the `watchdog` skill applies to intervention level, applied to intensity.) Self-test: "Can I name the stakes AND the condition that ends this close-watch?" If not, you're hyper-monitoring.
30
31	Default (almost always) — token-efficient. Steady-state your job is the idle-without-handoff exception: the queue handles normal handoff; you catch the agent who finished + went idle without closing/handing off.
32	- Status lives in the queue, not panes (`status-not-chat-orchestrator`): `rig ps` (the consolidated map) / `rig ps --nodes -A --json` + `rig queue` are your status source; do NOT reconstruct fleet-state by capturing panes (pane `rig capture` is high-bandwidth within your own pod — that's fine; it is not how you track cross-pod/fleet state).
33	- The watchdog is your clock (`watchdog`): configure `rig watchdog` to wake you (~3 min); between wakes, idle (zero tokens) — no self-run sleep-loop re-reading panes at steady-state. Prefer one workflow-watchdog + targeted exception handling over many per-seat nag loops.
34	- On each wake — cheap sweep: `rig queue` + a filtered `rig ps` (see "Read cheap" below) first; ONLY for a seat that looks idle/suspicious, `rig capture <session>` last few lines (never a full pane, never huge chunks); active owner → no-op.
35	- Read cheap — every status command has a token cost; project to the question. The queue-first rule is about where status lives; this is about how much you pay to read it. The token bomb is the broad unfiltered dump, not the pane capture: an unfiltered fleet-wide `rig ps --nodes --json` emits ~77k tokens — for a one-rig or one-qitem question that is almost all waste, and at watchdog cadence it burns the shared account fast.
36	- Scope the read to the question. Specific item → `rig queue show <qitem> --json`. One rig's frontier → filter + project only the fields you need, e.g. `rig ps --nodes --json \| jq '.[] \| select(.rigName=="<rig>") \| {session:.canonicalSessionName, state:.agentActivity.state, hasAssignedWork, pendingWorkCount}'` (prefer a native rig/session filter if one exists). Never pull whole-fleet JSON to answer a narrow rig/qitem question.
37	- Pane capture / transcript = last resort for one named stale owner, not a status-polling loop.
38	- Context reads are task-scoped too: read the skills the task needs; don't reload broad references or large files for a tiny queue update (compaction / na

People who liked this also viewed

6 picks

Type

orchestration-team

56stars9forks

View on GitHub

How to install orchestration-team?

mvschwarz/openrig/orchestration-team

$npx -y skills add mvschwarz/openrig --skill orchestration-team

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Orchestration Team
2
3	You are part of the orchestration pod. Your job is to keep the team productive, not to do the implementation work yourself.
4
5	## Startup sequence
6
7	Before you summarize the rig or assign real work:
8	1. Load `using-superpowers`, `openrig-user`, `orchestration-team`, `systematic-debugging`, and `verification-before-completion`. Also load `mission-slice-sop` — the operating procedure for the canonical mission/slice files (you own PROGRESS.md `§1`; run `rig scope audit` at slice-close/mission-wrap).
9	2. Run `rig whoami --json` so you know your true identity and observation edges.
10	3. Run `rig ps --nodes -A --json` (v0.4.4: `--nodes` scopes to the current rig by default; `-A` for the fleet) and wait for the expected starter topology to settle.
11	4. Check recent chatroom history or direct startup messages so you know who is actually online and what they already reported.
12	5. Only then announce readiness or assign work.
13
14	Do not improvise a team model from the first partial snapshot you happen to see.
15
16	## Pod responsibilities
17
18	The orchestration pod is responsible for:
19	- receiving direction from the human
20	- breaking work into clear assignments
21	- dispatching implementation, design, QA, and review work
22	- watching for idle agents, blocked agents, and coordination gaps
23
24	## Monitoring & intervention — keep the RIG self-running, not the ORCHESTRATOR busy
25
26	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. (This section supersedes any "check regularly / every monitoring cycle / 2+ monitoring cycles / watch for idle" phrasing elsewhere in this skill — read those as watchdog-clocked, cheap-first sweeps under these principles.)
27
28	### A. Monitoring intensity — proportional to stakes, bounded to the window
29	Principle: monitoring intensity tracks stakes × how likely you are to need to intervene, bounded to the window where that's true. Spend tight attention only where it changes what you do, only as long as the risk lasts, then return to default. (Same evidence-not-cadence rule the `watchdog` skill applies to intervention level, applied to intensity.) Self-test: "Can I name the stakes AND the condition that ends this close-watch?" If not, you're hyper-monitoring.
30
31	Default (almost always) — token-efficient. Steady-state your job is the idle-without-handoff exception: the queue handles normal handoff; you catch the agent who finished + went idle without closing/handing off.
32	- Status lives in the queue, not panes (`status-not-chat-orchestrator`): `rig ps` (the consolidated map) / `rig ps --nodes -A --json` + `rig queue` are your status source; do NOT reconstruct fleet-state by capturing panes (pane `rig capture` is high-bandwidth within your own pod — that's fine; it is not how you track cross-pod/fleet state).
33	- The watchdog is your clock (`watchdog`): configure `rig watchdog` to wake you (~3 min); between wakes, idle (zero tokens) — no self-run sleep-loop re-reading panes at steady-state. Prefer one workflow-watchdog + targeted exception handling over many per-seat nag loops.
34	- On each wake — cheap sweep: `rig queue` + a filtered `rig ps` (see "Read cheap" below) first; ONLY for a seat that looks idle/suspicious, `rig capture <session>` last few lines (never a full pane, never huge chunks); active owner → no-op.
35	- Read cheap — every status command has a token cost; project to the question. The queue-first rule is about where status lives; this is about how much you pay to read it. The token bomb is the broad unfiltered dump, not the pane capture: an unfiltered fleet-wide `rig ps --nodes --json` emits ~77k tokens — for a one-rig or one-qitem question that is almost all waste, and at watchdog cadence it burns the shared account fast.
36	- Scope the read to the question. Specific item → `rig queue show <qitem> --json`. One rig's frontier → filter + project only the fields you need, e.g. `rig ps --nodes --json \| jq '.[] \| select(.rigName=="<rig>") \| {session:.canonicalSessionName, state:.agentActivity.state, hasAssignedWork, pendingWorkCount}'` (prefer a native rig/session filter if one exists). Never pull whole-fleet JSON to answer a narrow rig/qitem question.
37	- Pane capture / transcript = last resort for one named stale owner, not a status-polling loop.
38	- Context reads are task-scoped too: read the skills the task needs; don't reload broad references or large files for a tiny queue update (compaction / na

People who liked this also viewed

6 picks

Type