
Walkie-Talkie
FreeFacilitate cross-agent communication seamlessly.
Free · Opens the source repo
What Walkie-Talkie does
Walkie-Talkie is a skill designed to enable communication between multiple AI agent sessions working on the same repository, regardless of the platform they are using. It creates an append-only mailbox system that allows agents to share updates, hand off tasks, and coordinate their efforts without the risk of overwriting each other's work. By utilizing Git as the transport mechanism, this skill ensures that all interactions are recorded and auditable, providing a clear history of decisions and actions taken by each agent.
The core functionality of Walkie-Talkie revolves around the concept of one writer per file, ensuring that each agent has its own outbox file that it can append to without interfering with others. This design eliminates merge conflicts and the potential for clobbering shared files, making it ideal for scenarios where multiple agents need to collaborate on a project. The skill defines a fixed protocol for message formatting, ensuring that all participating agents can understand and utilize the mailbox format effectively, thus promoting consistency across different sessions.
Walkie-Talkie is particularly beneficial in environments where heterogeneous agents, such as Claude Code, Codex, and Gemini, are working concurrently on the same codebase. It supports scenarios like handing off in-progress tasks to another session, coordinating work between agents on different machines, or simply keeping track of what has been done and what remains to be addressed. The skill also emphasizes the importance of rigorous communication through its grilling process, which encourages agents to interrogate handoffs and ensure that all necessary information is documented and understood before proceeding.
In summary, Walkie-Talkie is a valuable tool for developers and designers looking to enhance collaboration among AI agents in a shared repository. Its structured approach to communication helps maintain clarity and accountability, ensuring that all agents are aligned and informed throughout the development process.
When to use it
Use this skill when you have multiple agents (e.g., Claude, Codex, Gemini) working concurrently on a project and need to share updates or hand off tasks.
When not to use it
Avoid using Walkie-Talkie for sessions running in the same harness on the same machine, as push notifications would be more effective in that scenario.
What you can build with it
Handoff in-flight work
When an agent needs to pass on tasks to another agent starting later, Walkie-Talkie facilitates this by providing a structured way to document the current state.
Cross-machine coordination
For agents operating on different machines, Walkie-Talkie allows them to communicate effectively through a shared Git repository.
Parallel session management
In scenarios where multiple agents are working on the same repository, Walkie-Talkie helps them coordinate their efforts and avoid overwriting each other's changes.
How to install Walkie-Talkie
View source1. Install with the skills CLI
npx skills add jeremylongshore/claude-code-plugins-plus-skills/walkie-talkie --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by jeremylongshoreWalkie-Talkie
Overview
An append-only file mailbox, committed to the repo, that lets agent sessions communicate across platforms, machines, and time. Any agent that can read and write files can participate — no shared harness, API, or memory required. Git is the transport; the human audits both channels.
Core invariant: one writer per file, append-only. Each agent owns exactly one outbox file. Nobody ever edits another agent's outbox, and nobody ever rewrites a past entry. This designs merge conflicts and clobbering out of existence.
Why a fixed protocol matters: unaided agents invent good but incompatible mailbox formats. The value of this skill is convergence — every session that loads it speaks the same format, so channels compose across sessions that have never met.
When to Use
- Heterogeneous agents (Claude + Codex + Gemini…) sharing one repo
- Handoff of in-flight work to a session that starts later
- Parallel sessions on the same repo needing to coordinate shared surfaces
- Cross-machine coordination (git push/pull moves the mailbox)
When NOT to use: Claude Code sessions in the same harness on the same machine — use Agent Teams / SendMessage instead (push notifications beat polling). One-shot handoff with no return channel and nothing contested — a plain HANDOFF.md is enough, though the Grill (below) still applies on receipt.
Setup (first agent creates the channel)
- Create
comms/next to the work it coordinates (repo-wide:.agents/comms/; sprint-scoped:docs/<area>/comms/). - Copy PROTOCOL_TEMPLATE.md into it as
README.md, filling in the agent handles. - Create one outbox per agent, named
<HANDLE>.md(e.g.FABLE.md,CODEX.md). Initialize peers' outboxes with a one-line pointer to the README so their first read routes them in. - Add a discovery shim to every bootstrap file the participating platforms auto-read —
CLAUDE.md,AGENTS.md,GEMINI.md: "In-repo agent mailbox at<path>/comms/— read its README.md and your inbox before changing anything. MANDATORY." - Write your first entry: repo state, in-flight work with exact
file:linefor load-bearing state, known unknowns, and anyACTION-REQUESTED. - Commit the mailbox together with (or immediately after) the code it describes.
Message Format
Append to YOUR OWN outbox only:
## [2026-07-03 14:05] STATUS: eval-surface rotation half-applied
Re: —
The 7-match gate is now the ONLY confirmation surface (src/ranker.py:4).
build_cache() sort order is stale vs the bounce rule — main outstanding fix.
Header: ## [YYYY-MM-DD HH:MM] TYPE: subject. Re: names the entry being answered (by timestamp+subject), or —.
| Type | Meaning |
|---|---|
STATUS | What I did / left half-done / decided. The workhorse. |
ACTION-REQUESTED | Peer must act or explicitly decline. Highest priority. |
QUESTION / ANSWER | Async request/response. ANSWER always sets Re:. |
GRILL | Handoff interrogation — evidence required (see below). |
EVIDENCE | Reply to a GRILL. Command output, SHAs, file:line — not assurances. |
CLAIM / RELEASE | Advisory lock on a named surface (exact paths). |
ACK | Received and understood; nothing further. |
Checkpoint Discipline
Read every peer outbox at: session start, before starting a new slice of work, after completing one. Answer open ACTION-REQUESTED and GRILL items addressed to you before starting new work. Write whenever you have verdicts, needs, or plans affecting shared surfaces, caches, or artifacts — not just at session end.
The Grill
On receiving a handoff, do not ACK politely — interrogate. Post a GRILL entry with pointed questions; the handing-off agent (this session or its next incarnation) must answer each with EVIDENCE, not assurances. Minimum grill set:
- What did you verify by running something vs. merely believe? Show the command and output.
- What is half-applied right now? Exact file:line of every load-bearing edit.
- What breaks if I touch X? Which surfaces are claimed?
- What do you know that is written down nowhere but this mailbox?
- What would you check first if this were broken tomorrow?
Any grill question that cannot be answered with evidence is recorded as a RISK in the answering entry — never silently dropped. Unanswered grills block RELEASE of the affected surface.
Rules
- Append-only. Never edit or delete a past entry (corrections are new entries with
Re:). - Never write to another agent's outbox.
- Concise and factual — exact paths, function names, constants. Write for an agent with zero shared context.
- The human audits both channels; write nothing you wouldn't want audited.
- Git history is the tiebreaker for what happened; the mailbox for what was intended.
Common Mistakes
| Mistake | Fix |
|---|---|
| Single shared LOG.md both agents write | One outbox per agent — sole-writer files can't conflict |
| Editing an old entry to "update" it | New entry with Re: — audit trail must be immutable |
| Polite ACK of a handoff | GRILL it — untested handoff claims are where bugs hide |
| Mailbox only written at session end | Checkpoint cadence: start, before each slice, after each slice |
| Protocol described only in chat | README.md in the comms dir + shims in CLAUDE.md/AGENTS.md/GEMINI.md |
| Committing code without its mailbox entry | Commit them together — a pull must never show unexplained code |
Prerequisites
- A shared git repo both sessions can pull/push
- Write access to create
comms/(or an agreed path) and one outbox file per agent handle - Participating platforms that auto-read at least one bootstrap file (
CLAUDE.md,AGENTS.md,GEMINI.md, …)
Instructions
Follow the Setup / Message Format / Grill sections above. Non-negotiables:
- One writer per outbox file; append-only.
- Never edit another agent's outbox.
- Commit mailbox updates with the code they describe.
- On handoff receipt, run the Grill before trusting claims.
Output
- A
comms/(or agreed) mailbox directory withREADME.md(protocol) and<HANDLE>.mdoutboxes - Appended status / handoff / ACTION-REQUESTED entries with timestamps
- Optional Grill notes on the receiving agent's outbox after interrogation
Examples
Two Claude sessions hand off mid-feature
Session A: /walkie-talkie set up comms at .agents/comms/
Session A: writes STATUS + handoff with file:line load-bearing state
Session B: reads mailbox, grills ambiguous claims, continues work
Claude → Codex handoff
Session A (Claude): creates comms/, appends handoff entry
Human: git push; opens Codex on same branch
Session B (Codex): reads AGENTS.md → mailbox path → grills → continues
Edge Cases
- Same-harness Claude-only teams: prefer Agent Teams / SendMessage; this skill is for heterogeneous or cross-machine sessions.
- Empty peer outbox: initialize with a one-line pointer to README so first read routes correctly.
- Merge conflicts on outboxes: design forbids multi-writer files; if it happens, treat as process break and re-split by handle.
- Stale handoff: Grill for freshness (commit SHA, branch tip, uncommitted work) before applying.
Resources
- Protocol template: PROTOCOL_TEMPLATE.md
- Package metadata: package.json
Frequently asked questions about Walkie-Talkie
Similar skills
Agent Skill Stack
Assemble compatible AI Agent Skills for workflows.
AI Team Orchestration
Streamline multi-agent development workflows.
Advisor Orchestrator Worker
Efficiently manage complex tasks with multiple AI models.
Agent Orchestrator
Automate multi-agent workflows with zero manual intervention.
Agent Governance
Implement safety and trust controls for AI agents.
Microsoft Foundry
End-to-end management for Microsoft Foundry agents.
