name

patchpad

description

Create or use a shared markdown dead-drop for exchanging notes between two live Claude Code sessions running in parallel (separate terminals, same or related work). Use when the user says "/patchpad", "patchpad new/write/read", "set up a patchpad", "drop a note for the other session", or is manually copy-pasting text between two open Claude sessions and wants a lighter way to do it. Not for session handoff across time — that's session-kit's `/relay` + `/pickup`. patchpad is for two sessions open *at the same time*.

Patchpad

A deliberate, human-triggered dead-drop between two live Claude Code sessions — not an automated cross-session channel. Each side writes explicitly; nothing auto-delivers or auto-polls. The human still says "check the pad" out loud — this removes the copy/paste drag, not their judgment about what's worth relaying.

Not session-kit. /relay + /pickup hand a baton from one session to the next across time (one ends, another resumes). patchpad is for two sessions open at the same time, in separate terminals, trading curated notes while both stay live. Different axis of concern — standalone skill, keeps session-kit lean.

Usage

patchpad is a self-contained uv run --script CLI, symlinked onto PATH — invoke it directly, no absolute path needed:

patchpad new [--note "purpose"]
patchpad write <slug> "<message>" [--from <label>]
patchpad read <slug> [--tail N]

new creates ./.stoobz/patchpad/<slug>.md in the current project and prints the slug. Hand the slug (not the full path) to the other session — it's short enough to say out loud or paste in one line.
write appends a timestamped, tagged entry under a filelock — safe if both sessions happen to write around the same moment.
read prints the pad. Use --tail N once a pad accumulates enough entries that the full dump gets noisy.

When invoked

No slug given, none exists yet: run new, report the printed slug back to the user plainly — they're the one relaying it to the other window.
User wants to leave a note: run write with a --from tag that identifies this session's role or perspective (e.g. the project name, or what lens/angle this session is arguing from) — pick something a human skimming the pad later can use to tell sessions apart.
User wants to check the pad: run read, then summarize or relay the new content in your own words — don't just dump raw file output unless they ask for it verbatim.

Rules

Curate, don't pipe. Never wire this to a file-watcher, hook, or polling loop that auto-forwards content — the value of this tool is the deliberate write step, same judgment call the operator was making by hand before. That was an explicit design choice, not a gap to close later.
Project-scoped, not global. Pads live in ./.stoobz/patchpad/, gitignored session artifacts like the rest of .stoobz/ — not committed history, not a cross-project mailbox.
Don't invent a slug. Always let new generate it (collision-checked on creation); a hand-picked slug risks colliding with an existing pad.

Patchpad

Usage

patchpad is a self-contained uv run --script CLI, symlinked onto PATH — invoke it directly, no absolute path needed:

patchpad new [--note "purpose"] patchpad write <slug> "<message>" [--from <label>] patchpad read <slug> [--tail N]

new creates ./.stoobz/patchpad/<slug>.md in the current project and prints the slug. Hand the slug (not the full path) to the other session — it's short enough to say out loud or paste in one line.

write appends a timestamped, tagged entry under a filelock — safe if both sessions happen to write around the same moment.

read prints the pad. Use --tail N once a pad accumulates enough entries that the full dump gets noisy.

When invoked

No slug given, none exists yet: run new, report the printed slug back to the user plainly — they're the one relaying it to the other window.

User wants to leave a note: run write with a --from tag that identifies this session's role or perspective (e.g. the project name, or what lens/angle this session is arguing from) — pick something a human skimming the pad later can use to tell sessions apart.

User wants to check the pad: run read, then summarize or relay the new content in your own words — don't just dump raw file output unless they ask for it verbatim.

Rules

Curate, don't pipe. Never wire this to a file-watcher, hook, or polling loop that auto-forwards content — the value of this tool is the deliberate write step, same judgment call the operator was making by hand before. That was an explicit design choice, not a gap to close later.

Project-scoped, not global. Pads live in ./.stoobz/patchpad/, gitignored session artifacts like the rest of .stoobz/ — not committed history, not a cross-project mailbox.

Don't invent a slug. Always let new generate it (collision-checked on creation); a hand-picked slug risks colliding with an existing pad.