Pass the baton. Turn the work sitting in your coding agent's context into one self-contained HTML page — a few diagrams a non-engineer reads in minutes, with the complete session context embedded so the reader's own coding agent can load it and keep going.

AI made every engineer's output explode, but the bandwidth between people did not grow. baton is the handoff: not a summary someone re-derives, but the real working history — every path tried and dropped, every review round, the schema writes behind each state — packaged so a person skims it and their agent resumes from it.

Say "baton" after any real coding session, "write this up for my PM" to pack it for someone who doesn't read code, or paste a PRD / spec / RFC / decision doc. /baton makes two decisions from what you ask — never by asking you to pick:

What is the input?

• Work done in this session — packaged as what happened: the change drawn per item, the paths tried and dropped, next steps.
• A PRD, spec or decision doc — work not yet done, rendered as the argument in diagrams and marked proposal, never mistaken for shipped.

Who reads the page?

• An engineer who has forgotten — future you, or whoever inherits the branch: identifiers, paths and code stay.
• Someone who does not read code — a PM or exec asking "what can now go wrong for our users?": plain words, risks only, each traceable.

Any coding work qualifies — a merged feature, a debugging session, a refactor, an incident, a security fix, a local experiment with no branch. A repo helps; it is not required. Every route produces the same kind of page: an outline you walk, diagrams drawn by the diagram-design skill from the repo's own design docs and embedded as static inline SVG (architecture, an interactive state machine linked to the database write behind each state, sequence, the DB lifecycle as transactions, before/after, attack-path for a security fix), a three-language switch (EN / 繁 / 简), and a one-click copy the context to your AI. It works offline and inside a sandboxed iframe.

Claude Code — clone it and link it in as a personal skill; the command is /baton:

git clone https://github.com/BenjaminLu/baton ~/.claude/baton
ln -s ~/.claude/baton ~/.claude/skills/baton

To update later: git -C ~/.claude/baton pull. Skills load at session start, so open a new session after installing.

Codex, Cursor, and other agents — clone the repo and point your agent at AGENTS.md; it carries the same workflow and script paths.

No repo, no setup, and the data is fetched live. Ask /baton to settle gaming's most famous irreversible decision:

claude "/baton Which Eevee evolution should I commit to? Fetch the real
stats from PokeAPI, embed the sprites, and lay it out as a decision"

What comes out is one HTML file that treats the question with the same rigour as a security audit — which is the joke, and also the point. All eight evolutions share the same six base stats, permuted, so the page becomes a matrix of where each one puts its 130, a quadrant of who plays which role (sprites included), and an acquisition-cost map (buy a stone / grind friendship / walk to one specific rock in Sinnoh) — with the fetch commands embedded so the reader's own agent can verify every number.

Point it at the famous "remove the GIL" proposal and ask for a page a product manager could read:

claude "/baton https://peps.python.org/pep-0703/ — make the free-threaded
Python decision legible to someone who has never heard of the GIL"

What comes out is one HTML file: the rejected alternatives drawn next to what was accepted, the conditions attached to acceptance, the open questions ranked by what they block — and the entire PEP embedded behind a copy button, so whoever you send it to can paste the full context into their own Claude Code / Codex / Cursor and interrogate the proposal past what the page shows.

Any RFC, PEP, KEP, TC39 proposal or design doc works the same way — they are all decision documents, which /baton recognises as a proposal. Done work needs no URL at all: after any real coding session, just say "baton" to pack it for an engineer, or "write this up for my PM" to pack it for someone who doesn't read code.

Python 3 (standard library only), git, and gh for pull-request context (optional — degrades gracefully). Two other skills do the parts baton does not: diagram-design draws every diagram as static inline SVG — no runtime diagram library, no network at view time — and eli5 rewrites the page for a reader who does not read code.

This repository is the skill directory: SKILL.md at the root decides the route and carries the rules that differ by route; references/pipeline.md is the whole method; references/diagrams.md the diagram vocabulary; references/spec.md the packet spec; templates/packet.html the page. The agent does the extraction itself — gh for the pull request, git merge-base for the boundary, reading for the design docs and migrations, its own session for the history — and invokes the diagram-design skill to draw, embedding the extracted SVG. scripts/ holds the only three scripts, all mechanical on purpose: render.py assembles the packet spec into the single HTML file (filling the template and escaping the payloads); verify.py scans for mechanical absences (the context's refusal declaration, a digest-thin context, the register); snapshot.py renders the page headless, fails on mechanical diagram defects, and emits screenshots. Diagram correctness is then checked by eye in a real browser — that is the gate.

MIT.