Session Source Fork logo

Session Source Fork

CommunityPopular
mvschwarz
session-source-fork

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.

Overview

Publishermvschwarz
Repositoryopenrig
Skill namesession-source-fork
Stars
5K
Forks
366
Bundled files
Instructions only
LicenseApache-2.0
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by mvschwarz on GitHub. Read the source before you install it.

Installation

Install the Session Source Fork AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/mvschwarz/openrig/tree/main/packages/daemon/specs/agents/shared/skills/core/session-source-fork
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/mvschwarz/openrig.git /tmp/openrig
mkdir -p .claude/skills
cp -r /tmp/openrig/packages/daemon/specs/agents/shared/skills/core/session-source-fork .claude/skills/session-source-fork
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Session Source Fork in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Session Source Fork on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Session Source Fork is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

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.

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)

Frequently asked questions

What does the Session Source Fork AI skill do?

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.

Why use Session Source Fork on TypingMind?

Because you install it once and use it with any model. Session Source Fork is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Session Source Fork in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/mvschwarz/openrig/tree/main/packages/daemon/specs/agents/shared/skills/core/session-source-fork. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Session Source Fork?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Session Source Fork?

As many as you like. As long as a model supports skills, you can use Session Source Fork with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Session Source Fork AI skill free?

Yes. It is published on GitHub by mvschwarz under the Apache-2.0 license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇