Topology Mutation And Seat Management
Use when changing a rig while it is alive, `rig grow` / `rig expand` / `rig shrink` /...
Install
npx skills add mvschwarz/openrig --skill topology-mutation-and-seat-management -g -a claude-code -y- Repository
- mvschwarz/openrig8.5k
- Category
- Business
- Updated
- 3d ago
- License
- Apache-2.0
- Context cost
- Lightabout 1,495 tokens
- Runs scripts
- No, instructions only
What it does
Use when changing a rig while it is alive, `rig grow` / `rig expand` / `rig shrink` / `rig launch` / `rig remove` / `rig discover` / `rig bind` / `rig adopt` / `rig attach`. Covers the 4 failure modes (newly created seat lacks queue/startup/role; edges and permissions not updated; adopt/bind succeeds at tmux but not OpenRig identity; shrink/remove leaves stale topology references) and the rule that mutation must work while the rig is active, not just in clean fixtures.
Topology Mutation and Seat Management
The ability to change a rig while it is alive: expand, shrink, launch, remove, discover, bind, adopt, and attach seats or sessions. Seat management includes the stable identifiers, edges, roles, and startup context that make those mutations coherent.
OpenRig should be easy to reach for. A user should be able to add capacity, retire capacity, adopt an existing session, or attach a terminal without rebuilding the whole topology. If mutation is rarely tested, users avoid it and the product collapses back into static launch scripts.
Use this when
- Adding seats to a running rig (
rig grow <rig-id> <member...>for the simple case, a fragment withrig expandorrig addotherwise; see below) - Removing capacity (
rig shrink/rig remove) - Launching/relaunching a node in a running rig (
rig launch) - Binding a discovered session into an existing logical node (
rig bind) - Adopting a topology + binding live sessions (
rig adopt) - Attaching a shell or agent into a rig node (
rig attach --self)
Adding seats: rig grow first, a fragment when you need more
rig grow <rig-id> <member...> adds one or more seats to a running rig without
writing YAML. Each seat gets the default agent spec and its default profile.
Check rig grow --help on your installed version; at the time of writing:
--pod <pod>: the target pod; inferred when the rig has one pod--new-pod <pod>: create a new pod for the seats (not together with--pod)--runtime <runtime>: one runtime for every named seat (defaultclaude-code)--cwd <path>: one working directory for every named seat (default: the current directory)--json: output for agents
