К основному содержанию
скилл CX Codex

session-source-fork — скилл для Claude Code: форк сессии

Скилл для авторинга rig spec: запускает новое управляемое место из прошлой сессии Claude или Codex, не выдавая его за продолжение старого.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add mvschwarz/openrig --skill session-source-fork -a claude-code
Открыть на GitHub

Что делает session-source-fork

session_source — поле уровня члена в OpenRig, которое описывает, откуда новое место берёт начальную непрерывность разговора. В v1 работает один режим — fork: новое место стартует от прежнего нативного источника, но не считается продолжением исходного места.

Схема не привязана к рантайму, а реализация зависит от него: Claude и Codex форкают своими командами. Для Claude это claude --resume <parent-id> --fork-session, для Codex — codex fork <parent-id>. Новое место получает НОВЫЙ токен непрерывности, а родительский токен на него не записывается никогда. Терминальный рантайм session_source отклоняет.

ref.kind в v1 принимает только native_id, а value для него обязателен. Схема отклоняет artifact_path, name, last и artifact_set ещё до запуска, поэтому запасного пути через артефакт нет. Если исходный id не находится, ошибка называет рантайм и пропавший id — тихий запуск с нуля не предусмотрен. Это повод проверить, что вы не путаете форк с восстановлением: restore продолжает существующее место, а session_source создаёт новое.

Какие задачи решает

  • запустить новое управляемое место от прошлой сессии Claude или Codex
  • описать источник сессии в rig spec или в payload rig expand
  • выбрать между fork, rebuild, resume и fresh для нового места
  • сложить форк с передачей дел по месту
  • поймать ошибку, когда исходный session id не резолвится

Примеры запросов агенту

  • добавь в member session_source с mode: fork и ref.kind: native_id
  • сделай rig expand с session_source, чтобы новое место форкнулось от прошлой сессии
  • проверь, что рантайм не terminal — иначе session_source отклонят

Как установить session-source-fork

1Через Skills CLI (Vercel)

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

2Вручную: положить файлы

~/.claude/skills/session-source-fork/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/session-source-fork/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Вопросы о session-source-fork

Как установить session-source-fork в Claude?

Выполните npx skills add mvschwarz/openrig --skill session-source-fork -a claude-code. Скилл окажется в ~/.claude/skills/session-source-fork/SKILL.md.

Что делает session-source-fork?

Описывает, как новое управляемое место получает начальную непрерывность разговора от прежнего нативного источника. В v1 это режим fork с ref.kind: native_id для Claude и Codex.

Чем форк отличается от восстановления места?

Форк создаёт новое место с новым токеном непрерывности, а restore продолжает уже существующее. Родительский токен на новое место не записывается.

Исходный текст

SKILL.md · Apache-2.0
---
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.
metadata:
  openrig:
    stage: factory-approved
    sibling_skills:
      - claude-compaction-restore
      - session-compaction-and-restore
      - agent-startup-and-context-ingestion
      - agent-starters
      - seat-continuity-and-handover
---

# 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)

| Runtime | Command 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>` |
| Terminal | Rejected at schema level |

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

## Continuity outcome literals

| Outcome | When |
|---|---|
| `forked` | Fork succeeded; new seat has new native token; parent never written onto new seat |
| `fresh` | Fresh launch (no `session_source` declared) |
| `resumed` | Restore of existing managed seat |
| `failed` | Resolution 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 · mvschwarz/openrig

Похожие скиллы

Все скиллы по теме «Настройка агента: память, контекст, субагенты» →
fork-discipline jezweb Находит зашитые имена клиентов и условия в общем коде мультиклиентских репозиториев. Скилл строит карту границ платформы и готовит план рефакторинга. CX Codex +1 889установок bmad-party-mode bmad-code-org Собирает обсуждение между BMAD-агентами и пользовательскими персонами. Пригодится для раундтейблов, нескольких точек зрения и настройки собственных партий. CX Codex +1 11 500установок grok-delegate amElnagdy Скилл передаёт задачу на реализацию в Grok Build CLI, а вы проверяете диф и коммитите сами. Пригодится, когда нужно разгрузить основного агента. CX Codex +1 4 300установок standup thedotmack Скилл запускает фасилитируемый разговор между агентами разных гит-веток и PR. Каждая ветка как отдельный участник обсуждает свои изменения, находит пересечения и выбирает порядок слияния — всё без реальных коммитов. CX Codex +1 3 400установок warp-delegate amElnagdy Передаёт задачу на реализацию агенту Warp через oz agent run, а вы проверяете диф и коммитите сами. Пригодится, когда нужно остаться ревьюером, а не писать код вручную. CX Codex +1 2 800установок nelson Aspegio nelson координирует работу нескольких ИИ-агентов по этапам миссии. Он нужен для параллельных задач, контрольных точек и журнала решений. CX Codex +1 1 300установок

Из того же набора14

context-engineering Скилл про то, как наполняется окно контекста агента: что грузить сразу, что по запросу, когда чистить. Пригодится, если агент забывает ограничения посреди задачи. CX Codex +1 ★ 8 172звёзд репо orchestration-team Скилл для оркестрации: раздаёт задания между агентами, следит за простаивающими и заблокированными и не даёт оркестратору делать работу за других. CX Codex +1 ★ 8 172звёзд репо requirements-writer Ведёт диалог с продакт-менеджером и собирает из черновых мыслей один SPEC.md с проверяемыми критериями приёмки и явными границами. CX Codex +1 ★ 8 172звёзд репо exec-summary Собирает из папки фичи один документ на 600–800 слов: питч для продаж, стратегию для руководства и поведение для разработки. CX Codex +1 ★ 8 172звёзд репо watchdog Скилл для настройки политик rig watchdog: решает, когда будить застрявший цикл, когда вернуть его к задаче, а когда остановить на сверку. CX Codex +1 ★ 8 172звёзд репо openrig-upgrade Ведёт агента через обновление OpenRig CLI и демона по шагам: проверить, изменить, убедиться. Полезен, когда на хосте живут рабочие сессии. CX Codex +1 ★ 8 172звёзд репо messaging-the-human Скилл описывает, как агенту написать человеку через rig: создать запрос на решение или тихое уведомление и дождаться ответа. CX Codex +1 ★ 8 172звёзд репо agent-startup-and-context-ingestion Скилл для тех, кто собирает стартовые файлы агента: разбирает четыре режима отказа контекста и показывает, как агент получает роль и текущий режим работы. CX Codex +1 ★ 8 172звёзд репо

Спонсоры проекта

Компании, которые помогают держать аналитику открытой