Agent skill

Session Source Fork

by mvschwarz in mvschwarz/openrig

A skill your agent uses when authoring a rig spec member or rig expand payload that needs to start a new managed seat from a prior runtime conversation source — sessionsource: { mode: fork, ref: {…

Apache-2.0Auto-check passedAgent Workflows

Install Session Source Fork

skills CLI
$ npx skills add mvschwarz/openrig --skill session-source-fork -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install mvschwarz/openrig session-source-fork --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/mvschwarz/openrig.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/_canonical/core/session-source-fork .claude/skills/session-source-fork && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
session-source-fork
GitHub stars
5.5k
Token cost
~2.2k tokens
SKILL.md length
1,026 words
Files
1
Skills in repo
49
Repo updated
First seen
Licence
Apache-2.0

At a glance

A skill your agent uses when authoring a rig spec member or rig expand payload that needs to start a new managed seat from a prior runtime conversation source — sessionsource: { mode: fork, ref: {…

  • Works in 4 steps: Declared — present in member config or… → Resolved — at launch time, OpenRig… → Realized — runtime fork succeeds; new… → …
  • Authoring a rig spec member
  • SKILL.md covers Use this when, Don't use this when, The shape (canonical YAML) and State model, plus 8 more sections
  • Calls claude and codex

What it does

Session Source Fork is an agent skill from mvschwarz/openrig. 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 — sessionsource: { mode: fork, ref: { kind, value } }. v1 supports mode: fork with ref.kind: nativeid 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.

Its SKILL.md is about 2.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Agent Workflows. The repository describes itself as: Build your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work. The licence is Apache-2.0.

When your agent uses it

  • Authoring a rig spec member
  • Rig expand payload that needs to start a new managed seat from a prior runtime conversation source — sessionsource: { mode: fork

Example prompts

  • “/session-source-fork”

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Declared — present in member config or expansion payload
  2. Resolved — at launch time, OpenRig resolves the ref against the runtime
  3. Realized — runtime fork succeeds; new managed seat receives a NEW native continuity token (Claude session id or Codex thread id). OpenRig…
  4. Failed — resolution or fork failed; seat not launched as a fork; clear error names the resolution step that failed

What it can do on your machine

Read from SKILL.md and the folder at commit a7fed63. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • claude
    • codex

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Session Source Fork loads about 2.2k tokens when it runs. Until then it costs about 118 tokens; SKILL.md has 1,026 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~118
When it runs · the whole SKILL.md, loaded when a task matches
~2.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from mvschwarz/openrig at commit a7fed63, republished under its Apache-2.0 licence (© mvschwarz). 1,026 words, ~2,249 tokens.

Download SKILL.mdSave it as .claude/skills/session-source-fork/SKILL.md (or your agent's skills folder).
name
session-source-fork
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.

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"

Rules:

  • mode v1 only valid value: fork.
  • ref.kind v1 supports native_id only. Schema rejects artifact_path, name, last, and artifact_set pre-launch with explicit deferred/weaker/wrong-mode error messages (see packages/daemon/src/domain/rigspec-schema.ts validateSessionSourceFork). Adapter-level refusal exists as defensive handling but should not be reachable in v1 because schema rejects first.
  • value required for ref.kind: native_id in v1 (the only schema-accepted kind). Future-state value semantics for artifact_path / name / last are not active in v1 because schema rejects those kinds pre-launch.
  • rig expand accepts the same shape so dynamically-added members can carry session-source attribution.

The primitive does NOT introduce a new top-level command. It flows through existing rig spec and expansion pathways.

State model

session_source is a launch-time input, not a long-lived stateful field:

  1. Declared — present in member config or expansion payload
  2. Resolved — at launch time, OpenRig resolves the ref against the runtime
  3. Realized — runtime fork succeeds; new managed seat receives a NEW native continuity token (Claude session id or Codex thread id). OpenRig persists that NEW token. Parent token is NEVER written onto the new seat.
  4. Failed — resolution or fork failed; seat not launched as a fork; clear error names the resolution step that failed

Once realized, session_source is essentially history. Restoring the seat later is restore of the new seat, not re-fork-from-parent.

Failure modes (5)

  1. Source session id not found — runtime cannot resolve native_id. Action: emit error naming runtime + missing id; do NOT silently launch fresh. (Future-state note: when artifact_path is supported in a follow-up slice, it could become a candidate fallback for Claude; in v1 schema rejects artifact_path pre-launch so no fallback path exists.)
  2. Source artifact path missing (out of v1 scope) — would apply once ref.kind: artifact_path becomes schema-accepted. v1 schema rejects this kind pre-launch.
  3. Unsupported runtime/kind combination (largely pre-empted in v1 by schema rejection) — schema rejects all non-native_id kinds upfront. Adapter-level refusal exists as defensive handling but is not reached in v1.
  4. Fork launch failed after source resolution — runtime command (claude --resume <parent> --fork-session or codex fork <id>) returned non-zero or hung. Preserve runtime stderr; do not record new seat as launched; do not write parent token onto seat.
  5. Persistence inconsistency — fork succeeded but seat-token persistence cannot record new continuity token. Internal failure: seat is not considered launched until new token is durably written.

Honest UX rule (verbatim)

The primitive must NOT report "restored the original agent" or "resumed the original seat" or "snapshot." The correct framing is "forked from source session" / "started from prior conversation source."

Check the actual user-facing outcome and persisted identity; wording alone does not prove the intended continuity was created.

Show full SKILL.md (418 more words)Show less

Hard boundaries (do-not list; verbatim)

  • Do NOT introduce a DIVERGENT fork primitive. The primitive flows through existing spec/expansion pathways. (Update 2026-08-07: rig fork <source-session> has since shipped as a thin convenience verb that COMPOSES the existing agent-image fork path — this honors the boundary; it is not a divergent primitive. The rule now reads: no NEW fork mechanics outside the spec / expansion / agent-image pathways.)
  • Do NOT report "restored" / "resumed the original seat" / "snapshot" in any UX surface.
  • Do NOT couple session_source to AgentSpec. It's a member-level launch-time input.
  • Do NOT change restore semantics. session_source creates a seat; restore continues an existing managed seat.

Adapter command shape (shipped v1)

RuntimeCommand shape
Claude (mode: fork + ref.kind: native_id)claude --resume <parent-id> --fork-session
Codex (mode: fork + ref.kind: native_id)codex... fork <parent-id>
TerminalRejected at schema level

Mutual exclusion between resumeToken (restore path) and forkSource (fork path) is enforced at three layers in the daemon.

Continuity outcome literals

OutcomeWhen
forkedFork succeeded; new seat has new native token; parent never written onto new seat
freshFresh launch (no session_source declared)
resumedRestore of existing managed seat
failedResolution or fork failed

For seat handover over fork composition, the binding outcome is independent (see seat-continuity-and-handover skill).

Verify the running implementation

A source checkout and the running daemon can contain different implementations. Before an authorized fork, check the target daemon's build identity and support for the requested source. A source or isolated test establishes only that cut's behavior; it does not prove the live runtime uses it.

Record the actual parent history, new seat identity, new continuity token and independent binding outcome. Preserve errors and incomplete results rather than reporting a fresh launch or restored original seat as a successful fork. These checks confer no authority to launch, replace or retire a live seat.

Currently shipped (v1) vs deferred

Shipped at openrig c7b6df1 (2026-04-30):

  • Schema accept/reject for full Honest Refusal Matrix
  • Codec roundtrip (serialize → parse → normalize preserves session_source faithfully)
  • Expansion path through rig expand member-input
  • Adapter command shape for Claude + Codex native_id
  • Persistence honesty (seat's resume_token is the NEW post-fork token; parent token NEVER written)
  • Honest UX literal contract (continuityOutcome: forked)

Deferred:

  • Claude artifact_path mode (schema currently refuses with deferred message)
  • Provenance columns (parent_native_id / created_via for queryable RSI consumer)
  • Cross-host fork (source on host A, new seat on host B) — depends on cross-host-rig-commands

See also

  • seat-continuity-and-handover skill — sibling occupant-creation primitives (resume / fork / rebuild / fresh) + seat-binding (handover composes with fork)
  • agent-starters skill — composes session_source fork into named reusable starting points
  • cross-host-rig-commands skill — multi-host fork (deferred)

© mvschwarz, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/_canonical/core/session-source-fork of mvschwarz/openrig.

Open the folder on GitHubat commit a7fed63

Compare with similar skills

Session Source Fork next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Session Source Fork compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Session Source Fork this skillmvschwarz/openrig5.5k—~2.2kAutomated safety check: PassApache-2.0
MCP Server Builderanthropics/skills180k62 repos~2.3kAutomated safety check: PassApache-2.0
Hook Development for Claude Code Pluginsanthropics/claude-plugins-official37k11 repos~4.1kAutomated safety check: NotesApache-2.0
Using Superpowersfarm-fe/farm5.6k34 repos~1.4kAutomated safety check: PassMIT
Executing Plans Inlineobra/superpowers296k2 repos~5.1kAutomated safety check: PassMIT
Claude Code Agent Developmentanthropics/claude-plugins-official37k8 repos~2.8kAutomated safety check: PassApache-2.0

Similar skills

  • MCP Server Builder

    anthropics/skills

    Official

    Guides the design and implementation of Model Context Protocol servers in TypeScript or Python, from tool naming and error messages to evaluation.

    180k GitHub starsUsed in 62 repos~2.3k tokens
    Agent WorkflowsAuto-check passed
  • Hook Development for Claude Code Plugins

    anthropics/claude-plugins-official

    Official

    Explains how to write Claude Code plugin hooks, both prompt-based checks and bash commands, for events such as PreToolUse, Stop and SessionStart.

    37k GitHub starsUsed in 11 repos~4.1k tokens
    Agent WorkflowsAuto-check: notes
  • Using Superpowers

    farm-fe/farm

    A skill your agent uses when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

    5.6k GitHub starsUsed in 34 repos~1.4k tokens
    Agent WorkflowsAuto-check passed
  • Executing Plans Inline

    obra/superpowers

    Has the agent carry out an implementation plan itself, task by task in the current session, keeping a ledger, proving each step with a test and ending with one whole-branch review.

    296k GitHub starsUsed in 2 repos~5.1k tokens
    Agent WorkflowsAuto-check passed
  • Claude Code Agent Development

    anthropics/claude-plugins-official

    Official

    Explains how to write agents for Claude Code plugins: the markdown file with YAML frontmatter, trigger descriptions, model and color settings, and system prompt design.

    37k GitHub starsUsed in 8 repos~2.8k tokens
    Agent WorkflowsAuto-check passed
  • Skill Creator

    Azure/azqr

    Official

    Create new skills, modify and improve existing skills, and measure skill performance.

    794 GitHub starsUsed in 89 repos~8.2k tokens
    Agent WorkflowsAuto-check passed

More from mvschwarz/openrig

All 49 skills in this repo
  • OpenRig Upgrade Procedure

    mvschwarz/openrig

    Walks an agent through upgrading the OpenRig CLI and daemon one observed step at a time, keeping live seats alive and reconciling managed plugin files.

    5.5k GitHub stars~2.9k tokensUpdated today
    Auto-check passed
  • OpenRig Software Factory

    mvschwarz/openrig

    Helps set up a continuing agent software team for a real repository with OpenRig, choosing between manual work, queue handoffs and an explicit Workflow.

    5.5k GitHub stars~2.5k tokensUpdated today
    Auto-check passed
  • Separates a stable agent seat's identity from its changing occupant, and records honest, two-part provenance whenever one occupant replaces another.

    5.5k GitHub stars~2.1k tokensUpdated today
    Auto-check passed
  • Loads one section of a Markdown file by its path#h2-slug address with a bundled resolver script, for use outside OpenRig's context library.

    5.5k GitHub stars~341 tokensUpdated today
    Auto-check passed
  • Vault User

    mvschwarz/openrig

    A skill your agent uses when checking the health of this rig's HashiCorp Vault or writing, reading, listing, deleting or explaining its secrets.

    5.5k GitHub starsUsed in 1 repo~451 tokens
    Auto-check passed
  • Agent Refocusing

    mvschwarz/openrig

    Re-grounds a long-running agent in the current product outcome by running a path-based trace to the root of its topology and work trees.

    5.5k GitHub stars~399 tokensUpdated today
    Auto-check passed

Categories

Questions about Session Source Fork

What does Session Source Fork do?

A skill your agent uses when authoring a rig spec member or rig expand payload that needs to start a new managed seat from a prior runtime conversation source — sessionsource: { mode: fork, ref: {…. Session Source Fork is an agent skill from mvschwarz/openrig. 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 — sessionsource: { mode: fork, ref: { kind, value } }.

When should I use Session Source Fork?

Session Source Fork fits situations like: authoring a rig spec member; rig expand payload that needs to start a new managed seat from a prior runtime conversation source — sessionsource: { mode: fork.

How do I install Session Source Fork in Claude Code?

Run `npx skills add mvschwarz/openrig --skill session-source-fork -a claude-code`. Or copy the skill folder (skills/_canonical/core/session-source-fork in mvschwarz/openrig) into .claude/skills/session-source-fork in your project. Claude Code loads it when a task matches its description.

How do I install Session Source Fork in Codex?

Run `npx skills add mvschwarz/openrig --skill session-source-fork -a codex`. Or copy the skill folder (skills/_canonical/core/session-source-fork in mvschwarz/openrig) into .agents/skills/session-source-fork in your project. Codex loads it when a task matches its description.

Can I use Session Source Fork in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add mvschwarz/openrig --skill session-source-fork -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/session-source-fork, .gemini/skills/session-source-fork, .github/skills/session-source-fork and .opencode/skills/session-source-fork in your project.

What does Session Source Fork need to run?

Going by SKILL.md and its folder, Session Source Fork needs the command-line tools its instructions call (claude and codex).

Does Session Source Fork access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Session Source Fork safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Session Source Fork use?

Session Source Fork is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Session Source Fork use?

About 2.2k tokens (SKILL.md is roughly 9k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Session Source Fork?

Skills that share tags, products or a category with Session Source Fork: MCP Server Builder (anthropics/skills, 180k stars), Hook Development for Claude Code Plugins (anthropics/claude-plugins-official, 37k stars), Using Superpowers (farm-fe/farm, 5.6k stars) and Executing Plans Inline (obra/superpowers, 296k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Session Source Fork?

mvschwarz (a GitHub user) maintains it in mvschwarz/openrig, which has 5,542 GitHub stars. The repository holds 49 skills in this directory. The repository was last updated on October 7, 2026.

Source: mvschwarz/openrig on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.