task-coordination-strategies

Name: task-coordination-strategies
Author: wshobson

38kstars4.1kforks

How to install task-coordination-strategies?

wshobson/agents/task-coordination-strategies

$npx -y skills add wshobson/agents --skill task-coordination-strategies

Installs into the current project.

Summary

Decompose complex tasks, design dependency graphs, and coordinate multi-agent work with proper task descriptions and workload balancing. Use this skill when breaking down work for agent teams, managing task dependencies, or monitoring team progress.

Files · 1

View on GitHub

SKILL.md

1	# Task Coordination Strategies
2
3	Strategies for decomposing complex tasks into parallelizable units, designing dependency graphs, writing effective task descriptions, and monitoring workload across agent teams.
4
5	## When to Use This Skill
6
7	- Breaking down a complex task for parallel execution
8	- Designing task dependency relationships (blockedBy/blocks)
9	- Writing task descriptions with clear acceptance criteria
10	- Monitoring and rebalancing workload across teammates
11	- Identifying the critical path in a multi-task workflow
12
13	## Task Decomposition Strategies
14
15	### By Layer
16
17	Split work by architectural layer:
18
19	- Frontend components
20	- Backend API endpoints
21	- Database migrations/models
22	- Test suites
23
24	Best for: Full-stack features, vertical slices
25
26	### By Component
27
28	Split work by functional component:
29
30	- Authentication module
31	- User profile module
32	- Notification module
33
34	Best for: Microservices, modular architectures
35
36	### By Concern
37
38	Split work by cross-cutting concern:
39
40	- Security review
41	- Performance review
42	- Architecture review
43
44	Best for: Code reviews, audits
45
46	### By File Ownership
47
48	Split work by file/directory boundaries:
49
50	- `src/components/` — Implementer 1
51	- `src/api/` — Implementer 2
52	- `src/utils/` — Implementer 3
53
54	Best for: Parallel implementation, conflict avoidance
55
56	## Dependency Graph Design
57
58	### Principles
59
60	1. Minimize chain depth — Prefer wide, shallow graphs over deep chains
61	2. Identify the critical path — The longest chain determines minimum completion time
62	3. Use blockedBy sparingly — Only add dependencies that are truly required
63	4. Avoid circular dependencies — Task A blocks B blocks A is a deadlock
64
65	### Patterns
66
67	Independent (Best parallelism):
68
69	```
70	Task A ─┐
71	Task B ─┼─→ Integration
72	Task C ─┘
73	```
74
75	Sequential (Necessary dependencies):
76
77	```
78	Task A → Task B → Task C
79	```
80
81	Diamond (Mixed):
82
83	```
84	┌→ Task B ─┐
85	Task A ─┤ ├→ Task D
86	└→ Task C ─┘
87	```
88
89	### Using blockedBy/blocks
90
91	```
92	TaskCreate: { subject: "Build API endpoints" } → Task #1
93	TaskCreate: { subject: "Build frontend components" } → Task #2
94	TaskCreate: { subject: "Integration testing" } → Task #3
95	TaskUpdate: { taskId: "3", addBlockedBy: ["1", "2"] } → #3 waits for #1 and #2
96	```
97
98	## Task Description Best Practices
99
100	Every task should include:
101
102	1. Objective — What needs to be accomplished (1-2 sentences)
103	2. Owned Files — Explicit list of files/directories this teammate may modify
104	3. Requirements — Specific deliverables or behaviors expected
105	4. Interface Contracts — How this work connects to other teammates' work
106	5. Acceptance Criteria — How to verify the task is done correctly
107	6. Scope Boundaries — What is explicitly out of scope
108
109	### Template
110
111	```
112	## Objective
113	Build the user authentication API endpoints.
114
115	## Owned Files
116	- src/api/auth.ts
117	- src/api/middleware/auth-middleware.ts
118	- src/types/auth.ts (shared — read only, do not modify)
119
120	## Requirements
121	- POST /api/login — accepts email/password, returns JWT
122	- POST /api/register — creates new user, returns JWT
123	- GET /api/me — returns current user profile (requires auth)
124
125	## Interface Contract
126	- Import User type from src/types/auth.ts (owned by implementer-1)
127	- Export AuthResponse type for frontend consumption
128
129	## Acceptance Criteria
130	- All endpoints return proper HTTP status codes
131	- JWT tokens expire after 24 hours
132	- Passwords are hashed with bcrypt
133
134	## Out of Scope
135	- OAuth/social login
136	- Password reset flow
137	- Rate limiting
138	```
139
140	## Workload Monitoring
141
142	### Indicators of Imbalance
143
144	\| Signal \| Meaning \| Action \|
145	\| -------------------------- \| ------------------- \| --------------------------- \|
146	\| Teammate idle, others busy \| Uneven distribution \| Reassign pending tasks \|
147	\| Teammate stuck on one task \| Possible blocker \| Check in, offer help \|
148	\| All tasks blocked \| Dependency issue \| Resolve critical path first \|
149	\| One teammate has 3x others \| Overloaded \| Split tasks or reassign \|
150
151	### Rebalancing Steps
152
153	1. Call `TaskList` to assess current state
154	2. Identify idle or overloaded teammates
155	3. Use `TaskUpdate` to reassign tasks
156	4. Use `SendMessage` to notify affected teammates
157	5. Monitor for improved throughput

People who liked this also viewed

6 picks

Type

task-coordination-strategies

38kstars4.1kforks

View on GitHub

How to install task-coordination-strategies?

wshobson/agents/task-coordination-strategies

$npx -y skills add wshobson/agents --skill task-coordination-strategies

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Task Coordination Strategies
2
3	Strategies for decomposing complex tasks into parallelizable units, designing dependency graphs, writing effective task descriptions, and monitoring workload across agent teams.
4
5	## When to Use This Skill
6
7	- Breaking down a complex task for parallel execution
8	- Designing task dependency relationships (blockedBy/blocks)
9	- Writing task descriptions with clear acceptance criteria
10	- Monitoring and rebalancing workload across teammates
11	- Identifying the critical path in a multi-task workflow
12
13	## Task Decomposition Strategies
14
15	### By Layer
16
17	Split work by architectural layer:
18
19	- Frontend components
20	- Backend API endpoints
21	- Database migrations/models
22	- Test suites
23
24	Best for: Full-stack features, vertical slices
25
26	### By Component
27
28	Split work by functional component:
29
30	- Authentication module
31	- User profile module
32	- Notification module
33
34	Best for: Microservices, modular architectures
35
36	### By Concern
37
38	Split work by cross-cutting concern:
39
40	- Security review
41	- Performance review
42	- Architecture review
43
44	Best for: Code reviews, audits
45
46	### By File Ownership
47
48	Split work by file/directory boundaries:
49
50	- `src/components/` — Implementer 1
51	- `src/api/` — Implementer 2
52	- `src/utils/` — Implementer 3
53
54	Best for: Parallel implementation, conflict avoidance
55
56	## Dependency Graph Design
57
58	### Principles
59
60	1. Minimize chain depth — Prefer wide, shallow graphs over deep chains
61	2. Identify the critical path — The longest chain determines minimum completion time
62	3. Use blockedBy sparingly — Only add dependencies that are truly required
63	4. Avoid circular dependencies — Task A blocks B blocks A is a deadlock
64
65	### Patterns
66
67	Independent (Best parallelism):
68
69	```
70	Task A ─┐
71	Task B ─┼─→ Integration
72	Task C ─┘
73	```
74
75	Sequential (Necessary dependencies):
76
77	```
78	Task A → Task B → Task C
79	```
80
81	Diamond (Mixed):
82
83	```
84	┌→ Task B ─┐
85	Task A ─┤ ├→ Task D
86	└→ Task C ─┘
87	```
88
89	### Using blockedBy/blocks
90
91	```
92	TaskCreate: { subject: "Build API endpoints" } → Task #1
93	TaskCreate: { subject: "Build frontend components" } → Task #2
94	TaskCreate: { subject: "Integration testing" } → Task #3
95	TaskUpdate: { taskId: "3", addBlockedBy: ["1", "2"] } → #3 waits for #1 and #2
96	```
97
98	## Task Description Best Practices
99
100	Every task should include:
101
102	1. Objective — What needs to be accomplished (1-2 sentences)
103	2. Owned Files — Explicit list of files/directories this teammate may modify
104	3. Requirements — Specific deliverables or behaviors expected
105	4. Interface Contracts — How this work connects to other teammates' work
106	5. Acceptance Criteria — How to verify the task is done correctly
107	6. Scope Boundaries — What is explicitly out of scope
108
109	### Template
110
111	```
112	## Objective
113	Build the user authentication API endpoints.
114
115	## Owned Files
116	- src/api/auth.ts
117	- src/api/middleware/auth-middleware.ts
118	- src/types/auth.ts (shared — read only, do not modify)
119
120	## Requirements
121	- POST /api/login — accepts email/password, returns JWT
122	- POST /api/register — creates new user, returns JWT
123	- GET /api/me — returns current user profile (requires auth)
124
125	## Interface Contract
126	- Import User type from src/types/auth.ts (owned by implementer-1)
127	- Export AuthResponse type for frontend consumption
128
129	## Acceptance Criteria
130	- All endpoints return proper HTTP status codes
131	- JWT tokens expire after 24 hours
132	- Passwords are hashed with bcrypt
133
134	## Out of Scope
135	- OAuth/social login
136	- Password reset flow
137	- Rate limiting
138	```
139
140	## Workload Monitoring
141
142	### Indicators of Imbalance
143
144	\| Signal \| Meaning \| Action \|
145	\| -------------------------- \| ------------------- \| --------------------------- \|
146	\| Teammate idle, others busy \| Uneven distribution \| Reassign pending tasks \|
147	\| Teammate stuck on one task \| Possible blocker \| Check in, offer help \|
148	\| All tasks blocked \| Dependency issue \| Resolve critical path first \|
149	\| One teammate has 3x others \| Overloaded \| Split tasks or reassign \|
150
151	### Rebalancing Steps
152
153	1. Call `TaskList` to assess current state
154	2. Identify idle or overloaded teammates
155	3. Use `TaskUpdate` to reassign tasks
156	4. Use `SendMessage` to notify affected teammates
157	5. Monitor for improved throughput

People who liked this also viewed

6 picks

Type