Guide · Agent skill
How to use the Seat Continuity and Handover agent skill
Updated · written with AI from the project's own documentation and checked against our catalogue data
The seat-continuity-and-handover skill teaches an AI agent how to replace the agent occupying a named role, or seat, in an OpenRig multi-agent setup. It is for developers and operators who rebuild, fork or swap seat occupants and want the seat's stable address and history kept intact. After following this guide you will know what the skill asks the agent to do, how to install it, how to phrase a request that triggers it, and which safety limits apply.
Seat Continuity and Handovermvschwarz/openrig · Apache-2.0 Download the skill Quick start
- 1Install the skill. Unzip the downloaded ZIP into ~/.claude/skills/ or a project's .claude/skills/ folder, or upload it under Settings → Capabilities → Skills.
- 2Confirm OpenRig is available. Make sure the OpenRig daemon and rig CLI are running, since the skill references rig handover and rig seat status.
- 3Ask with a clear seat goal. Name the seat and the change you want, such as rebuilding its occupant or choosing a disposition for the old one.
- 4Run a dry run first. Use --dry-run to request planning only before any command that can change state.
- 5Get owner authorization. Obtain explicit approval from the named owner before running a non-dry-run handover.
- 6Check the outcomes. Read continuityOutcome, seatBindingOutcome and the provenance record separately with rig seat status.
What the skill makes the agent do
The skill separates who is sitting in a seat from what the seat itself is. A seat keeps a stable address, while its occupant can change. When an occupant is replaced, the agent is guided to record two independent outcomes: whether continuity was achieved (continuityOutcome: rebuilt, resumed, forked, fresh or failed) and whether the binding succeeded (seatBindingOutcome: handed_over, partial, failed or unchanged).
It also requires a provenance record for every handover, listing the seat id, old and new occupant ids, creation mode, source artifacts, what happened to the old occupant, who initiated the change, a timestamp and the result.
- Keep the seat name stable; do not add successor suffixes such as lead2 or lead3.
- Do not report handed_over if the provenance record did not write durably.
- Do not auto-rollback a half-finished handover by reattaching the old occupant unless detach completed cleanly.
Install the skill
Download the skill ZIP from this page and unzip it into one of two locations. For a personal install, use ~/.claude/skills/. For a single project, use the .claude/skills/ folder inside the project. The skill folder contains SKILL.md and the references/ files it relies on.
Alternatively, upload the ZIP in the Claude apps under Settings → Capabilities → Skills.
- Personal: ~/.claude/skills/
- Project: .claude/skills/ inside your project folder
- Claude apps: Settings → Capabilities → Skills, then upload the ZIP
Check that you have the prerequisites
The skill only makes sense inside an OpenRig setup. It references the OpenRig daemon and the rig CLI, including rig handover, rig seat handover and rig seat status. Without the daemon and CLI those commands will not exist, and the skill does not apply.
The operator mechanics for a real cutover are in the reference files, especially the apprentice-successor seat cutover SOP. The skill does not run scripts and does not use the network.
- OpenRig daemon and rig CLI
- Reference files in the skill folder (references/apprentice-successor-seat-cutover.md and related files)
Trigger the skill with natural requests
The skill's description lists the situations it covers. Ask for them in plain language that names the seat and the goal. Good triggers include replacing or rebuilding a seat's occupant, choosing what happens to the old occupant (retire, advise or shadow), and recording how an occupant change happened.
Do not use it for a seat that was just created with no occupant. For that case the skill points you to rig launch or rig expand instead.
- "Rebuild the occupant of the lead seat from its recap and tell me the outcome."
- "Hand over the reviewer seat to a fork of the current occupant, keep the old one as advisor, and show the provenance."
- "Explain how the current occupant of the planner seat came to be."
- "Swap the implementer seat occupant with a fresh one, dry run first."
Write the seat recap before a handover
A rebuild primes the successor from the seat's durable artifacts, highest trust first: the authored RECAP.md, then LEARNED.md, then the latest restore packet if marked, then superseded recaps. Before a handover, compaction or long pause, the current occupant should write its recap through the command below rather than a file tool, so the chain is kept.
The store refuses the write and writes nothing when a section cannot be addressed. Only H2 and H3 headings count as sections, and duplicate section paths are not allowed.
- <seat> is the seat's folder under rigs/<rig>/seats/, the part of its session name before @.
- The command reads topology.root and does not need the daemon.
rig context recap-write --rig <rig> --seat <seat> --file <draft.md>Use dry runs and check results
The rig handover and rig seat handover commands accept fresh, discovered:<id>, fork:<seat> and rebuild sources. Use --dry-run to request planning only. Without it, these commands can execute real state changes, so do not assume they are read-only.
rig seat status <seat> is the read-only way to observe a seat. A help listing or dry-run is not proof that a transition succeeded, so read the source, continuity, binding and provenance results separately.
- Get explicit owner authorization before any non-dry-run command.
- Use rig seat status to inspect the result after a change.
rig seat status <seat>What people use it for
- Rebuilding a seat's occupant from its authored recap and learned notes after the previous occupant's context has grown too large.
- Forking a seat's current occupant into a candidate successor and binding it into the same stable seat.
- Auditing how the current occupant of a seat came to be by reading its provenance record.
- Choosing whether the old occupant is retired, kept as an advisor, or shadowed after a handover.
- Writing a seat recap before a planned handover so the successor has the latest context.
Frequently asked questions
How do I install the seat-continuity-and-handover skill?
Download the skill ZIP from this page and unzip it into ~/.claude/skills/ for a personal install or into a project's .claude/skills/ folder. You can also upload the ZIP in the Claude apps under Settings → Capabilities → Skills.
What do I need to run this skill?
You need an OpenRig daemon and the rig CLI, because the skill's commands (rig handover, rig seat handover, rig seat status) come from them. The reference files in the skill folder are needed for operator mechanics. Without OpenRig, the skill does not apply.
Is the skill free to use?
The source identifies the licence as Apache-2.0. Check the licence file in the repository for the full terms. This page does not state any price.
Does the skill run scripts or use the network?
According to the assessment, it runs no scripts and uses no network. Its commands operate on the OpenRig daemon and CLI, and non-dry-run commands can execute real state changes, so use --dry-run and get owner approval first.
When should I not use this skill?
Do not use it for a freshly created seat with no occupant to replace; use rig launch or rig expand instead. Do not use it to add or remove seats, since that changes topology shape rather than the occupant.
Why does the skill refuse to rename seats?
The skill sets stable seat identity as the architectural goal. Successor suffixes such as lead2 or lead3 are forbidden, and a retired tenure is tracked through its ledger generation and history token instead of a renamed pane.
New agent skills, repos and AI tools — every week
The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.
Our verdict
This skill suits OpenRig developers and operators who replace seat occupants and need a traceable record of who replaced whom. It is not useful if you do not run an OpenRig daemon and CLI, or if you need a simple way to start a new agent in an empty seat.
Download the skill