Task Coordination Strategies
Choose dependency-graph patterns (parallel, sequential, diamond, fork-join) when breaking agent or implementation work into TaskCreate graphs with blockedBy edges.
Overview
Task coordination strategies is a journey-wide agent skill that picks dependency-graph patterns for parallel agent work—usable whenever a solo builder needs to order TaskCreate tasks before committing to an execution pla
Install
npx skills add https://github.com/wshobson/agents --skill task-coordination-strategiesWhat is this skill?
- Documents four dependency patterns: fully independent, sequential chain, diamond, and fork-join phased parallelism
- Spells TaskCreate usage: when to omit blockedBy vs chain blockedBy for maximum safe parallelism
- Explains trade-offs—late integration risk vs cascading delay vs shared-foundation bottlenecks
- Guides integration tasks blocked by all parallel branches in the independent pattern
- Maps phase boundaries for fork-join when work must complete in waves
- 4 dependency graph patterns documented (independent, sequential, diamond, fork-join)
Adoption & trust: 6k installs on skills.sh; 36.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have multiple agent tasks but no clear blockedBy structure, so you either serialize everything unnecessarily or run parallel work that breaks at integration.
Who is it for?
Multi-file features, agent swarms, or phased refactors where some tasks share types or APIs and others are truly isolated.
Skip if: Single-file one-shot edits with no decomposition, or when an approved implementation plan already lists a fixed task order you should not reshape.
When should I use this skill?
Planning multi-task agent runs where parallelism, blockedBy ordering, or phased integration gates matter.
What do I get? / Deliverables
You adopt a named pattern (independent, chain, diamond, or fork-join) with explicit TaskCreate dependencies matched to how modules actually depend on each other.
- Chosen dependency pattern with TaskCreate blockedBy relationships
- Documented parallelism vs risk trade-off for the selected graph
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Decide whether spike tasks can run fully independent before a single integration spike.
Use a diamond so shared types land in task A before parallel UI and API tasks merge at task D.
Apply fork-join so phase-1 infra tasks finish before phase-2 feature tasks start.
Run parallel review tasks on separate modules with a final integration review blocked by all.
How it compares
Complements spec and plan skills by focusing on execution topology—not on writing requirements or CI pipelines.
Common Questions / FAQ
Who is task coordination strategies for?
Solo builders using Claude Code, Cursor, or Codex who split work into multiple tasks and need sensible parallelism and blockedBy edges.
When should I use task coordination strategies?
In Validate when scoping parallel prototype tasks; in Build when structuring PM or agent-tooling runs; in Ship when coordinating review and test tasks; anytime integration timing matters.
Is task coordination strategies safe to install?
It is documentation-only pattern guidance—check the Security Audits panel on this Prism page; it does not execute shell or network actions by itself.
SKILL.md
READMESKILL.md - Task Coordination Strategies
# 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. # 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/projec