Continuity Core — Development skill for Claude Code

continuity-core

The provider-neutral bones of a multi-agent session-continuity system: a transactional checkpoint store, a deterministic route planner, and a Claude/Codex tool-envelope mapper. Zero dependencies, Node >= 18, ESM only.

This is the general-purpose layer extracted from a working multi-agent setup — see [Provenance](#provenance). It does not include a message broker, a permission policy engine, or any hook wiring for a specific host; those are workspace-specific and live elsewhere (a sibling project, **the-wire**, publishes a durable local broker built on the same lock-file primitives).

The three primitives

`store` — a transactional checkpoint store

A checkpoint is a small curated JSON object — `objective`, `decisions`, `completed`, `next`, `references` — that one agent writes so another agent (or the same agent after a context compaction) can resume without re-reading a transcript. `store` gives you:

• A lock-file transaction. mkdir .lock is the mutex — atomic on every target filesystem this library expects to run on. The update runs, the result is written to a temp file, fsynced, then renamed over the target. A crash mid-write leaves the old file intact; a crash mid-lock leaves a lock directory behind, on purpose (see `docs/FIELD-NOTES.md` for why removing a stale lock automatically is the wrong move).
• Revision-conflict detection. Every save() carries the revision it expects to be replacing. If the task has moved on, save() throws Revision conflict and writes nothing. Never blindly retry a revision conflict with the same checkpoint. Re-read the task, see what the other writer decided, and resubmit a checkpoint that accounts for it. An eventId makes a retried identical write (same id, same content, same writer) a no-op instead of a conflict — that is the one case that is safe to retry automatically.
• Checkpoint validation that rejects secrets by regex. Every t