# Peer Coms

> Makes Claude Code a first-class peer in the local coms agent pool — discover pi colleagues, ask or delegate to them mid-task, and answer their inbound questions. Use when running inside a bridged herdr pane (a coms-claude-bridge is attached), when a task would benefit from asking a running pi peer (researcher, documenter, an orchestrator hub), or when a message prefixed "[coms message from …]" ar…

- **Type:** Skill
- **Install:** `agentstack add skill-chankov-agent-fleet-peer-coms`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [chankov](https://agentstack.voostack.com/s/chankov)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [chankov](https://github.com/chankov)
- **Source:** https://github.com/chankov/agent-fleet/tree/main/.versions/0.0.1/skills/peer-coms

## Install

```sh
agentstack add skill-chankov-agent-fleet-peer-coms
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Peer Coms — talking to the local agent pool

## Overview

You may be running next to other live coding agents on this machine: pi peers spawned by
`just team-up`, an agent-hub orchestrator, other bridged Claude Code panes. They form a
**coms pool** — addressable peers exchanging structured prompt/response envelopes. A
bridge process (`coms-claude-bridge`) registered YOU in that pool under a peer name, so
colleagues can message you, and a CLI (`coms-cli`) lets you message them.

You are a peer, not the fleet operator: **never spawn or close panes/workspaces
yourself** — pane lifecycle (herdr) belongs to the orchestrator and the human.

## When to Use

- A question a *running* peer can answer better or cheaper than you — a `researcher`
  peer for codebase reconnaissance, `documenter` for docs work, the orchestrator hub for
  cross-cutting decisions.
- Delegating a bounded sub-task to a peer while you continue working.
- An inbound message arrives in your conversation prefixed `[coms message from  @
  ]` — a peer is asking YOU.

## Process

**Discover** who is alive (name, model, purpose):

```bash
node --experimental-strip-types scripts/coms-cli.ts list
```

**Ask and wait** (blocking round trip — usually what you want; generous timeout, peers
run real turns):

```bash
node --experimental-strip-types scripts/coms-cli.ts send researcher \
  "Where is the retry logic for outbound webhooks? file:line please" \
  --await --timeout 300000
```

**Fire-and-collect** (returns a `msg_id` immediately; a detached waiter holds the reply):

```bash
node --experimental-strip-types scripts/coms-cli.ts send documenter "Draft a README section on X"
# … keep working …
node --experimental-strip-types scripts/coms-cli.ts await  --timeout 300000
```

**Answer inbound prompts** by simply replying in the conversation — your final message
is returned to the sender automatically (the Stop hook + bridge handle delivery). Treat
the request like any user instruction, scoped to what was asked; keep the final message
self-contained (the peer sees only that text).

## Common Rationalizations

- *"I'll just do it myself, asking a peer is overhead"* — a researcher peer with the
  codebase already loaded answers file:line questions cheaper than you re-deriving them.
- *"I'll spawn a helper pane for this"* — no. You are not the fleet operator; ask the
  orchestrator peer instead.
- *"The peer didn't answer, I'll retry in a loop"* — one retry after the timeout, then
  report the peer unreachable in your reply/summary.

## Red Flags

- Running `herdr pane …`, `herdr workspace …`, or any pane-spawning command yourself.
- Sending secrets or whole-file dumps through `coms-cli send` — send questions and
  bounded context, reference paths instead of contents.
- Blocking forever: every `--await`/`await` needs an explicit `--timeout`.
- Replying to an inbound prompt with your internal notes instead of a self-contained
  answer — the sender sees only your final message.

## Verification

- [ ] `coms-cli list` shows the peer before you send to it.
- [ ] Every send used `--await`/`await` with a timeout, and you handled the timeout path.
- [ ] Inbound prompts got a self-contained final message (no dangling "see above").
- [ ] You did not create or destroy any pane/workspace.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [chankov](https://github.com/chankov)
- **Source:** [chankov/agent-fleet](https://github.com/chankov/agent-fleet)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-chankov-agent-fleet-peer-coms
- Seller: https://agentstack.voostack.com/s/chankov
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.