# Session Source Fork

Use when authoring a rig spec member or `rig expand` payload that needs to start a new...

- Repository: https://github.com/mvschwarz/openrig (8541 stars)
- Category: AI and agents
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add mvschwarz/openrig --skill session-source-fork -g -a claude-code -y`
Codex: `npx skills add mvschwarz/openrig --skill session-source-fork -g -a codex -y`
Cursor: `npx skills add mvschwarz/openrig --skill session-source-fork -g -a cursor -y`
Gemini CLI: `npx skills add mvschwarz/openrig --skill session-source-fork -g -a gemini-cli -y`

## Description

Use when authoring a rig spec member or `rig expand` payload that needs to start a new managed seat from a prior runtime conversation source, `session_source: { mode: fork, ref: { kind, value } }`. v1 supports `mode: fork` with `ref.kind: native_id` for Claude and Codex. The new seat persists a NEW post-fork token; the parent token is NEVER written onto the new seat. NOT for restoring an existing seat or for artifact-backed mental-model rebuild.

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

# session_source Fork

`session_source` is a **member-level OpenRig field** that declares how a
newly-launched managed seat should derive its initial conversation
continuity from a prior runtime conversation source.

v1 supports one mode: **`fork`**, start a *new* managed seat from a
prior native runtime conversation source without claiming the original
seat continued.

The schema is runtime-neutral; implementation is runtime-specific (Claude
and Codex have their own native fork commands).

## Use this when

- Authoring a rig spec member that should fork from a prior session
- Authoring a `rig expand` payload with `session_source`
- Reasoning about whether to use `fork` vs `rebuild` vs `resume` vs `fresh` for a new seat
- Composing fork + handover (seat-handover-over-fork), see `seat-continuity-and-handover` skill

## Don't use this when

- The seat is being **restored**, not created. Restore continues an existing managed seat. Fork creates a new seat.
- The continuity is **artifact-backed mental-model rebuild** (packet-derived understanding, not native runtime continuity). Use `mode: rebuild` (see `seat-continuity-and-handover` for the rebuild surface), do NOT collapse fork into artifact-backed reentry; the distinction is load-bearing.
- The runtime is `terminal`. Terminal runtime rejects `session_source`.

## The shape (canonical YAML)

```yaml
members:
  - id: reviewer-2
    runtime: claude-code        # or "codex"; not valid on terminal
    agent_ref: specs/agents/reviewer.yaml
    profile: reviewer
    cwd: .
    session_source:
      mode: fork
      ref:
        kind: native_id          # v1 fork mode supports native_id only
        value: "0b0165d7-cb4d-4650-90de-15c0a1ede9e6"
```

The rest: https://github.com/mvschwarz/openrig/blob/HEAD/packages/daemon/specs/agents/shared/skills/core/session-source-fork/SKILL.md