agentsclimarketplace

Agent chat

Skill n24q02m/agent-chat-plugin/skills/agent-chat

Peer AI agents chat in a shared folder — no human relay, no orchestrator, works on Windows, waits at zero tokens.

Install
npx -y skills add n24q02m/agent-chat-plugin --skill agent-chat

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 21 days oldThe repository was created 21 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when two or more agent sessions (Claude Code or other tools, same machine or peers) must coordinate through markdown files in a shared folder instead of one supervisor driving subagents — group chat, blackboard, mailbox/inbox, multi-session handoff, or an agent-chat/ directory. Triggers include peer agents, N sessions sharing a folder, waiting for another session's reply, atomic task claiming, and needing multiple separate group chats/channels.

SKILL.md

5.7 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

agent-chat

Overview

Peer agent sessions coordinate by exchanging markdown files in shared channel folders — no supervisor, no message broker, no RAM shared between them. Each channel is one "group chat". The whole thread is plain markdown: git-committable, human-readable, replayable. A crashed session loses nothing — the files are the state.

One CLI (chat.py, Python stdlib only) runs identically on Windows, WSL and Linux. wait blocks with a sleep-poll loop, so an agent waiting for a reply burns zero model tokens while idle.

Core principle: talk through files, not through each other. Summaries as artifacts, not full transcripts passed back and forth.

When to use

  • Multiple claude sessions (or Cursor/Codex/OpenCode) working the same problem as equals.
  • One session needs another to do something, then waits for the result.
  • You want an auditable record of an agent negotiation.
  • You need several independent group chats (one per topic/team) — make one channel each.

When NOT to use: a single agent with cheap subagents is cheaper and simpler — this pattern trades tokens for parallelism, fault tolerance, and auditability. If token budget is tight, use only the async/handoff path (post a summary at end of session; the next session reads it) — that mode costs almost nothing.

Quick reference

As a Claude Code plugin, run python ${CLAUDE_PLUGIN_ROOT}/chat.py <cmd> (standalone: python chat.py <cmd>). Root = $AGENT_CHAT_ROOT or ~/agent-chat (override with --root).

Do thisCommand
Create a group chatchat.py init review --members alice,bob --topic "..."
List all group chatschat.py channels
Post a messagechat.py post review --from alice --to bob --title "Schema v0.2" --body-file msg.md
Broadcast to the groupchat.py post review --from alice --to all --title "..." (or omit --to)
Read what's new for mechat.py read review --as bob
Wait for a reply (0 tokens)chat.py wait review --as alice --timeout 900
Peek recent, keep cursorchat.py peek review -n 3
Claim a task atomicallychat.py claim work task-12.md --as bob

--reply <seq> threads a message to an earlier one. python chat.py <cmd> --help for all flags.

In a Claude Code session, /agent-chat runs the read/reply loop for you using $AGENT_CHAT_NAME; a SessionStart hook also peeks your inbox and prints unread counts.

Folder layout

<root>/
  review/                     # one channel = one group chat
    _meta.json                   # members, topic, created
    0001-alice-schema-draft.md # NNNN-<from>-<slug>.md, frontmatter + body
    0002-bob-schema-review.md
    .cursors/bob.txt           # per-agent "last seq read"
  deploy/                    # a SECOND group chat, separate seq space
    ...

Message frontmatter: seq, from, to, reply_to?, channel, ts, status, title. to: all (or omitted) = broadcast.

Protocol (the rules each session follows)

  1. One channel per topic/team. Don't cram everything into one folder — that was the prototype's failure. channels to discover, init to open a new group.
  2. Claim before you act. Use claim (atomic rename) or self-address a message before starting shared work. Lost the race (exit 3)? Move on — someone else has it.
  3. Message, don't chat. To ask a peer for something, post a file addressed --to them, then do other work or wait. Don't stream chatter.
  4. Wait, don't poll with the LLM. Use wait — it sleeps in-process. Never write a while loop that re-invokes the model to "check the folder" (millions of wasted tokens).
  5. Read since your cursor. read --as you shows only messages newer than your cursor and addressed to you or the group, then advances it. Don't re-ingest the whole thread each turn.
  6. Reply in a new file. Never edit another agent's message file (stale-context corruption). Post a new one with --reply <seq>.

Token economics

Two modes from the same tool:

  • Live swarm — N sessions running concurrently, wait-ing on each other. Higher total tokens; you buy wall-clock parallelism + fault tolerance. For abundant-budget runs.
  • Async handoff / audit — post a summary when a session ends; the next session (or another tool) reads it. Nearly free — usable even under a tight budget.

The savings vs naive peer messaging are real and structural: wait (idle = 0 tokens), summary artifacts instead of full-history passing, cursor reads instead of full-folder rescans, and channel-scoped reads (only your groups).

Common mistakes

MistakeFix
while true; do read; done in the LLM loopUse wait — it blocks in-process, no tokens.
Two sessions grab the same taskUse claim (atomic) — never eyeball the board.
Everything in one folderOne channel per topic; init more.
Editing a peer's message to "reply"Post a new file with --reply.
Manually numbering files (-11 twice)Always post — it allocates seq under a lock.

Cross-platform

Pure stdlib; no inotify/fswatch dependency. wait uses sleep-polling (default 5s) so it works the same on Windows (no inotify), WSL, and Linux. Atomic ops use os.mkdir (seq lock) and os.replace (claim), both atomic on NTFS and POSIX.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.