Task Coordination Strategies
Strategies for decomposing complex tasks into parallelizable units, designing dependency graphs, writing effective task descriptions, and monitoring workload across agent teams.
When to Use This Skill
- •Breaking down a complex task for parallel execution
- •Designing task dependency relationships (blockedBy/blocks)
- •Writing task descriptions with clear acceptance criteria
- •Monitoring and rebalancing workload across teammates
- •Identifying the critical path in a multi-task workflow
Task Decomposition Strategies
By Layer
Split work by architectural layer:
- •Frontend components
- •Backend API endpoints
- •Database migrations/models
- •Test suites
Best for: Full-stack features, vertical slices
By Component
Split work by functional component:
- •Authentication module
- •User profile module
- •Notification module
Best for: Microservices, modular architectures
By Concern
Split work by cross-cutting concern:
- •Security review
- •Performance review
- •Architecture review
Best for: Code reviews, audits
By File Ownership
Split work by file/directory boundaries:
- •
src/components/— Implementer 1 - •
src/api/— Implementer 2 - •
src/utils/— Implementer 3
Best for: Parallel implementation, conflict avoidance
Dependency Graph Design
Principles
- •Minimize chain depth — Prefer wide, shallow graphs over deep chains
- •Identify the critical path — The longest chain determines minimum completion time
- •Use blockedBy sparingly — Only add dependencies that are truly required
- •Avoid circular dependencies — Task A blocks B blocks A is a deadlock
Patterns
Independent (Best parallelism):
code
Task A ─┐ Task B ─┼─→ Integration Task C ─┘
Sequential (Necessary dependencies):
code
Task A → Task B → Task C
Diamond (Mixed):
code
┌→ Task B ─┐
Task A ─┤ ├→ Task D
└→ Task C ─┘
Using blockedBy/blocks
code
TaskCreate: { subject: "Build API endpoints" } → Task #1
TaskCreate: { subject: "Build frontend components" } → Task #2
TaskCreate: { subject: "Integration testing" } → Task #3
TaskUpdate: { taskId: "3", addBlockedBy: ["1", "2"] } → #3 waits for #1 and #2
Task Description Best Practices
Every task should include:
- •Objective — What needs to be accomplished (1-2 sentences)
- •Owned Files — Explicit list of files/directories this teammate may modify
- •Requirements — Specific deliverables or behaviors expected
- •Interface Contracts — How this work connects to other teammates' work
- •Acceptance Criteria — How to verify the task is done correctly
- •Scope Boundaries — What is explicitly out of scope
Template
code
## Objective Build the user authentication API endpoints. ## Owned Files - src/api/auth.ts - src/api/middleware/auth-middleware.ts - src/types/auth.ts (shared — read only, do not modify) ## Requirements - POST /api/login — accepts email/password, returns JWT - POST /api/register — creates new user, returns JWT - GET /api/me — returns current user profile (requires auth) ## Interface Contract - Import User type from src/types/auth.ts (owned by implementer-1) - Export AuthResponse type for frontend consumption ## Acceptance Criteria - All endpoints return proper HTTP status codes - JWT tokens expire after 24 hours - Passwords are hashed with bcrypt ## Out of Scope - OAuth/social login - Password reset flow - Rate limiting
Workload Monitoring
Indicators of Imbalance
| Signal | Meaning | Action |
|---|---|---|
| Teammate idle, others busy | Uneven distribution | Reassign pending tasks |
| Teammate stuck on one task | Possible blocker | Check in, offer help |
| All tasks blocked | Dependency issue | Resolve critical path first |
| One teammate has 3x others | Overloaded | Split tasks or reassign |
Rebalancing Steps
- •Call
TaskListto assess current state - •Identify idle or overloaded teammates
- •Use
TaskUpdateto reassign tasks - •Use
SendMessageto notify affected teammates - •Monitor for improved throughput