Loading
Use when reasoning about the rig lifecycle operations family (create / start / stop / resume / restore / snapshot / release / unclaim / destroy), reading or trusting `rig ps` / lifecycle projections a
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add mvschwarz/openrig --skill rig-lifecycle -a cursor -y
Use when reasoning about the rig lifecycle operations family (create / start / stop / resume / restore / snapshot / release / unclaim / destroy), reading or trusting `rig ps` / lifecycle projections after recovery, or designing proof for a lifecycle scenario. Covers the 4 failure modes (auto-restore creates partial rig; projections report healthier than reality; provider auth treated as impl work; resume succeeds for one runtime fails another) plus the restore-honesty rule (failed resume is FAILED loudly — no auto fresh fallback).
Use when reasoning about the rig lifecycle operations family (create / start / stop / resume / restore / snapshot / release / unclaim / destroy), reading or trusting `rig ps` / lifecycle projections after recovery, or designing proof for a lifecycle scenario. Covers the 4 failure modes (auto-restore creates partial rig; projections report healthier than reality; provider auth treated as impl work; resume succeeds for one runtime fails another) plus the restore-honesty rule (failed resume is FAILED loudly — no auto fresh fallback).
rig ps / lifecycle projections after recovery, or designing proof for a lifecycle scenario. Covers the 4 failure modes (auto-restore creates partial rig; projections report healthier than reality; provider auth treated as impl work; resume succeeds for one runtime fails another) plus the restore-honesty rule (failed resume is FAILED loudly — no auto fresh fallback).
metadata:
cli_surfaces_referenced:
- destroy
- down
- ps
- release
- restore
- restore-check
- resume
- snapshot
- unclaim
- up
openrig:
stage: factory-approved
sibling_skills:
- topology-mutation-and-seat-management
- seat-scaling-and-specialization
- cross-host-rig-commands
- sidecar-operator
- rig-bundles-and-shareable-artifacts
- specification-system
- extension-and-user-workspaceThe family of operations that create, start, stop, resume, restore, snapshot, release, unclaim, and destroy OpenRig-managed topologies. Includes the user story after reboot: "bring my work back without turning a clean recovery into a cleanup project."
If lifecycle is brittle, every higher-level primitive inherits that brittleness. Queue, workflow, seat continuity, cross-host operation, and RSI all assume that rigs and seats can be restored into known states.
rig up / down / restore / resume / snapshot / release / unclaim / destroyrig ps after a reboot or recovery and deciding what to trustresumed / rebuilt / fresh / failed / attention_required)openrig-user skill for CLI surfaceopenrig-operatoropenrig-architectrig ps or lifecycle projections report a healthier state than the runtime actually has. Projections are summaries; the runtime is truth. Don't trust projections silently.Failed resume is FAILED loudly. No automatic fresh fallback. Fresh
launch is explicit follow-up only. This is enforced architecturally
at the daemon level (per architecture.md §7 rule 15).
The locked restore-outcome vocabulary:
| Outcome | Meaning |
|---|---|
resumed | Native runtime resumed the same conversation |
rebuilt | New process assembled from artifacts (session_source: mode: rebuild) |
fresh | New process with no prior continuity |
failed | Restore attempted and failed; no automatic fallback |
attention_required | Recoverable blocker (provider auth refused, etc.); needs operator action |
n-a | Not applicable (terminal nodes, etc.) |
Codex auth-refusal returns attention_required (recoverable); Claude
looksLikeClaudeLoginPrompt returns failed/login_required (terminal).
Cross-runtime alignment is an open follow-up question.
Lifecycle proof should include real reboot or VM-reboot evidence, not only daemon-unit evidence. The minimum useful matrix covers:
| Scenario | What it proves |
|---|---|
| Clean start | Boot from spec into known state |
| Warm resume | rig down → rig up <name> resumes seats |
| Host reboot / tmux socket absence | Recovery from lost tmux connection |
| Provider auth loss | Codex/Claude auth refusal handled honestly |
| Partial boot / partial failure | Some seats up, some failed; honest reporting |
| Intentional operator recovery | Operator-initiated restore from snapshot |
Tier 1: in-process bedrock (daemon-unit evidence). Tier 2: real reboot or disposable Tart VM. Tier 1 alone is not lifecycle proof; it's bedrock.
Treat default policy as part of the primitive, not an afterthought. Lifecycle defaults that are too optimistic for the reliability level actually proven create silent harm:
auto-restore defaults that mask failure modesThe rail sequences restore truth into four rungs:
fully_restored is a Rung 3 execution rollupNaming discipline matters. "Fully restored" and "fully back" are different claims; don't conflate.
openrig-user skill — CLI surface for rig up / down / restore / etc.openrig-operator skill — operator-level discipline for OpenRig itselfseat-continuity-and-handover skill — sub-primitive: occupant-creation modes for restore (resume / rebuild / fresh / failed)session-source-fork skill — forked continuity outcome for fork-based restorepermission-and-capability-preflight skill — provider-auth blocker → escalation pathopenrig/docs/as-built/architecture/lifecycle-snapshot-restore.md (product reference doc) — daemon enforcement of restore-honesty rule