team-orchestrator

name	team-orchestrator
description	Workflow decomposition and task dependency management. Breaks epics into tasks, establishes dependencies, manages execution order, and coordinates parallel work streams.

Team Orchestrator

Break large goals into agent-sized tasks, wire up dependencies, and drive parallel execution across a team.

Core Concepts

Epic to Story to Task Decomposition

Every piece of work flows through three levels:

• Epic: A broad objective ("Build user authentication"). Too large for one agent.
• Story: A coherent slice of the epic ("Implement password hashing"). May still need splitting.
• Task: A single unit of work completable by one agent in one session. Has clear inputs, outputs, and acceptance criteria.

The rule of thumb: if you cannot describe the done state in one sentence, the task is too big. If the task takes under five minutes of thought to specify, you may have over-decomposed.

Dependency Management

Tasks declare two relationships:

• blockedBy: IDs of tasks that must complete before this task can start.
• blocks: IDs of tasks that cannot start until this task completes.

These are symmetric: if task B has blockedBy: ["A"], then task A should have blocks: ["B"].

Dependency rules:

1. Minimize dependencies. Every edge you add constrains parallelism.
2. Never create circular dependencies. If A blocks B and B blocks A, neither can start.
3. Prefer thin interfaces. A task should depend on an output artifact, not on an entire body of work.
4. Make dependencies explicit. Implicit ordering causes race conditions and wasted effort.

Workflow Patterns

Sequential -- Tasks run one after another. Use when each task consumes the prior task's output directly.

A --> B --> C --> D

Parallel -- Independent tasks run simultaneously. Use when tasks share no data dependencies.

A --> B
A --> C
A --> D

Diamond -- Parallel paths converge at a synchronization point. Use when independent work must merge before the next phase.

    B
   / \
  A   D
   \ /
    C

Pipeline -- Stages where multiple tasks feed into the next stage. Use for phased delivery with review gates.

[Design A, Design B] --> [Implement A, Implement B] --> [Integration Test]

Task Assignment Strategy

1. Match skills to tasks. Assign code tasks to code-focused agents, documentation to writing agents.
2. Balance load. Distribute tasks so no single agent becomes a bottleneck.
3. Minimize handoffs. If one agent wrote the module, assign its tests to the same agent when possible.
4. Separate concerns. The agent reviewing code should not be the agent who wrote it.
5. Keep the critical path staffed. Never leave a critical-path task unassigned.

Execution Monitoring

Track workflow health by watching:

• Blocked count: How many tasks are waiting. A rising number signals a bottleneck.
• In-progress count: How many tasks are active. Should match your team size.
• Critical path progress: How many critical-path tasks remain. This determines your minimum completion time.
• Idle agents: Any agent with no assigned pending or in-progress task is wasted capacity.

Update task status as work proceeds. A task moves through: pending -> in_progress -> completed.

When a task completes, check whether it unblocks downstream tasks and notify those owners.

---

Example 1: Build REST API

Epic: Build a REST API for a task management application.

Decomposition:

Epic: REST API
  Story: Project Setup
    Task 1: Initialize project structure and dependencies
  Story: Data Layer
    Task 2: Define database schema and models
    Task 3: Write database migration scripts
  Story: API Endpoints
    Task 4: Implement CRUD endpoints for tasks
    Task 5: Implement CRUD endpoints for users
    Task 6: Add authentication middleware
  Story: Testing
    Task 7: Write unit tests for models
    Task 8: Write integration tests for endpoints
  Story: Documentation
    Task 9: Write API documentation with examples

Dependency graph:

Task 1 (setup)
  |
  +--> Task 2 (schema) --+--> Task 3 (migrations)
  |                       |
  |                       +--> Task 4 (task endpoints) --+--> Task 8 (integration tests)
  |                       |                              |
  |                       +--> Task 5 (user endpoints) --+
  |                       |
  |                       +--> Task 6 (auth middleware) --+
  |                       |
  |                       +--> Task 7 (unit tests)
  |
  +--> Task 9 (docs) -- depends on Tasks 4, 5, 6

TaskCreate calls:

TaskCreate: {
  subject: "Initialize project structure",
  description: "Create Python project with FastAPI, SQLAlchemy, Alembic. Set up pyproject.toml, directory layout (app/models, app/routes, app/tests), and dev dependencies.",
  owner: "backend-dev-1",
  blockedBy: [],
  blocks: ["task-2", "task-9"]
}

TaskCreate: {
  subject: "Define database schema and models",
  description: "Create SQLAlchemy models for User (id, email, password_hash, created_at) and Task (id, title, description, status, owner_id FK, created_at, updated_at). Include relationships.",
  owner: "backend-dev-1",
  blockedBy: ["task-1"],
  blocks: ["task-3", "task-4", "task-5", "task-6", "task-7"]
}

TaskCreate: {
  subject: "Write database migration scripts",
  description: "Create Alembic migration for initial schema. Verify upgrade and downgrade paths. Seed script for dev data.",
  owner: "backend-dev-2",
  blockedBy: ["task-2"],
  blocks: []
}

TaskCreate: {
  subject: "Implement CRUD endpoints for tasks",
  description: "POST /tasks, GET /tasks, GET /tasks/{id}, PUT /tasks/{id}, DELETE /tasks/{id}. Use Pydantic schemas for validation. Return appropriate HTTP status codes.",
  owner: "backend-dev-1",
  blockedBy: ["task-2"],
  blocks: ["task-8", "task-9"]
}

TaskCreate: {
  subject: "Implement CRUD endpoints for users",
  description: "POST /users (register), GET /users/me, PUT /users/me. Hash passwords with bcrypt. Pydantic schemas for input/output.",
  owner: "backend-dev-2",
  blockedBy: ["task-2"],
  blocks: ["task-8", "task-9"]
}

TaskCreate: {
  subject: "Add authentication middleware",
  description: "JWT-based auth. POST /auth/login returns access token. Middleware validates token on protected routes. Token expiry 24h.",
  owner: "backend-dev-2",
  blockedBy: ["task-2"],
  blocks: ["task-8", "task-9"]
}

TaskCreate: {
  subject: "Write unit tests for models",
  description: "Test User and Task model creation, validation, relationships. Test password hashing. Use pytest with in-memory SQLite. Target 95% model coverage.",
  owner: "tester",
  blockedBy: ["task-2"],
  blocks: []
}

TaskCreate: {
  subject: "Write integration tests for endpoints",
  description: "Test all endpoints with httpx AsyncClient. Cover auth flow, CRUD operations, error cases (404, 422, 401). Use test database with fixtures.",
  owner: "tester",
  blockedBy: ["task-4", "task-5", "task-6"],
  blocks: []
}

TaskCreate: {
  subject: "Write API documentation",
  description: "Document all endpoints with request/response examples. Include auth flow walkthrough. Add OpenAPI schema customizations. Write getting-started guide.",
  owner: "tech-writer",
  blockedBy: ["task-4", "task-5", "task-6"],
  blocks: []
}

Execution order:

1. Task 1 starts immediately (no blockers).
2. Task 2 starts when Task 1 completes.
3. Tasks 3, 4, 5, 6, 7 all start in parallel when Task 2 completes.
4. Tasks 8 and 9 start when Tasks 4, 5, and 6 all complete.

Critical path: Task 1 -> Task 2 -> Task 4 (or 5 or 6, whichever is slowest) -> Task 8.

Parallelism: After Task 2, five tasks can run simultaneously. Assign each to a different agent if available.

---

Example 2: Write Technical Documentation

Epic: Create comprehensive technical documentation for an existing library.

Decomposition:

Epic: Technical Documentation
  Story: Audit and Plan
    Task 1: Audit existing code and identify public API surface
    Task 2: Create documentation outline and style guide
  Story: Core Documentation
    Task 3: Write getting-started guide
    Task 4: Write API reference for core module
    Task 5: Write API reference for utilities module
  Story: Advanced Content
    Task 6: Write tutorial: common workflows
    Task 7: Write migration guide from v1 to v2
  Story: Review and Polish
    Task 8: Technical review of all documentation
    Task 9: Copy-edit and format final output

Dependency graph:

Task 1 (audit) ---+--> Task 2 (outline)
                  |        |
                  |        +--> Task 3 (getting started)
                  |        +--> Task 4 (core API ref) ----+--> Task 8 (tech review)
                  |        +--> Task 5 (utils API ref) ---+        |
                  |                                       |        v
                  +--> Task 6 (tutorials) ----------------+   Task 9 (copy-edit)
                  |
                  +--> Task 7 (migration guide) ----------+

TaskCreate calls:

TaskCreate: {
  subject: "Audit public API surface",
  description: "Read all source files. List every public class, function, and constant. Note which have docstrings and which do not. Output: api-surface.md with name, signature, and docstring status for each symbol.",
  owner: "researcher",
  blockedBy: [],
  blocks: ["task-2", "task-6", "task-7"]
}

TaskCreate: {
  subject: "Create documentation outline and style guide",
  description: "Define doc structure (sections, ordering). Write style guide: voice (active, second person), code example format (runnable snippets), heading conventions. Output: outline.md, style-guide.md.",
  owner: "tech-writer-1",
  blockedBy: ["task-1"],
  blocks: ["task-3", "task-4", "task-5"]
}

TaskCreate: {
  subject: "Write getting-started guide",
  description: "Cover installation (pip, conda), first script (10 lines), key concepts (3-4 paragraphs). Include a working code example that the reader can copy-paste and run.",
  owner: "tech-writer-1",
  blockedBy: ["task-2"],
  blocks: ["task-8"]
}

TaskCreate: {
  subject: "Write API reference for core module",
  description: "Document every public symbol in the core module. For each: signature, parameters with types, return value, exceptions raised, one usage example. Follow style guide from Task 2.",
  owner: "tech-writer-2",
  blockedBy: ["task-2"],
  blocks: ["task-8"]
}

TaskCreate: {
  subject: "Write API reference for utilities module",
  description: "Document every public symbol in the utilities module. Same format as Task 4. Cross-link to core module where utilities wrap core functionality.",
  owner: "tech-writer-2",
  blockedBy: ["task-2"],
  blocks: ["task-8"]
}

TaskCreate: {
  subject: "Write tutorial: common workflows",
  description: "Three tutorials: data loading, transformation pipeline, export to multiple formats. Each tutorial is a standalone page with full code and expected output.",
  owner: "tech-writer-1",
  blockedBy: ["task-1"],
  blocks: ["task-8"]
}

TaskCreate: {
  subject: "Write migration guide from v1 to v2",
  description: "List every breaking change. For each: what changed, why, before/after code snippets, automated migration steps if any. Include a checklist for migrating a project.",
  owner: "researcher",
  blockedBy: ["task-1"],
  blocks: ["task-8"]
}

TaskCreate: {
  subject: "Technical review of all documentation",
  description: "Verify every code example runs. Check accuracy of parameter descriptions against source. Flag inconsistencies with style guide. Output: review-notes.md with file, line, issue, suggestion.",
  owner: "reviewer",
  blockedBy: ["task-3", "task-4", "task-5", "task-6", "task-7"],
  blocks: ["task-9"]
}

TaskCreate: {
  subject: "Copy-edit and format final output",
  description: "Apply review fixes. Check grammar, spelling, formatting. Ensure consistent heading levels, link validity, and code block language tags. Final output: publishable documentation set.",
  owner: "tech-writer-1",
  blockedBy: ["task-8"],
  blocks: []
}

Execution order:

1. Task 1 starts immediately.
2. Tasks 2, 6, 7 start when Task 1 completes (parallel).
3. Tasks 3, 4, 5 start when Task 2 completes (parallel, also parallel with 6 and 7).
4. Task 8 starts when Tasks 3, 4, 5, 6, 7 all complete.
5. Task 9 starts when Task 8 completes.

Critical path: Task 1 -> Task 2 -> Task 4 (longest API ref) -> Task 8 -> Task 9.

Parallelism peak: Up to five tasks (3, 4, 5, 6, 7) can run simultaneously after Task 2 completes. With three writers and one researcher, assign: writer-1 gets Tasks 3 and 6, writer-2 gets Tasks 4 and 5, researcher gets Task 7.

---

Monitoring Checklist

After creating all tasks:

1. Run scripts/dependency_graph.py {team-name} to visualize the graph and confirm no cycles.
2. Identify the critical path. Ensure every task on it has an owner.
3. Count maximum parallelism. Ensure you have enough agents to exploit it.
4. Set up a check-in cadence: after each critical-path task completes, review the remaining graph.
5. When a task completes, use TaskUpdate to set status: "completed" and check what it unblocks.
6. If a blocked task has all its blockers completed, set it to in_progress and notify the owner.
7. If an agent finishes early, assign them the next available task from the ready queue (pending tasks with all blockers completed).

Common TaskUpdate Patterns

Starting a task:

TaskUpdate: { id: "task-4", status: "in_progress" }

Completing a task and checking downstream:

TaskUpdate: { id: "task-4", status: "completed" }
TaskList: { filter: { blockedBy: "task-4" } }
-- For each downstream task, check if all blockers are now completed.
-- If yes, notify the owner and set status to in_progress.

Reassigning a stuck task:

TaskUpdate: { id: "task-6", owner: "tech-writer-2", description: "..." }

Related Skills

• team-communicator -- Communication protocols for coordinating agents during workflow execution
• team-monitor -- Track task progress and detect bottlenecks in the workflow
• team-builder -- Create the team and initial tasks before orchestration begins