← Baton PassCONTENT HISTORY

Update to Baton Pass

Snapshot Sep 30, 2026 · 23:15 UTC · version 0.8.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Multi-agent handoff workflow for coding repos, shared across Claude and Codex. Use when work must pause, transfer, or resume between agents or sessions — new-game (set up a repo), save-state (pause without handoff), baton-pass (hand off on low tokens or ownership change), foresight (receive and verify), party-check (who owns it now), hindsight (audit claimed-vs-done), dragon-dance (record a workflow lesson). Invoke as /move, $move, or plain name; also on task lists, worktrees, multi-agent plans, or low context.",
  "included_files": [],
  "name": "baton-pass",
  "skill_md_contents": "---\nname: baton-pass\ndescription: Multi-agent handoff workflow for coding repos, shared across Claude and Codex. Use when work must pause, transfer, or resume between agents or sessions — new-game (set up a repo), save-state (pause without handoff), baton-pass (hand off on low tokens or ownership change), foresight (receive and verify), party-check (who owns it now), hindsight (audit claimed-vs-done), dragon-dance (record a workflow lesson). Invoke as /move, $move, or plain name; also on task lists, worktrees, multi-agent plans, or low context.\n---\n\n# Baton Pass\n\nPurpose: preserve continuity between multiple agents with the least amount of text necessary.\n\nThis is a low-token workflow utility, not a documentation ceremony.\n\n## Quick Setup\n\n### Install on every agent (once per machine)\n\n```bash\nnpx github:netheremp/baton-pass-netheremp install\n```\n\nInstalls this skill into `~/.claude` and every `~/.codex*` home. Then:\n- Claude Code (CLI + IDE) — skill auto-loads; `/new-game` `/save-state` `/baton-pass` `/foresight` `/dragon-dance` `/party-check` `/hindsight`\n- Codex CLI — skill auto-loads; run it explicitly with `$baton-pass`\n- Codex desktop app — skill auto-loads; `/prompts:baton-pass` in the composer\n\nAlternatives: `/plugin marketplace add netheremp/baton-pass-netheremp` (Claude Code) or `/plugins` → install (Codex).\n\n### Initialize a repo for multi-agent work\n\n```bash\nnpx github:netheremp/baton-pass-netheremp init\n```\n\nAdd `--track-state` to commit handoff state to git (teams that need shared history). Default is local-only (gitignored).\n\nThis creates:\n- `baton-pass.config.json` — where the workflow finds your memory files\n- `baton-pass.state.json` — lightweight shared ownership state\n- `docs/agent-handoff.md` — repo-specific rules for all agents\n- `docs/current-state.md` — what is happening right now\n- `docs/next-task.md` — who owns the work and what comes next\n- `docs/progress.md` — running session log (append-only)\n\n`init` also drops the `/move` slash commands into the repo's `.claude/commands/`.\n\n## The Move Set\n\n- `new-game` = initialize the workflow in a fresh repo\n- `save-state` = pause safely without handing off\n- `baton-pass` = transfer work when tokens are low or ownership changes\n- `foresight` = receive or resume work, verify alignment, then continue\n- `dragon-dance` = improve the workflow only when a real lesson was learned\n- `party-check` = inspect who last acted, who should act next, and the current repo state\n- `hindsight` = audit the full baton chain — milestones claimed, verifications made, risks carried, items never resolved\n\n## Core Rule\n\nDefault to delta, not recap.\n\nDo not restate stable project history unless the receiver cannot continue safely without it.\n\n## When To Use Each Move\n\n### `new-game`\n\nUse once at repo start, or when introducing this workflow into a repo that has no shared memory files yet.\n\n### `save-state`\n\nUse when:\n- you must stop suddenly\n- you are pausing work for later\n- ownership is not changing yet\n\n`save-state` is a local checkpoint, not a transfer.\n\n### `baton-pass`\n\nUse when:\n- tokens are low\n- another agent is taking over\n- you need a transferable continuity package\n\n`baton-pass` is a transfer checkpoint.\n\n### `foresight`\n\nUse when:\n- receiving a baton\n- returning after a save-state\n- there is any doubt that the written state still matches the repo\n\n### `dragon-dance`\n\nUse only when:\n- the workflow itself learned something\n- the receiver found drift\n- the baton omitted something important\n- a new rule would clearly prevent repeated waste\n\nDo not trigger `dragon-dance` by reflex.\nDo not include it in every session or `baton-pass` by default.\n\n### `party-check`\n\nUse when:\n- you forgot whose turn it is\n- multiple agents share the repo\n- you want the current status without paying for a full `foresight`\n\n`party-check` is the in-session move. From a plain terminal (no agent, no tokens) run\n`baton-pass status` — it prints the same ownership read plus the recent baton chain, and\n`baton-pass status --json` gives machine-readable output for scripts and hooks.\n\n### `hindsight`\n\nUse when:\n- a milestone or major feature is complete and you want a clean record\n- something feels wrong and you need to trace what was actually claimed vs. done\n- a new agent is joining and needs a full picture of the history, not just the last baton\n- a `foresight` found severe drift and you need to understand how far back it started\n- the project is being reviewed, handed to a human, or archived\n\nDo not run `hindsight` after every baton.\nIt is an audit, not a routine checkpoint.\n\n## What Each Move Should Write\n\n### `save-state`\n\nMinimal output:\n- current task\n- stopped at\n- files touched\n- next immediate action\n- blocker or risk\n\n### `baton-pass`\n\nMinimal output:\n- goal\n- done\n- tasks (if using a task plan — list each task with status: done / in-progress / pending)\n- files\n- worktree (branch name and worktree path if using git worktrees)\n- verified\n- deviations (decisions made mid-session that differ from the original plan)\n- environment (prerequisites the next agent must confirm: services running, .env vars set, test DBs, etc.)\n- next\n- risks\n- next agent\n\nCommit discipline:\n- Commit before handing off, or document why not.\n- Never hand off a dirty working tree without naming the uncommitted state explicitly.\n- If verification was not run, say so — do not imply it passed.\n\n**Why tasks, worktree, deviations, and environment matter:**\nSession memory is lost on handoff. If you are mid-way through a 20-task plan, the next agent cannot reconstruct which tasks are done from git log alone — write the status explicitly. If you are working inside a worktree, the next agent needs the exact path. If you fixed something differently than the plan said, write it down — the next agent will re-read the plan and redo it the wrong way. If the environment must be in a specific state (database running, .env populated), name it — a fresh agent will hit the same blocker without it.\n\n### `foresight`\n\nMinimal output:\n- aligned or not\n- if not aligned, what was stale or missing\n- corrected next step only if needed\n\nIf drift is severe (baton claims work was done but the repo shows otherwise), write a structured drift report before continuing:\n- what was claimed\n- what the repo actually shows\n- what must be redone\n- whether this drift warrants a `dragon-dance`\n\n### `dragon-dance`\n\nMinimal output:\n- problem\n- impact\n- improvement\n- new convention\n\n### `party-check`\n\nMinimal output:\n- state\n- last move\n- last agent\n- next agent\n- updated at\n- short summary\n\n### `hindsight`\n\nMinimal output:\n- audit scope (full chain or bounded range)\n- baton chain table (from → to, date, goal summary)\n- milestones claimed per agent with verification status\n- verification gaps (claims made without evidence)\n- risks carried forward across batons\n- drift found across batons\n- open items never resolved\n- audit verdict: `clean`, `gaps found`, `risks unresolved`, or `action required`\n\nSources to check:\n- `docs/progress.md` — full session log\n- `docs/next-task.md` — Turn State history\n- `baton-pass.state.json` — programmatic state\n- git log — commit messages and dates\n- any saved baton or save-state files referenced in progress\n\n## Receive Procedure For `foresight`\n\nCheck only the minimum needed to avoid missteps:\n- current user goal\n- working tree status\n- latest commit(s)\n- `current-state`\n- `next-task`\n- latest `progress` entry\n- files named in the saved state or baton\n- task list status if a plan was in progress\n\nThen decide:\n- if aligned, continue\n- if misaligned, correct the baton and continue\n- if the misalignment reveals a reusable lesson, run `dragon-dance`\n\n## Skill Discovery Across Agents\n\nWhen skills are installed project-locally (into `.claude/commands/` or via plugin install to the repo), Codex and other agents that pick up the repo will find the same skill definitions. The skill files travel with the repo.\n\nWhat skills do NOT carry across a session boundary:\n- Task state from in-memory task managers (TaskCreate lists are lost when the session ends)\n- Subagent execution state (which review loops completed, which agents ran)\n- Environment state (what services are running, what .env vars are set)\n\nThe baton-pass must write all of this explicitly. Skills tell agents how to work; the baton tells them where things stand.\n\n## State Model\n\nUse the shared state file to track:\n- current state\n- last move\n- last agent\n- next agent\n- updated time\n- summary\n\nRecommended states:\n- `active`\n- `paused`\n- `handed-off`\n- `claimed`\n- `blocked`\n\n## Verification Vocabulary\n\nUse consistent language so receivers know exactly what was checked.\n\n- `passed` — ran locally, output confirmed clean\n- `passed outside sandbox` — ran locally but not in the CI/build environment\n- `not run — [reason]` — skipped, state the reason\n- `expected to pass, unverified` — not run, but believed correct\n\nNever write `passed` when you mean `expected to pass, unverified`.\nThat single ambiguity causes the most handoff rework.\n\n## Turn State\n\nThe Turn State block in `next-task` is the primary human-readable ownership signal.\n`baton-pass.state.json` mirrors it for programmatic use.\n\nWhen updating one, update both. If they ever disagree, `next-task` wins.\n\nRecommended `state` values in both:\n- `active` — someone is working now\n- `paused` — stopped safely, same agent will resume\n- `handed-off` — transferred, waiting for receiver to claim\n- `claimed` — receiver has run `foresight` and is continuing\n- `blocked` — cannot proceed, reason should be in `next-task`\n\n## Anti-Patterns\n\nAvoid:\n- using `baton-pass` for every tiny checkpoint\n- using `dragon-dance` when nothing was learned\n- rewriting all memory files for trivial work\n- turning `foresight` into a full repo audit every time\n- running `hindsight` after every baton — it is an audit, not a routine step\n- restating the whole project instead of the delta\n- writing `passed` when you mean `expected to pass, unverified`\n- handing off with a dirty working tree without naming the uncommitted state\n- omitting task status when mid-way through a numbered plan\n- omitting the worktree path when work is inside a git worktree\n- omitting environment prerequisites that a fresh agent would not know\n\n## Best Practical Flow\n\nPause:\n- `save-state`\n- later `foresight`\n\nTransfer:\n- `baton-pass`\n- receiver runs `foresight`\n\nImprove:\n- `dragon-dance` only if `foresight` exposed a meaningful workflow issue\n\nCheck turn ownership:\n- `party-check`\n\nAudit the full chain:\n- `hindsight`\n- if gaps or unresolved risks are found, run `dragon-dance`\n"
}

SHA-256 of public snapshot: f14dee86598182b6a56e3082bc63e55a534c219913988facdbd2687548f393f9