team-communication-protocols

Name: team-communication-protocols
Author: wshobson

38kstars4.1kforks

How to install team-communication-protocols?

wshobson/agents/team-communication-protocols

$npx -y skills add wshobson/agents --skill team-communication-protocols

Installs into the current project.

Summary

Structured messaging protocols for agent team communication including message type selection, plan approval, shutdown procedures, and anti-patterns to avoid. Use this skill when establishing communication norms for a newly spawned team, when deciding whether to send a direct mess

Files · 1

View on GitHub

SKILL.md

1	# Team Communication Protocols
2
3	Protocols for effective communication between agent teammates, including message type selection, plan approval workflows, shutdown procedures, and common anti-patterns to avoid.
4
5	## When to Use This Skill
6
7	- Establishing communication norms for a new team
8	- Choosing between message types (message, broadcast, shutdown_request)
9	- Handling plan approval workflows
10	- Managing graceful team shutdown
11	- Discovering teammate identities and capabilities
12
13	## Message Type Selection
14
15	### `message` (Direct Message) — Default Choice
16
17	Send to a single specific teammate:
18
19	```json
20	{
21	"type": "message",
22	"recipient": "implementer-1",
23	"content": "Your API endpoint is ready. You can now build the frontend form.",
24	"summary": "API endpoint ready for frontend"
25	}
26	```
27
28	Use for: Task updates, coordination, questions, integration notifications.
29
30	### `broadcast` — Use Sparingly
31
32	Send to ALL teammates simultaneously:
33
34	```json
35	{
36	"type": "broadcast",
37	"content": "Critical: shared types file has been updated. Pull latest before continuing.",
38	"summary": "Shared types updated"
39	}
40	```
41
42	Use ONLY for: Critical blockers affecting everyone, major changes to shared resources.
43
44	Why sparingly?: Each broadcast sends N separate messages (one per teammate), consuming API resources proportional to team size.
45
46	### `shutdown_request` — Graceful Termination
47
48	Request a teammate to shut down:
49
50	```json
51	{
52	"type": "shutdown_request",
53	"recipient": "reviewer-1",
54	"content": "Review complete, shutting down team."
55	}
56	```
57
58	The teammate responds with `shutdown_response` (approve or reject with reason).
59
60	## Communication Anti-Patterns
61
62	\| Anti-Pattern \| Problem \| Better Approach \|
63	\| --------------------------------------- \| ---------------------------------------- \| -------------------------------------- \|
64	\| Broadcasting routine updates \| Wastes resources, noise \| Direct message to affected teammate \|
65	\| Sending JSON status messages \| Not designed for structured data \| Use TaskUpdate to update task status \|
66	\| Not communicating at integration points \| Teammates build against stale interfaces \| Message when your interface is ready \|
67	\| Micromanaging via messages \| Overwhelms teammates, slows work \| Check in at milestones, not every step \|
68	\| Using UUIDs instead of names \| Hard to read, error-prone \| Always use teammate names \|
69	\| Ignoring idle teammates \| Wasted capacity \| Assign new work or shut down \|
70
71	## Plan Approval Workflow
72
73	When a teammate is spawned with `plan_mode_required`:
74
75	1. Teammate creates a plan using read-only exploration tools
76	2. Teammate calls `ExitPlanMode` which sends a `plan_approval_request` to the lead
77	3. Lead reviews the plan
78	4. Lead responds with `plan_approval_response`:
79
80	Approve:
81
82	```json
83	{
84	"type": "plan_approval_response",
85	"request_id": "abc-123",
86	"recipient": "implementer-1",
87	"approve": true
88	}
89	```
90
91	Reject with feedback:
92
93	```json
94	{
95	"type": "plan_approval_response",
96	"request_id": "abc-123",
97	"recipient": "implementer-1",
98	"approve": false,
99	"content": "Please add error handling for the API calls"
100	}
101	```
102
103	## Shutdown Protocol
104
105	### Graceful Shutdown Sequence
106
107	1. Lead sends shutdown_request to each teammate
108	2. Teammate receives request as a JSON message with `type: "shutdown_request"`
109	3. Teammate responds with `shutdown_response`:
110	- `approve: true` — Teammate saves state and exits
111	- `approve: false` + reason — Teammate continues working
112	4. Lead handles rejections — Wait for teammate to finish, then retry
113	5. After all teammates shut down — Call `TeamDelete` to remove team resources
114
115	### Handling Rejections
116
117	If a teammate rejects shutdown:
118
119	- Check their reason (usually "still working on task")
120	- Wait for their current task to complete
121	- Retry shutdown request
122	- If urgent, user can force shutdown
123
124	## Teammate Discovery
125
126	Find team members by reading the config file:
127
128	Location: `~/.claude/teams/{team-name}/config.json`
129
130	Structure:
131
132	```json
133	{
134	"members": [
135	{
136	"name": "security-reviewer",
137	"agentId": "uuid-here",
138	"agentType": "team-reviewer"
139	},
140	{
141	"name": "perf

People who liked this also viewed

6 picks

Type

team-communication-protocols

38kstars4.1kforks

View on GitHub

How to install team-communication-protocols?

wshobson/agents/team-communication-protocols

$npx -y skills add wshobson/agents --skill team-communication-protocols

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Team Communication Protocols
2
3	Protocols for effective communication between agent teammates, including message type selection, plan approval workflows, shutdown procedures, and common anti-patterns to avoid.
4
5	## When to Use This Skill
6
7	- Establishing communication norms for a new team
8	- Choosing between message types (message, broadcast, shutdown_request)
9	- Handling plan approval workflows
10	- Managing graceful team shutdown
11	- Discovering teammate identities and capabilities
12
13	## Message Type Selection
14
15	### `message` (Direct Message) — Default Choice
16
17	Send to a single specific teammate:
18
19	```json
20	{
21	"type": "message",
22	"recipient": "implementer-1",
23	"content": "Your API endpoint is ready. You can now build the frontend form.",
24	"summary": "API endpoint ready for frontend"
25	}
26	```
27
28	Use for: Task updates, coordination, questions, integration notifications.
29
30	### `broadcast` — Use Sparingly
31
32	Send to ALL teammates simultaneously:
33
34	```json
35	{
36	"type": "broadcast",
37	"content": "Critical: shared types file has been updated. Pull latest before continuing.",
38	"summary": "Shared types updated"
39	}
40	```
41
42	Use ONLY for: Critical blockers affecting everyone, major changes to shared resources.
43
44	Why sparingly?: Each broadcast sends N separate messages (one per teammate), consuming API resources proportional to team size.
45
46	### `shutdown_request` — Graceful Termination
47
48	Request a teammate to shut down:
49
50	```json
51	{
52	"type": "shutdown_request",
53	"recipient": "reviewer-1",
54	"content": "Review complete, shutting down team."
55	}
56	```
57
58	The teammate responds with `shutdown_response` (approve or reject with reason).
59
60	## Communication Anti-Patterns
61
62	\| Anti-Pattern \| Problem \| Better Approach \|
63	\| --------------------------------------- \| ---------------------------------------- \| -------------------------------------- \|
64	\| Broadcasting routine updates \| Wastes resources, noise \| Direct message to affected teammate \|
65	\| Sending JSON status messages \| Not designed for structured data \| Use TaskUpdate to update task status \|
66	\| Not communicating at integration points \| Teammates build against stale interfaces \| Message when your interface is ready \|
67	\| Micromanaging via messages \| Overwhelms teammates, slows work \| Check in at milestones, not every step \|
68	\| Using UUIDs instead of names \| Hard to read, error-prone \| Always use teammate names \|
69	\| Ignoring idle teammates \| Wasted capacity \| Assign new work or shut down \|
70
71	## Plan Approval Workflow
72
73	When a teammate is spawned with `plan_mode_required`:
74
75	1. Teammate creates a plan using read-only exploration tools
76	2. Teammate calls `ExitPlanMode` which sends a `plan_approval_request` to the lead
77	3. Lead reviews the plan
78	4. Lead responds with `plan_approval_response`:
79
80	Approve:
81
82	```json
83	{
84	"type": "plan_approval_response",
85	"request_id": "abc-123",
86	"recipient": "implementer-1",
87	"approve": true
88	}
89	```
90
91	Reject with feedback:
92
93	```json
94	{
95	"type": "plan_approval_response",
96	"request_id": "abc-123",
97	"recipient": "implementer-1",
98	"approve": false,
99	"content": "Please add error handling for the API calls"
100	}
101	```
102
103	## Shutdown Protocol
104
105	### Graceful Shutdown Sequence
106
107	1. Lead sends shutdown_request to each teammate
108	2. Teammate receives request as a JSON message with `type: "shutdown_request"`
109	3. Teammate responds with `shutdown_response`:
110	- `approve: true` — Teammate saves state and exits
111	- `approve: false` + reason — Teammate continues working
112	4. Lead handles rejections — Wait for teammate to finish, then retry
113	5. After all teammates shut down — Call `TeamDelete` to remove team resources
114
115	### Handling Rejections
116
117	If a teammate rejects shutdown:
118
119	- Check their reason (usually "still working on task")
120	- Wait for their current task to complete
121	- Retry shutdown request
122	- If urgent, user can force shutdown
123
124	## Teammate Discovery
125
126	Find team members by reading the config file:
127
128	Location: `~/.claude/teams/{team-name}/config.json`
129
130	Structure:
131
132	```json
133	{
134	"members": [
135	{
136	"name": "security-reviewer",
137	"agentId": "uuid-here",
138	"agentType": "team-reviewer"
139	},
140	{
141	"name": "perf

People who liked this also viewed

6 picks

Type