Skip to main content
skill CX Codex

rig-lifecycle — Claude Code skill: what it does, how to install

Teaches the agent to reason about OpenRig lifecycle operations, verify post-reboot state in rig ps, and handle recovery without silent fresh fallbacks.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add mvschwarz/openrig --skill rig-lifecycle -a claude-code
Open on GitHub

What rig-lifecycle does

The skill establishes guardrails for OpenRig topology lifecycle commands: creation, startup, shutdown, snapshots, and destruction. It guides the model to doubt optimistic rig ps projections after reboots and highlights four common failure modes, such as treating lost provider credentials as code bugs or masking partial restores.

At its core sits the restore-honesty rule. When a resume operation fails, it must fail explicitly with a failed outcome instead of quietly spawning a clean environment. The agent evaluates states using a locked status vocabulary: resumed, rebuilt, fresh, failed, or attention_required.

Proof criteria require evidence from real machine reboots or disposable Tart VMs rather than daemon unit tests alone. Notably, Codex authentication loss yields an actionable attention_required state, while Claude login prompts are treated as terminal failed/login_required outcomes.

What it helps with

  • verify rig ps output against actual runtime state after host reboots
  • design test matrices for rig snapshot and restore flows
  • handle failed session resume attempts without silent fresh instance fallback
  • classify topology recovery outcomes using standard OpenRig status terms

Example prompts for the agent

  • Audit this rig ps output following a host restart and identify phantom healthy projections.
  • Design a lifecycle proof matrix covering provider authentication loss during rig resume.
  • Determine the restore outcome state when an occupant process gets rebuilt from saved artifacts.

How to install rig-lifecycle

1Skills CLI (Vercel)

npx skills add mvschwarz/openrig --skill rig-lifecycle -a claude-code

2Manually: put the files in place

~/.claude/skills/rig-lifecycle/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/rig-lifecycle/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about rig-lifecycle

How to install rig-lifecycle in Claude Code?

Run npx skills add mvschwarz/openrig --skill rig-lifecycle -a claude-code. The skill definition will be saved to ~/.claude/skills/rig-lifecycle/SKILL.md.

What does the rig-lifecycle skill do?

It guides AI assistants through OpenRig lifecycle commands like up, down, snapshot, and restore. It prevents the assistant from misinterpreting optimistic status reports or masking failed recoveries.

What is the restore-honesty rule?

Any failed resume attempt must halt loudly with an explicit failed state. The daemon architecture prohibits silent fallbacks to fresh launches, requiring deliberate operator action to start clean.

Source text

SKILL.md · Apache-2.0
---
name: rig-lifecycle
description: 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).
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-workspace
---

# Rig Lifecycle

The 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.

## Use this when

- Operating `rig up / down / restore / resume / snapshot / release / unclaim / destroy`
- Reading `rig ps` after a reboot or recovery and deciding what to trust
- Designing proof for a lifecycle scenario (clean start / warm resume / host reboot / provider auth loss / partial boot / operator recovery)
- Reasoning about restore-outcome semantics (`resumed` / `rebuilt` / `fresh` / `failed` / `attention_required`)
- Auditing whether a lifecycle proof is in-process bedrock vs requires real reboot evidence

## Don't use this when

- The operation is single-command and deterministic — use `openrig-user` skill for CLI surface
- The work is operator-level configuration of OpenRig itself — use `openrig-operator`
- The work is rig spec authoring — use `openrig-architect`

## Failure modes (4)

1. **Auto-restore creates a partially restored rig that must be cleaned up before real recovery.** Partial restore looks like recovery but isn't; cleanup-before-recovery becomes the actual workload.
2. **`rig 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.
3. **Provider auth is unavailable after reboot and the system treats that as implementation work** instead of a human/environment decision. Auth issues are environmental; route to human.
4. **Resume succeeds for one runtime/provider but fails for another scenario that was never tested.** Per-runtime parity assumptions break silently; matrix proof catches them.

## Restore-honesty rule (load-bearing)

**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.

## Proof standard

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.

## Default policy is part of the primitive

**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 modes
- Implicit fresh-fallback that hides resume failure
- Permissive verification that doesn't distinguish honest success from "appeared to work"

## Total-Host Restore Product Rail v2

The rail sequences restore truth into **four rungs**:

- `fully_restored` is a **Rung 3 execution rollup**
- "fully back" is **reserved for Rung 4 only**

Naming discipline matters. "Fully restored" and "fully back" are
different claims; don't conflate.

## See also

- `openrig-user` skill — CLI surface for `rig up / down / restore / etc.`
- `openrig-operator` skill — operator-level discipline for OpenRig itself
- `seat-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 restore
- `permission-and-capability-preflight` skill — provider-auth blocker → escalation path
- `openrig/docs/as-built/architecture/lifecycle-snapshot-restore.md` (product reference doc) — daemon enforcement of restore-honesty rule

© mvschwarz · Apache-2.0 · mvschwarz/openrig

Similar skills

All skills for Agent setup: memory, context, orchestration →

From the same set49

watchdog A skill for configuring rig watchdog policies: it picks the right intervention when an agent goes idle, drifts, or needs a checkpoint. CX Codex +1 ★ 8,227repo stars topology-mutation-and-seat-management Guides agents in altering live OpenRig topologies on the fly: expanding capacity, removing seats, binding tmux sessions, and preventing stale edges. CX Codex +1 ★ 8,227repo stars specification-system Guides the design and review of OpenRig rig, agent, and workflow specs. Use it to catch portability problems and check that a declared setup can run. CX Codex +1 ★ 8,227repo stars session-source-fork A skill for authoring rig specs: it starts a new managed seat from a prior Claude or Claude conversation without claiming the old seat continued. CX Codex +1 ★ 8,227repo stars rig-bundles-and-shareable-artifacts This skill covers creating, inspecting, and installing OpenRig bundles that package a rig topology with its workflow. Use it when preparing a proven setup for reuse in another environment. CX Codex +1 ★ 8,227repo stars openrig-upgrade Walks an agent through an OpenRig CLI and daemon upgrade one step at a time: inspect, mutate, observe. Useful when live seats matter. CX Codex +1 ★ 8,227repo stars openrig-software-factory This skill organizes OpenRig agent teams in software repositories. It sets up review handoffs and execution workflows between Claude Code and Codex seats. CX Codex +1 ★ 8,227repo stars openrig-skills This skill helps an agent in OpenRig find the right context for a handover, debugging, or recovery task. It also shows how to locate and load other skills with rig. CX Codex +1 ★ 8,227repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor