openrig-cmux

$npx mdskill add mvschwarz/openrig/openrig-cmux

Opens OpenRig fleet terminals into cmux for live agent tiles.

  • Turns rigs, pods, missions, or views into cmux terminal tiles.
  • Depends on OpenRig's rig terminal command with cmux provider.
  • Uses same OpenRig view semantics as herdr but best-effort.
  • Renders agent tiles into cmux instead of proof-gated herdr.

SKILL.md

.github/skills/openrig-cmuxView on GitHub ↗
---
name: openrig-cmux
description: >
  Use when opening OpenRig fleet terminals into cmux — turning a rig, pod, mission, slice, or saved
  view into live agent tiles via `rig terminal --provider cmux`, or driving cmux on an agent's
  request. Same OpenRig view semantics as openrig-herdr (the verbs, honest-partial/degrade, read-only
  cross-rig, scroll/copy, same-size-only duplicates); cmux is the **best-effort** provider (herdr is
  the default and the proof-gated one). Prefer openrig-herdr unless cmux is specifically wanted.
metadata:
  openrig:
    stage: candidate
    distribution_scope: product-bound
    source_evidence: |
      cmux is OpenRig's shipped terminal provider generalized onto `rig terminal <provider>` —
      best-effort, not proof-gated. Authored clean-room.
    transfer_test: pending
    sibling_skills:
      - openrig-herdr
      - openrig-user
---

# openrig-cmux

cmux is a **provider** for OpenRig views — the same `rig terminal` surface as herdr, rendering the
tiles into cmux instead. It is the provider OpenRig already shipped (the existing "Launch in cmux"
affordance generalizes onto `rig terminal <provider>`), kept working. The OpenRig-semantic half is
identical to openrig-herdr: OpenRig decides **which** agents form a view; the provider renders the
pixels. **Read openrig-herdr first for the full model** — this skill only calls out what differs for
cmux.

## Provider status — cmux is best-effort

- **herdr is the default and the proof-gated provider**; **cmux is best-effort** — it ships on the
  same `rig terminal <provider>` + web-launcher neighborhood, but a cmux miss is not a slice failure.
  Reach for cmux when it is specifically wanted; otherwise default to herdr (`rig terminal open <view>`
  with no `--provider`).
- Views are **provider-agnostic**: the same view + the same agents + the same semantics carry across
  herdr and cmux. A saved view opens in either.

## The surface (same three verbs, `--provider cmux`)

```bash
rig terminal open <view> --provider cmux [--json]   # open a view into cmux (herdr is the no-flag default)
rig terminal views [--json]                          # the same view library, provider-agnostic
rig terminal status --provider cmux [--json]         # cmux liveness / health
```

`<view>` resolves exactly as with herdr: a **rig name** · **`pod:<rig>/<podNamespace>`** ·
**`mission:<id>`** · **`slice:<id>`** (derived live) · a **saved-view name**.

## What carries over unchanged from openrig-herdr

All of these behave identically — see openrig-herdr for the detail:

- **Honest-partial / honest-degrade** — opened / absent / degraded, each named; partial opens exit 0,
  zero-pane exits non-zero; an http-registered host's agents degrade with the reason ("host `<id>` is
  http-registered; tiles need ssh"), never silently dropped.
- **Read-only policy** — a rig or `pod:` view is interactive; `mission:` / `slice:` views are
  read-only by construction; a saved view is per-member (`readOnly`). A read-only pane is
  `tmux attach -r` (client `readonly=1`, keystrokes physically cannot reach the agent). See openrig-herdr.
- **Safety rails (the fleet-safety rail)** — a tile is a *view* (nested `tmux attach`) of a
  daemon-owned session; never move/join/kill/re-parent a daemon-owned pane; closing a tile detaches
  one client and leaves the session untouched; never live-flip tmux options on a running seat in
  production (prove it in an isolated environment first).
- **Scroll + copy out of the box** — the daemon's terminal defaults (per-session scroll at launch +
  the server's clipboard defaults); running seats pick up wheel-scroll at their next relaunch.
- **Limits** — tile chrome v1 = a plain label; same-size panes for duplicate/multi-view membership
  (the different-size resize mismatch is an inherent tmux multi-client limit, documented not fixed).

## cmux-specific notes

- **Open-or-focus per agent** — cmux's shipped integration opens a node or focuses it if already open;
  expect focus (not a duplicate) when a seat is already tiled in cmux.
- **The shipped "Launch in cmux" affordance is preserved** (byte-compatible) and generalizes into the
  provider + view picker; opening cmux from the web launcher still works.
- **No AGPL arm's-length concern** — unlike herdr, cmux is OpenRig's shipped provider integration; the
  clean-room/never-embed rail that applies to herdr is not a cmux constraint. (This skill itself is
  still authored clean-room.)

## Saved views — provider-agnostic

Saved views are **hand-authored** in `terminal-views.yaml` (v1 has no save/write verb) and are
**provider-agnostic** — see **openrig-herdr** for the exact schema, the store facts (atomic tmp+rename,
byte-stable, at the OpenRig home root), and the derived-views-never-persisted rule. Reopen any saved
view in cmux with `rig terminal open <id> --provider cmux`. Derived views (a rig, `pod:<rig>/<pod>`,
`mission:<id>`, `slice:<id>`) are computed live and never written to the file.

More from mvschwarz/openrig

SkillDescription
agent-startup-and-context-ingestionUse when designing or auditing how an agent becomes useful after launch — AGENTS.md overlays, role files, skills, rig specs, workflow specs, startup checklists, refocus messages, "rig context" surface. Covers the 4 failure modes that make startup context fail (old rig spec misses current operating mode; current agents never told about new guidance; startup file as dumping ground; orchestrator transmits implementation without preserving product intent).
backlog-captureQuickly capture product ideas, feature requests, or insights from meetings and conversations. Rapid documentation with smart categorization and deduplication.
claude-compaction-restoreUse when a Claude Code session has just compacted, is about to compact, reached context limit, resumed after /compact, or needs to rebuild its working mental model from Claude JSONL transcripts and touched files.
context-builderGather and distill context from meetings, competitors, regulatory sources, and internal discussions. Produces background.md for a feature and updates shared context docs when new knowledge is discovered.
development-teamHow the development pod coordinates implementation, QA, and design without skipping gates.
forming-an-openrig-mental-model|
mission-slice-sopUse when working a mission or slice — the full SDLC flow (intent → mini-requirements + proof contract → mockups → plan-lock → build → QA visual compare → `rig proof` drops → proof-lock) plus how to track, prove, hand off, and carry state across agents and compaction via the canonical files (PROGRESS.md / PROOF.md / MISSION_NOTES.md / MISSION_BRIEF.md / README.md / IMPLEMENTATION-PRD.md). Covers the convention sections the Living Notes UI projects, the two locks, the three role contracts, per-file WHO/WHEN/HOW rules, the four-legs lifecycle, hot-potato queue handoffs, the moment-of-truth checklist, the deterministic `rig scope audit` backstop, and the ghost-text capture gotcha.
openrig-architectUse when designing multi-agent topologies that run ON OpenRig — authoring RigSpec and AgentSpec files for new rigs, creating agent startup content (guidance / skills / culture), or diagnosing why a launched rig's agents aren't behaving as intended. NOT for changing OpenRig itself (work in the openrig product repo); NOT for ordinary CLI operation of an existing rig (use openrig-user). Covers the full authoring lifecycle from user intent to validated, launchable rig.
openrig-herdr>
openrig-installerUse when installing or upgrading OpenRig on a host, especially the V0.3.1 upgrade flow which includes the substrate-kernel → daemon-managed-kernel migration ceremony. Covers npm install, rig setup, rig daemon start (auto-boots kernel), and the canonical verification commands. NOT for ordinary kernel operation post-install — use openrig-operator skill for that.