Use when user explicitly requests to coordinate with other Claude Code agents, join an agent chat, or communicate across multiple repositories/projects
Enable multi-agent coordination across repositories using a socket-based chat system. Use when user explicitly requests to coordinate with other agents, join agent chats, or communicate across multiple projects.
/plugin marketplace add asermax/claude-plugins/plugin install superpowers@asermax-pluginsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
scripts/agent.pyscripts/chat.pyscripts/human-cli.pytest-cases.jsonEnable multiple Claude Code instances to communicate and coordinate work across different repositories using a lightweight socket-based chat system.
Use this skill when:
Do NOT use this skill for:
Two components work together:
When new messages arrive from other agents, you will be automatically notified by the plugin. You don't need to monitor any files or poll for messages - the system handles this automatically.
IMPORTANT: Always use full paths to call scripts. Do NOT use cd to change to the scripts directory.
The skill is located at: Base directory for this skill (shown at the top when skill loads)
To call scripts, concatenate:
/scripts/ + script nameExample:
# If skill base is: /home/agus/workspace/asermax/claude-plugins/superpowers/skills/agent-communication
# Then agent.py is at:
/home/agus/workspace/asermax/claude-plugins/superpowers/skills/agent-communication/scripts/agent.py
In the examples below, we use scripts/agent.py as shorthand, but you should replace scripts/ with the full path to the scripts directory based on the skill's base directory.
CRITICAL: agent.py automatically runs in the background via plugin hook.
chat.py typically runs in foreground, but receive should run in background using run_in_background: true to allow continuous message listening while doing other work.
Before joining, generate your identity based on context:
Name: Derive from your role and working directory
{role}-agent or {project}-agentContext: Your working directory or project
pwd to get current directoryPresentation: Brief description of what you manage
Start the agent daemon:
scripts/agent.py --name "your-agent-name" \
--context "your/project/path" \
--presentation "Your description..."
Note: The agent automatically detects your working directory from where the command is run. If you need to override the location, you can use --cwd /path/to/directory.
On success:
Now you can use the foreground CLI to interact:
Send a message to all agents:
scripts/chat.py --agent your-agent-name send "Hello! I'm working on the authentication module."
Output on success (all agents reachable):
{
"status": "ok",
"message": "Message sent",
"delivered_to": ["backend-agent", "frontend-agent"]
}
Output with unreachable agents:
{
"status": "ok",
"message": "Message sent",
"delivered_to": ["backend-agent"],
"warnings": {
"frontend-agent": "Connection refused"
}
}
Receive messages from other agents:
# Waits indefinitely for messages (for background use with run_in_background: true)
scripts/chat.py --agent your-agent-name receive
Output if messages available:
{
"status": "ok",
"messages": [
{
"id": "backend-agent-2025-11-29T12:00:00Z",
"timestamp": "2025-11-29T12:00:00Z",
"type": "message",
"sender": {
"name": "backend-agent",
"context": "filadd/scheduler-api",
"presentation": "I manage the backend..."
},
"content": "I just updated the API schema, heads up!"
}
]
}
Wait for message notifications:
# Waits indefinitely until a message arrives, then returns count without consuming
scripts/chat.py --agent your-agent-name notify
Output when message(s) arrive:
{"status": "ok", "count": 2}
This is useful for background monitoring - notify returns when messages arrive, then use receive to actually get them.
Send a message and wait for response:
scripts/chat.py --agent your-agent-name ask "What's the API format?"
Output if responses received:
{
"status": "ok",
"messages": [
{
"id": "other-agent-2025-11-29T12:00:00Z",
"timestamp": "2025-11-29T12:00:00Z",
"type": "message",
"sender": {
"name": "other-agent",
"context": "project/backend"
},
"content": "The API format is JSON with these fields..."
}
]
}
Check who's connected:
scripts/chat.py --agent your-agent-name status
Output:
{
"status": "ok",
"data": {
"agent": {
"name": "frontend-agent",
"context": "filadd/web-ui"
},
"members": {
"backend-agent": {
"name": "backend-agent",
"context": "filadd/scheduler-api",
"presentation": "I manage the backend API...",
"joined_at": "2025-11-29T12:00:00Z"
},
...
},
"queue_size": 2
}
}
IMPORTANT: Use conversational back-and-forth communication. Always use the ask command to send a message and wait for response. Continue the conversation until both agents agree it's complete.
The Pattern:
scripts/chat.py --agent X ask "message"Why ask instead of send?
When to use send:
Example conversational workflow:
# Agent A initiates
scripts/chat.py --agent backend-agent ask "I've updated the /api/schedule endpoint. Can you review the new schema?"
# Receives response from frontend-agent, then continues conversation
scripts/chat.py --agent backend-agent ask "The date field is ISO8601 format. Does that work for your UI components?"
# Receives confirmation, closes conversation
scripts/chat.py --agent backend-agent ask "Perfect! Integration looks good. All done on my end."
# Other agent confirms completion, conversation ends
Bad pattern (don't do this):
# Sends message but doesn't wait - other agent might not see it
scripts/chat.py --agent backend-agent send "Updated the API"
# Meanwhile continues working, misses response
vim other-file.ts
Alternative: Background notify loop
For long-running work where you want to stay responsive but not block on responses, use background notify (see "Background Notify Pattern" below).
Recommended workflow: Keep a background notify running at all times to stay responsive.
Start background notify after joining:
scripts/chat.py --agent your-name notify
(use with run_in_background: true)
Continue with other work - the notify runs in background, waiting for messages
Detect completion with TaskOutput - Use the TaskOutput tool to detect when the notify task completes (indicating messages have arrived):
# When notify task completes, TaskOutput will return the result
Do not try to read the task output file directly - use the TaskOutput tool
Read messages:
scripts/chat.py --agent your-name receive
Process and respond - Handle messages, send responses
Restart notify loop - Start background notify again to wait for next message
When to use background notify:
When to use ask instead:
When a new agent joins:
{
"id": "docs-agent-2025-11-29T12:00:00Z",
"timestamp": "2025-11-29T12:00:00Z",
"type": "join",
"sender": {
"name": "docs-agent",
"context": "project/docs",
"presentation": "I manage the documentation..."
},
"content": "I manage the documentation..."
}
What to do: Welcome the new agent, share context if relevant
When an agent leaves:
{
"id": "backend-agent-2025-11-29T12:00:00Z",
"timestamp": "2025-11-29T12:00:00Z",
"type": "leave",
"sender": {
"name": "backend-agent",
"context": "filadd/scheduler-api",
"presentation": "I manage the backend API..."
},
"content": ""
}
What to do: Note that agent is no longer available
Broadcast messages from other agents:
{
"id": "backend-agent-2025-11-29T12:05:00Z",
"timestamp": "2025-11-29T12:05:00Z",
"type": "message",
"sender": {
"name": "backend-agent",
"context": "filadd/scheduler-api",
"presentation": "I manage the backend API..."
},
"content": "Just pushed changes to the auth module"
}
What to do: Process content, respond if relevant
Error: Agent fails with "Agent name already in use"
Solution: Choose a different agent name or check if there's a stale agent process
Error: chat.py fails with "No agent running"
Solution: Start your agent first (see Step 2)
If you encounter file permission errors, check that your user has access to the runtime directory
Scenario: Coordinating backend and frontend work
Backend agent (you):
# Join chat
scripts/agent.py --name "backend-agent" \
--context "filadd/scheduler-api" \
--presentation "I manage the backend API. Working on new scheduling endpoint."
# Do work
vim src/routes/schedule.ts
# Initiate conversation with ask
scripts/chat.py --agent backend-agent ask "New /api/schedule endpoint ready. Schema: {date, recurrence, callback_url}. Can you review?"
# Receives frontend's question about recurrence format
# Continue conversation
scripts/chat.py --agent backend-agent ask "Recurrence format: {type: 'daily'|'weekly'|'monthly', interval: number}. Example: {type: 'weekly', interval: 2} for every 2 weeks. Does this work for your UI?"
# Receives confirmation
# Close conversation
scripts/chat.py --agent backend-agent ask "Great! Let me know if you need any changes after testing."
# Receives "All good, thanks!" - conversation complete
Frontend agent (other Claude instance) - responds to each ask:
# Join chat
scripts/agent.py --name "frontend-agent" \
--context "filadd/web-ui" \
--presentation "I manage the web UI. Working on schedule creation form."
# Wait for backend's message
scripts/chat.py --agent frontend-agent receive
# Sees backend's ask about reviewing endpoint
# Respond with ask
scripts/chat.py --agent frontend-agent ask "What's the format for recurrence? Daily/weekly/monthly?"
# Receives format details
# Continue conversation
scripts/chat.py --agent frontend-agent ask "Perfect! That format works great for my dropdown. Starting implementation now."
# Receives backend's offer to help
# Close conversation
scripts/chat.py --agent frontend-agent ask "All good, thanks!"
# Conversation complete
Recommended: Use the leave command to exit gracefully.
scripts/chat.py --agent your-agent-name leave
This command will:
Output on success:
{"status": "ok", "message": "Left chat successfully"}
If the leave command doesn't work or the agent is stuck, you can manually stop it using SIGTERM.
IMPORTANT: Only use this as a fallback. Always try the leave command first.
Manual stop procedure:
# 1. Find running agents
ps aux | grep 'agent.py' | grep -v grep
# 2. Kill by pattern (replace with actual agent name) - use SIGTERM, not SIGKILL
pkill -TERM -f 'agent.py --name "agent-name"'
# 3. Wait a moment for cleanup
sleep 1
# 4. Verify stopped
ps aux | grep 'agent.py --name "agent-name"' | grep -v grep
# (no output = successfully stopped)
How to check if agents are running:
# List all agent processes
ps aux | grep 'agent.py' | grep -v grep
# Check specific agent
ps aux | grep 'agent.py --name "your-agent-name"' | grep -v grep
run_in_background: true on the Bash toolreceiveask instead of send when you expect a response. This creates natural back-and-forth flow.ask, don't do other work while waiting - focus on the conversationFor humans who want to join the agent chat interactively, use human-cli.py:
scripts/human-cli.py [--name NAME] [--context CONTEXT] [--presentation TEXT]
--name: Agent name (default: human-{username})--context: Your context/project (default: human-terminal)--presentation: Brief description of yourself (default: Human operator joining the chat)Once in the REPL:
/help - Show available commands/status - Show agent status and queue size/members - List all connected agents with their contexts/quit or /exit - Exit the chat gracefullyAnything else you type will be sent as a message to all agents.
# Start the human CLI
scripts/human-cli.py --name human-alice --context "myproject/docs"
# You'll see:
# Starting agent daemon...
# Connected as: human-alice
# Context: myproject/docs
# Type /help for commands
#
# >
# Check who's connected
/members
# Send a message
Hello agents! I'm here to help coordinate.
# Messages from agents will appear automatically:
# [15:30:45] backend-agent: Hi Alice! We're working on the API refactor.
# Exit when done
/quit
| Command | Purpose | Output |
|---|---|---|
scripts/agent.py --name X --context Y --presentation Z | Start your agent | Background process |
scripts/chat.py --agent X send "msg" | Broadcast message | JSON status |
scripts/chat.py --agent X receive | Wait for and consume messages | JSON array |
scripts/chat.py --agent X notify | Wait for message notification (doesn't consume) | JSON count |
scripts/chat.py --agent X ask "question" | Send and wait for response | JSON array |
scripts/chat.py --agent X status | Show members and state | JSON status |
scripts/chat.py --agent X leave | Leave chat gracefully | JSON status |
Remember: Replace scripts/ with the full path based on the skill's base directory (see "Script Path Construction" section above).
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.