home / skills / wshobson / agents / task-coordination-strategies

task-coordination-strategies skill

/plugins/agent-teams/skills/task-coordination-strategies

This skill helps you decompose complex tasks, design dependency graphs, and balance workload across agent teams for efficient multi-agent coordination.

npx playbooks add skill wshobson/agents --skill task-coordination-strategies

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
4.6 KB
---
name: task-coordination-strategies
description: 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.
version: 1.0.2
---

# 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

1. **Minimize chain depth** — Prefer wide, shallow graphs over deep chains
2. **Identify the critical path** — The longest chain determines minimum completion time
3. **Use blockedBy sparingly** — Only add dependencies that are truly required
4. **Avoid circular dependencies** — Task A blocks B blocks A is a deadlock

### Patterns

**Independent (Best parallelism)**:

```
Task A ─┐
Task B ─┼─→ Integration
Task C ─┘
```

**Sequential (Necessary dependencies)**:

```
Task A → Task B → Task C
```

**Diamond (Mixed)**:

```
        ┌→ Task B ─┐
Task A ─┤          ├→ Task D
        └→ Task C ─┘
```

### Using blockedBy/blocks

```
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:

1. **Objective** — What needs to be accomplished (1-2 sentences)
2. **Owned Files** — Explicit list of files/directories this teammate may modify
3. **Requirements** — Specific deliverables or behaviors expected
4. **Interface Contracts** — How this work connects to other teammates' work
5. **Acceptance Criteria** — How to verify the task is done correctly
6. **Scope Boundaries** — What is explicitly out of scope

### Template

```
## 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

1. Call `TaskList` to assess current state
2. Identify idle or overloaded teammates
3. Use `TaskUpdate` to reassign tasks
4. Use `SendMessage` to notify affected teammates
5. Monitor for improved throughput

Overview

This skill decomposes complex work into parallelizable tasks, designs dependency graphs, and coordinates multi-agent teams with clear task descriptions and workload balancing. It helps teams reduce blockers, identify critical paths, and keep progress observable. Use it to define ownership, interfaces, and acceptance criteria for reliable handoffs.

How this skill works

The skill inspects high-level objectives and produces a task breakdown using chosen decomposition strategies (by layer, component, concern, or file ownership). It generates dependency graphs (blockedBy/blocks), highlights the critical path, and creates precise task descriptions with owned files and acceptance criteria. It also recommends monitoring signals and concrete rebalancing actions for uneven workloads.

When to use it

  • Breaking a large feature into parallel work for multiple agents
  • Designing task dependencies to avoid deadlocks and unnecessary chains
  • Writing task descriptions with clear ownership and acceptance criteria
  • Monitoring team workload and reassigning work to improve throughput
  • Identifying and resolving the critical path in a multi-task workflow

Best practices

  • Prefer wide, shallow dependency graphs to minimize end-to-end cycle time
  • Only add blockedBy relationships that are strictly required to avoid unnecessary serialization
  • Include objective, owned files, requirements, interface contracts, acceptance criteria, and scope boundaries in every task
  • Keep task scopes small and testable so tasks can be verified independently
  • Continuously monitor idle/overloaded signals and rebalance early to prevent cascading delays

Example use cases

  • Split a full-stack feature by frontend, backend, DB migration, and tests with an integration task that blocks on each part
  • Create per-component tasks for a microservice migration and map interface contracts between teams
  • Define security, performance, and architecture review tasks that run in parallel against the same codebase
  • Spot and resolve workload imbalance when one agent is overloaded and others are idle by reassigning subtasks
  • Design a diamond-shaped dependency graph where two parallel tasks feed into a shared integration task

FAQ

How do I decide which decomposition strategy to use?

Choose by layer for vertical slices, by component for modular systems, by concern for cross-cutting reviews, and by file ownership to minimize merge conflicts; pick the one that best matches the architecture and team skills.

What is the simplest way to avoid deadlocks in task graphs?

Avoid circular blockedBy relationships, keep dependency chains shallow, and only add dependencies that are strictly necessary for correctness or integration.