OpenRig is a software harness that coordinates Claude Code and Codex coding agents as one system, with agent teams defined in YAML and launched together. It is for organizing persistent teams of coding agents that can delegate work to specialists and return results or decisions. The catalogue lists 53 skills and one plugin as add-ons for OpenRig.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add mvschwarz/openrig --skill retiring-and-inheriting-a-seatgit clone --depth 1 https://github.com/mvschwarz/openrigWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/mvschwarz/openrig/retiring-and-inheriting-a-seat)<a href="https://agentmods.dev/skills/mvschwarz/openrig/retiring-and-inheriting-a-seat"><img src="https://agentmods.dev/badge/skills/mvschwarz/openrig/retiring-and-inheriting-a-seat/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/mvschwarz/openrig/retiring-and-inheriting-a-seat"><img src="https://agentmods.dev/badge/skills/mvschwarz/openrig/retiring-and-inheriting-a-seat.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00145 | $0.03238 |
| Opus 5.5 | $0.00058 | $0.01295 |
| Sonnet 5.5 | $0.00029 | $0.00648 |
| Haiku 4.5 | $0.00015 | $0.00324 |
Grade A, and why
retiring-and-inheriting-a-seat scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 224 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Retiring and Inheriting a Seat
A planned seat transition. A long-lived seat accumulates context; as it nears the window's edge, don't wait for compaction to degrade you into a cold-started agent — retire deliberately and hand the seat to a fresh successor primed from a packet plus the seat's accumulated lineage. The seat address is stable; its occupants are a lineage. Keep the transition and its authority explicit.
Use this when
- You are a sitting agent near your context threshold (~85%) with a planned transition (or a deliberate role change), and want the successor to start clean.
- You are priming a fresh successor into an existing seat.
- You are recording a tenure in the seat's lineage ledger / writing your tombstone.
- You are inheriting a seat and need the do-not-over-inherit framing.
- You want to consult the agent who sat in this seat before you.
Don't use this when
- Unplanned compaction or a crash already happened — that is the backstop path:
session-compaction-and-restore/claude-compaction-restore. - You need the seat-binding primitive mechanics (rebuild/fork/fresh, the two-outcome
honesty model, the provenance schema) —
seat-continuity-and-handover. - The seat is fresh with no occupant to retire —
rig launch/agent-starters.
Why planned handover beats riding compaction
Compaction is the crash-class backstop (it stays that). A planned handover is deliberate: you author the packet with a clear head before degradation sets in, the successor starts on a clean context, and the transition is auditable. Reach for this at a threshold you can see coming; fall back to compaction only when a transition wasn't planned.
The handover sequence
- Trigger — the selected continuity threshold or a deliberate role transition. Use the configured policy and named transition owner; a context estimate alone does not authorize a cutover.
- Author the handover packet, deliberately — a composed context pack carrying current
work + next owner, the seat's durable pointers, constraints and authority boundaries, and
the accumulated lineage wisdom ("those before you learned X"). This IS a restore packet
in the
session-compaction-and-restore16-field contract — reuse that contract, don't reinvent it. Compose it withrig context compose(see openrig-user → "Context packs and paced delivery"). Enumerate the seat's standing duties as first-class packet content: what recurs, at what cadence, on which surface, and who will hold it after cutover. Carry each duty both in this packet and in durable seat state, because recurring duties are the content most often lost at a generation boundary while urgent one-off work carries cleanly. Write the seat's recap too: runrig context recap-write --rig <rig> --seat <seat> --file <draft>alongside updatingLEARNED.md. ArebuildreadsRECAP.mdbefore anything else. The format the store checks is inseat-continuity-and-handover, "Write the seat's recap before a handover". - Prime the fresh successor —
rig walkthe packet into the seat (paced delivery lets the successor absorb it in order), or launch-with-packet. The successor reads it as inheritance, not identity. The packet's first-read line MUST point the successor atorienting-to-an-inherited-seat— its world model of what a handover is. Carry that pointer in the durable packet artifact itself; never inject it as a runtime prompt keyed to the seat name (that runtime mechanism is the ghost-prompt class the orientation skill teaches successors to refuse). Artifact-carried survives the swap for free and needs no enabled gate. - Assess before cutover. If an apprenticeship or warm handoff is selected, use that staged window for questions and domain work before the owner decides. The incumbent retains authority until the owner-worded cutover; do not retire it merely to free a name while waiting for that decision.
- Preserve the physical seat at cutover — follow the portable SOP linked from
seat-continuity-and-handover. Keep the canonical tmux session, window and pane; resume the exact accepted successor history there and reconcile binding, environment, queue identity and attached clients. Preserve the incumbent's exact token as a cold-advisor handle when that is the selected disposition. Renaming tmux sessions is a repair fallback, not the default sequence. - Write the lineage-ledger row and tombstone (below). Record the actual outcomes and transfer each standing duty explicitly. Complete the successor's post-cutover self-check before unfreezing authority.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago Changed · +3 lines c03449dd9e9b
- 19d ago Changed · +3 lines 2d22804b24fa
- 1mo ago Changed · -14 lines ebe58e4db60e
- 1mo ago Changed 5b26972dbc0e
- 1mo ago First seen · 232 lines · 145 tokens per session scan A 8f20d6ef51cf
retiring-and-inheriting-a-seat is a skill published in the GitHub repository mvschwarz/openrig (8,228 stars, last pushed today), licensed Apache-2.0. It adds 145 tokens to every session and 3,238 once invoked, about $0.0006 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
handoff
Write a compact, decision-ready handoff so the next session (or the user) can continue without reconstructing the current one. Use when the session is ending, context is running low, the user asks for a handoff / 'pass the baton' / 'hand off', or a long-running operation needs a durable state checkpoint.
forget
Help the user remove a stored fact using Codewhale's Context Lens when they ask to forget or delete a memory.
semantix
Install and use the semantix memory kernel as a middleware in your agent: extract user preferences / workflows / experience from past sessions, retrieve and inject them on demand. One binary + your agent's own tools.
durable-session-state
Persist plans, scope decisions, evidence, and reviewer/critic verdicts to durable files during long or multi-phase tasks so work survives context compaction, session resumes, and handoffs. Use for swarm-mode tasks, before context grows large, when recording approval gates, and when resuming after compaction or a…
continuous-learning
Use when a mistake, correction, or surprise taught the workspace something that must stick — a retro or postmortem, the same agent error corrected twice, a resolved bug's root cause, scattered notes-to-self — and route that lesson to the durable surface that fires next time. NOT a forward choice with alternatives…
metis
A task-routing and checking workflow for explicitly requested Metis work. It assigns work to defined roles, records checks, and limits recovery when something fails.