# Seat Continuity And Handover

Use when replacing a seat's occupant (rebuild/handover/swap), reasoning about...

- 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 seat-continuity-and-handover -g -a claude-code -y`
Codex: `npx skills add mvschwarz/openrig --skill seat-continuity-and-handover -g -a codex -y`
Cursor: `npx skills add mvschwarz/openrig --skill seat-continuity-and-handover -g -a cursor -y`
Gemini CLI: `npx skills add mvschwarz/openrig --skill seat-continuity-and-handover -g -a gemini-cli -y`

## Description

Use when replacing a seat's occupant (rebuild/handover/swap), reasoning about stable-seat-identity vs fluid-occupant-identity, choosing an old-occupant disposition (retire/advise/shadow), or recording provenance for an occupant change. Two independent outcomes (continuityOutcome + seatBindingOutcome) and the 5 failure modes that prevent silent dishonesty.

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

# Seat Continuity and Handover

A pair of primitive families that separate *who is sitting in a seat* from
*what the seat itself is*:

1. **Occupant-creation primitives**, `resume`, `fork`, `rebuild`, `fresh`, produce a candidate new occupant. Answer: "where did the new occupant come from?"
2. **Seat-binding operations**, handover binds a candidate occupant into the topology. Answer: "what happened to the stable seat identity?" Inspect the current CLI for executable operations; design vocabulary alone does not establish a command.

Core architectural decision: **stable seat identity, fluid occupant
identity, explicit provenance.** Do not encode successive occupants into live
seat names. Keep the stable address and record lineage separately.

## Use this when

- Replacing a seat's occupant via rebuild, fork, fresh, or seat-handover
- Choosing old-occupant disposition: retire / advise / shadow
- Reasoning about whether a seat's lineage is stable or has drifted
- Reading or writing the provenance record for a seat
- Designing or auditing topology stability across an occupant change

## Don't use this when

- The seat is freshly created (no occupant to replace), use `rig launch` / `rig expand` directly
- The intent is to change topology shape (add/remove seats), not replace an occupant, use topology-mutation primitives

## The two-outcome honesty model

Every seat-binding operation produces two **independent** outcomes:

```yaml
continuityOutcome: rebuilt | resumed | forked | fresh | failed
seatBindingOutcome: handed_over | partial | failed | unchanged
```

These can disagree honestly. Examples:

- `continuityOutcome: failed` + `seatBindingOutcome: unchanged`, new occupant didn't materialize; seat correctly retains old occupant.
- `continuityOutcome: rebuilt` + `seatBindingOutcome: failed`, candidate created OK; bind failed mid-flight; provenance records the gap.

The rest: https://github.com/mvschwarz/openrig/blob/HEAD/packages/daemon/assets/plugins/openrig-core/skills/seat-continuity-and-handover/SKILL.md