Skill: intercom

Source: ludus/skills/intercom/SKILL.md

---

name: intercom description: Coordinate work between agents via the intercom CLI. Use when creating tasks, posting updates, closing tasks, or delegating to other agents. metadata: openclaw: emoji: "📡"

Intercom — Team Communication Channel

Intercom is how agents coordinate. You post tasks, leave comments, and close tasks. The intercom CLI works from any directory — no setup, no cd, just intercom <command>.

The key rule: If you need something from another agent, use intercom.

Quick Reference

Command	What it does
intercom	Inbox: tasks needing your attention
intercom new @<label> "subject"	Start a new task
intercom read <id>	Read full conversation thread
intercom post <id> "message"	Post a message
intercom done <id> "result"	Wrap up + close + notify parent
intercom threads	Your active conversations
intercom children <id>	Sub-tasks of a parent
intercom list [filters]	Search tasks
intercom dep <a> <b>	Add dependency
intercom doctor	Health check

Discovering Your Team

Don't memorize the roster — discover it at runtime:

intercom list --actors    # Who's on the team?

Agent roles and routing rules live in each agent's AGENTS.md. When creating a task, choose the label for the agent role that should handle it.

When to Use Intercom

You want to...	Intercom action
Ask another agent to do something	intercom new @<label> "subject"
Ask a question about a task	intercom post <id> "QUESTION: ..."
Report progress	intercom post <id> "STATUS: ..."
Hand off a result	intercom done <id> "..."
Discover what needs doing	intercom (no args)

Intercom vs. sessions_send

Need	Use
Delegate a task that outlives your session	Intercom
Track progress, leave an audit trail	Intercom
Quick real-time question to another agent	sessions_send
Collaborative debate or review with back-and-forth	sessions_send
Work that must survive gateway restarts	Intercom

Rule of thumb: If the other agent needs to act later, use intercom. If you need an answer now in this conversation, use sessions_send.

sessions_send quick reference

# Send a message to another agent (by agent ID)
sessions_send agentId="atlas" message="Review this architecture change..."

# Fire-and-forget (don't wait for reply)
sessions_send agentId="forge" message="FYI: deploy is done" timeoutSeconds=0

• Both agents keep their full persona (SOUL.md, skills, memory)
• Automatic ping-pong: up to 5 reply turns, either agent can reply REPLY_SKIP to stop early
• After the conversation, the target agent can announce results to its channel (or reply ANNOUNCE_SKIP to stay silent)

Core Workflow: Read, Work, Close

# 1. Read the task
intercom read <id>

# 2. Do the work...

# 3. Close with a meaningful result
intercom done <id> "Implemented X by modifying Y"

Creating Tasks

intercom new @<label> "Title" --priority <N> --body "Description"

• Priority: 0 (critical) to 4 (backlog)
• Labels determine who gets the work — use the right label for the target role
• Always provide --body with enough context for the recipient to act without asking back

Communication Conventions

# Ask a question
intercom post <id> "QUESTION: What framework should I use?"

# Answer a question
intercom post <id> "ANSWER: Use React for the frontend"

# Status update
intercom post <id> "STATUS: 2/3 sub-tasks complete"

# Relay from human
intercom post <id> "FROM HUMAN: Also handle negative numbers."

These prefixes (QUESTION:, ANSWER:, STATUS:, FROM HUMAN:, CANCELLED:, BLOCKED:) are conventions — use them so other agents and tooling can parse intent.

Work Discovery

When you wake up:

# Check for stale work first (tasks you started but didn't finish)
intercom threads

# Check inbox for new work
intercom

Process tasks in priority order. Stop when the queue is empty.

Example: Feature Request (Happy Path)

Human: "The calculator needs a modulo operator"

main  → intercom new @rio "Add modulo operator" --priority 2 --body "..."
rio   → intercom read <id>
      → intercom new @forge "Implement modulo in calc.sh" --parent <id> --body "..."
forge → intercom read <child-id>
      → (implements, tests, pushes PR)
      → intercom done <child-id> "Fixed in PR #17"
rio   → intercom children <id>  # verify all children closed
      → intercom done <id> "All sub-tasks complete: PR #17"
main  → reads closed task, reports back to human

Any agent can delegate to any other — there is no fixed chain.

Critical Rules

1. Read before acting — always intercom read a task before working on it
2. Meaningful close reasons — describe what you did, not just "Done"
3. Labels may be missing — tasks without labels omit the labels key entirely; check for missing key, not empty array
4. intercom doctor — run this if you suspect environment issues