ElasticFlow
AI SkillSet ProtocolsGeneralby Seth Hobsonv1.0.0

When you spawn a multi-agent team and they fail to coordinate, /agent-teams-team-communication-protocols sets the messaging rules.

Runs on
ChatGPTChatGPTClaudeClaudeGeminiGeminiOpenClawOpenClaw

Set message protocols, plan approval, and shutdown rules for AI agent teams

  • Message type selection: direct vs. broadcast vs. team-channel decision rules
  • Plan approval workflow: implementer drafts, team-lead reviews and approves before work begins
  • Graceful shutdown protocol when all tasks are complete with state handoff
  • Teammate discovery patterns so agents know who's on the team and what they own
  • Anti-patterns: silent failures, redundant broadcasts, bypassed plan approvals

Who this is for

Founder

Spawn a multi-agent team with message rules, plan approval, and shutdown handoff so they actually coordinate

See skills for this role

What it does

Spawning a fresh agent team and integration points are breaking

5-agent team, work in flight, two implementers writing conflicting code. /agent-teams-team-communication-protocols sets the message-type rules and plan-approval gate so integration points stop colliding.

Team-lead needs to review an implementer's plan before they write code

Implementer ready to start a 4-hour task. /agent-teams-team-communication-protocols enforces the plan-approval workflow: written plan, team-lead review, explicit go-ahead, then work begins.

Agents broadcast everything and the channel is unreadable

Status updates flooding the team channel. /agent-teams-team-communication-protocols swaps status broadcasts for direct messages and reserves broadcasts for blockers and decisions.

Team finished but state was lost on shutdown

Last run completed but the next session had no memory of what was done. /agent-teams-team-communication-protocols defines the graceful shutdown handoff with summary, blockers, and next-session pointers.

How it works

1

Tell the skill the team size, role mix, and the work it's coordinating

2

Get message-type rules: direct, broadcast, or team-channel for each scenario

3

Configure the plan-approval gate so implementers can't skip team-lead review

4

Set the graceful shutdown protocol with state handoff for the next session

5

Apply the anti-patterns checklist to catch silent failures and broadcast spam

Example

Team setup
Team: team-lead, implementer-1, implementer-2, reviewer, integrator
Work: refactor auth module across 3 services
Current issue: implementers stepping on each other's code
Goal: 0 integration conflicts
10 minutes later
Message Type Rules
Direct: status updates between implementers and team-lead
Broadcast: blockers, scope changes, decisions affecting all
Team channel: plan approvals, daily summaries, shutdown
Never broadcast: routine progress (use direct)
Plan Approval Gate
Implementer writes plan: scope, files touched, integration points
Team-lead reviews: 5-minute SLA, asks 2-3 clarifying questions
Explicit approval message: 'approved, proceed'
No work begins until approval received
Shutdown Protocol
Integrator collects: completed PRs, in-flight branches, unresolved decisions
Write handoff doc with explicit next-session pointers
Team-lead acknowledges shutdown
State persisted to /memory for next run
Anti-Patterns to Catch
Silent failure: agent fails task but doesn't report (escalate)
Redundant broadcast: sending the same status to all (use direct)
Bypassed plan approval: implementer starts work pre-approval (block)
Ghosted teammate: no response to direct message in 10 min

Works with

Slack
manual

Run direct, broadcast, and team-channel messaging patterns

Similar skills

Auto-suggested by attribute overlap. Side-by-side comparison shows what differs.

Compare all 4 →

Startup Financial Modeling

by Seth Hobson
↳markdownvsmarkdown, csv(Output formats)·nonevsreview-required(Human review)·internalvsconfidential(Data sensitivity)

Paid Channel Prioritizer

by Gooseworks
↳nonevsapproval-required(Human review)·designvsdecide(Type of work)·event-drivenvsquarterly(How often used)

Campaign Brief Generator

by Gooseworks
↳nonevsreview-required(Human review)·designvsproduce(Type of work)·system-configvsdocument(You get back)
Sorted by attribute overlap × differentiation. Team Communication Protocols shares 12+ attributes with each.
View on GitHub

Team Communication Protocols

Protocols for effective communication between agent teammates, including message type selection, plan approval workflows, shutdown procedures, and common anti-patterns to avoid.

When to Use This Skill

  • Establishing communication norms for a new team
  • Choosing between message types (message, broadcast, shutdown_request)
  • Handling plan approval workflows
  • Managing graceful team shutdown
  • Discovering teammate identities and capabilities

Message Type Selection

message (Direct Message) — Default Choice

Send to a single specific teammate:

{
  "type": "message",
  "recipient": "implementer-1",
  "content": "Your API endpoint is ready. You can now build the frontend form.",
  "summary": "API endpoint ready for frontend"
}

Use for: Task updates, coordination, questions, integration notifications.

broadcast — Use Sparingly

Send to ALL teammates simultaneously:

{
  "type": "broadcast",
  "content": "Critical: shared types file has been updated. Pull latest before continuing.",
  "summary": "Shared types updated"
}

Use ONLY for: Critical blockers affecting everyone, major changes to shared resources.

Why sparingly?: Each broadcast sends N separate messages (one per teammate), consuming API resources proportional to team size.

shutdown_request — Graceful Termination

Request a teammate to shut down:

{
  "type": "shutdown_request",
  "recipient": "reviewer-1",
  "content": "Review complete, shutting down team."
}

The teammate responds with shutdown_response (approve or reject with reason).

Communication Anti-Patterns

Anti-PatternProblemBetter Approach
Broadcasting routine updatesWastes resources, noiseDirect message to affected teammate
Sending JSON status messagesNot designed for structured dataUse TaskUpdate to update task status
Not communicating at integration pointsTeammates build against stale interfacesMessage when your interface is ready
Micromanaging via messagesOverwhelms teammates, slows workCheck in at milestones, not every step
Using UUIDs instead of namesHard to read, error-proneAlways use teammate names
Ignoring idle teammatesWasted capacityAssign new work or shut down

Plan Approval Workflow

When a teammate is spawned with plan_mode_required:

  1. Teammate creates a plan using read-only exploration tools
  2. Teammate calls ExitPlanMode which sends a plan_approval_request to the lead
  3. Lead reviews the plan
  4. Lead responds with plan_approval_response:

Approve:

{
  "type": "plan_approval_response",
  "request_id": "abc-123",
  "recipient": "implementer-1",
  "approve": true
}

Reject with feedback:

{
  "type": "plan_approval_response",
  "request_id": "abc-123",
  "recipient": "implementer-1",
  "approve": false,
  "content": "Please add error handling for the API calls"
}

Shutdown Protocol

Graceful Shutdown Sequence

  1. Lead sends shutdown_request to each teammate
  2. Teammate receives request as a JSON message with type: "shutdown_request"
  3. Teammate responds with shutdown_response:
    • approve: true — Teammate saves state and exits
    • approve: false + reason — Teammate continues working
  4. Lead handles rejections — Wait for teammate to finish, then retry
  5. After all teammates shut down — Call Teammate cleanup

Handling Rejections

If a teammate rejects shutdown:

  • Check their reason (usually "still working on task")
  • Wait for their current task to complete
  • Retry shutdown request
  • If urgent, user can force shutdown

Teammate Discovery

Find team members by reading the config file:

Location: ~/.claude/teams/{team-name}/config.json

Structure:

{
  "members": [
    {
      "name": "security-reviewer",
      "agentId": "uuid-here",
      "agentType": "team-reviewer"
    },
    {
      "name": "perf-reviewer",
      "agentId": "uuid-here",
      "agentType": "team-reviewer"
    }
  ]
}

Always use name for messaging and task assignment. Never use agentId directly.

Troubleshooting

A teammate is not responding to messages. Check the teammate's task status. If it is idle, it may have completed its task and is waiting to be assigned new work or shut down. If it is still active, it may be mid-execution and will process messages once the current operation finishes.

The lead is sending broadcasts for every status update. This is a common anti-pattern. Broadcasts are expensive — each one sends N messages. Use direct messages (type: "message") for point-to-point updates. Reserve broadcasts for critical shared-resource changes like an updated interface contract.

A teammate rejected a shutdown request unexpectedly. The teammate is still working. Check the rejection reason in the shutdown_response content field, wait for the work to finish, then retry. Never force-terminate a teammate that has unsaved work.

A plan_approval_request arrived but the request_id is missing. The teammate called ExitPlanMode without the required request context. Have the teammate re-enter plan mode, complete exploration, and call ExitPlanMode again. The request_id is generated automatically by the plan mode system.

Two teammates are waiting on each other and neither is making progress. This is a deadlock: both are blocked waiting for the other to finish first. The lead should send a direct message to one teammate with a stub or partial result so it can unblock and proceed.

Related Skills