mirror of
https://github.com/wshobson/agents.git
synced 2026-03-18 17:47:16 +00:00
feat(agent-teams): add plugin for multi-agent team orchestration
New plugin with 7 presets (review, debug, feature, fullstack, research, security, migration), 4 specialized agents, 7 slash commands, 6 skills with reference docs, and Context7 MCP integration for research teams.
This commit is contained in:
Seth Hobson
162
plugins/agent-teams/skills/task-coordination-strategies/SKILL.md
Normal file
162
plugins/agent-teams/skills/task-coordination-strategies/SKILL.md
Normal file
@@ -0,0 +1,162 @@
|
||||
---
|
||||
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.
|
||||
---
|
||||
|
||||
# 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
|
||||
@@ -0,0 +1,97 @@
|
||||
# Dependency Graph Patterns
|
||||
|
||||
Visual patterns for task dependency design with trade-offs.
|
||||
|
||||
## Pattern 1: Fully Independent (Maximum Parallelism)
|
||||
|
||||
```
|
||||
Task A ─┐
|
||||
Task B ─┼─→ Final Integration
|
||||
Task C ─┘
|
||||
```
|
||||
|
||||
- **Parallelism**: Maximum — all tasks run simultaneously
|
||||
- **Risk**: Integration may reveal incompatibilities late
|
||||
- **Use when**: Tasks operate on completely separate files/modules
|
||||
- **TaskCreate**: No blockedBy relationships; integration task blocked by all
|
||||
|
||||
## Pattern 2: Sequential Chain (No Parallelism)
|
||||
|
||||
```
|
||||
Task A → Task B → Task C → Task D
|
||||
```
|
||||
|
||||
- **Parallelism**: None — each task waits for the previous
|
||||
- **Risk**: Bottleneck at each step; one delay cascades
|
||||
- **Use when**: Each task depends on the output of the previous (avoid if possible)
|
||||
- **TaskCreate**: Each task blockedBy the previous
|
||||
|
||||
## Pattern 3: Diamond (Shared Foundation)
|
||||
|
||||
```
|
||||
┌→ Task B ─┐
|
||||
Task A ──→ ┤ ├→ Task D
|
||||
└→ Task C ─┘
|
||||
```
|
||||
|
||||
- **Parallelism**: B and C run in parallel after A completes
|
||||
- **Risk**: A is a bottleneck; D must wait for both B and C
|
||||
- **Use when**: B and C both need output from A (e.g., shared types)
|
||||
- **TaskCreate**: B and C blockedBy A; D blockedBy B and C
|
||||
|
||||
## Pattern 4: Fork-Join (Phased Parallelism)
|
||||
|
||||
```
|
||||
Phase 1: A1, A2, A3 (parallel)
|
||||
────────────
|
||||
Phase 2: B1, B2 (parallel, after phase 1)
|
||||
────────────
|
||||
Phase 3: C1 (after phase 2)
|
||||
```
|
||||
|
||||
- **Parallelism**: Within each phase, tasks are parallel
|
||||
- **Risk**: Phase boundaries add synchronization delays
|
||||
- **Use when**: Natural phases with dependencies (build → test → deploy)
|
||||
- **TaskCreate**: Phase 2 tasks blockedBy all Phase 1 tasks
|
||||
|
||||
## Pattern 5: Pipeline (Streaming)
|
||||
|
||||
```
|
||||
Task A ──→ Task B ──→ Task C
|
||||
└──→ Task D ──→ Task E
|
||||
```
|
||||
|
||||
- **Parallelism**: Two parallel chains
|
||||
- **Risk**: Chains may diverge in approach
|
||||
- **Use when**: Two independent feature branches from a common starting point
|
||||
- **TaskCreate**: B blockedBy A; D blockedBy A; C blockedBy B; E blockedBy D
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
### Circular Dependency (Deadlock)
|
||||
|
||||
```
|
||||
Task A → Task B → Task C → Task A ✗ DEADLOCK
|
||||
```
|
||||
|
||||
**Fix**: Extract shared dependency into a separate task that all three depend on.
|
||||
|
||||
### Unnecessary Dependencies
|
||||
|
||||
```
|
||||
Task A → Task B → Task C
|
||||
(where B doesn't actually need A's output)
|
||||
```
|
||||
|
||||
**Fix**: Remove the blockedBy relationship; let B run independently.
|
||||
|
||||
### Star Pattern (Single Bottleneck)
|
||||
|
||||
```
|
||||
┌→ B
|
||||
A → ├→ C → F
|
||||
├→ D
|
||||
└→ E
|
||||
```
|
||||
|
||||
**Fix**: If A is slow, all downstream tasks are delayed. Try to parallelize A's work.
|
||||
@@ -0,0 +1,98 @@
|
||||
# Task Decomposition Examples
|
||||
|
||||
Practical examples of decomposing features into parallelizable tasks with clear ownership.
|
||||
|
||||
## Example 1: User Authentication Feature
|
||||
|
||||
### Feature Description
|
||||
|
||||
Add email/password authentication with login, registration, and profile pages.
|
||||
|
||||
### Decomposition (Vertical Slices)
|
||||
|
||||
**Stream 1: Login Flow** (implementer-1)
|
||||
|
||||
- Owned files: `src/pages/login.tsx`, `src/api/login.ts`, `tests/login.test.ts`
|
||||
- Requirements: Login form, API endpoint, input validation, error handling
|
||||
- Interface: Imports `AuthResponse` from `src/types/auth.ts`
|
||||
|
||||
**Stream 2: Registration Flow** (implementer-2)
|
||||
|
||||
- Owned files: `src/pages/register.tsx`, `src/api/register.ts`, `tests/register.test.ts`
|
||||
- Requirements: Registration form, API endpoint, email validation, password strength
|
||||
- Interface: Imports `AuthResponse` from `src/types/auth.ts`
|
||||
|
||||
**Stream 3: Shared Infrastructure** (implementer-3)
|
||||
|
||||
- Owned files: `src/types/auth.ts`, `src/middleware/auth.ts`, `src/utils/jwt.ts`
|
||||
- Requirements: Type definitions, JWT middleware, token utilities
|
||||
- Dependencies: None (other streams depend on this)
|
||||
|
||||
### Dependency Graph
|
||||
|
||||
```
|
||||
Stream 3 (types/middleware) ──→ Stream 1 (login)
|
||||
└→ Stream 2 (registration)
|
||||
```
|
||||
|
||||
## Example 2: REST API Endpoints
|
||||
|
||||
### Feature Description
|
||||
|
||||
Add CRUD endpoints for a new "Projects" resource.
|
||||
|
||||
### Decomposition (By Layer)
|
||||
|
||||
**Stream 1: Data Layer** (implementer-1)
|
||||
|
||||
- Owned files: `src/models/project.ts`, `src/migrations/add-projects.ts`, `src/repositories/project-repo.ts`
|
||||
- Requirements: Schema definition, migration, repository pattern
|
||||
- Dependencies: None
|
||||
|
||||
**Stream 2: Business Logic** (implementer-2)
|
||||
|
||||
- Owned files: `src/services/project-service.ts`, `src/validators/project-validator.ts`
|
||||
- Requirements: CRUD operations, validation rules, business logic
|
||||
- Dependencies: Blocked by Stream 1 (needs model/repository)
|
||||
|
||||
**Stream 3: API Layer** (implementer-3)
|
||||
|
||||
- Owned files: `src/routes/projects.ts`, `src/controllers/project-controller.ts`
|
||||
- Requirements: REST endpoints, request parsing, response formatting
|
||||
- Dependencies: Blocked by Stream 2 (needs service layer)
|
||||
|
||||
## Task Template
|
||||
|
||||
```markdown
|
||||
## Task: {Stream Name}
|
||||
|
||||
### Objective
|
||||
|
||||
{1-2 sentence description of what to build}
|
||||
|
||||
### Owned Files
|
||||
|
||||
- {file1} — {purpose}
|
||||
- {file2} — {purpose}
|
||||
|
||||
### Requirements
|
||||
|
||||
1. {Specific deliverable 1}
|
||||
2. {Specific deliverable 2}
|
||||
3. {Specific deliverable 3}
|
||||
|
||||
### Interface Contract
|
||||
|
||||
- Exports: {types/functions this stream provides}
|
||||
- Imports: {types/functions this stream consumes from other streams}
|
||||
|
||||
### Acceptance Criteria
|
||||
|
||||
- [ ] {Verifiable criterion 1}
|
||||
- [ ] {Verifiable criterion 2}
|
||||
- [ ] {Verifiable criterion 3}
|
||||
|
||||
### Out of Scope
|
||||
|
||||
- {Explicitly excluded work}
|
||||
```
|
||||
Reference in New Issue
Block a user