/task-dependency-patterns

name: task-dependency-patterns
license: MIT
compatibility: "Claude Code 2.1.277+."
description: Task Management patterns with TaskCreate, TaskUpdate, TaskGet, TaskList tools. Decompose complex work into trackable tasks with dependency chains. Use when managing multi-step implementations, coordinating parallel work, or tracking completion status.
user-invocable: false
disable-model-invocation: true
metadata:
  owner-agent: "workflow-architect"
  category: workflow-automation
  version: "1.0.0"
  author: "OrchestKit"
  complexity: "medium"
  tags: "task-management, dependencies, orchestration, workflow, coordination"
allowed-tools: "Read Glob Grep WebFetch WebSearch"
# Reference skill: fenced calls below teach a pattern, they are not calls this
# skill makes. Widening allowed-tools to satisfy the coverage gate would grant real
# permissions (Agent, CronCreate) to something that never acts.
tool-coverage: illustrative

Task Dependency Patterns

Overview

Claude Code 2.1.16 introduces a native Task Management System with four tools: > **CC 2.1.268 caveat:** TaskCreate, TaskGet, TaskUpdate, TaskList, and TodoWrite are offered only on Claude 3.x, Opus 4.0 to 4.7, Sonnet 4.0 to 4.6, and Haiku 4.5. On models outside this allowlist, these tools are absent unless the operator sets `CLAUDE_CODE_ENABLE_TODO_TOOLS=1`. CC honours the flag only from user or managed settings (or the shell). ork cannot ship it (CC reads only `permissions` from plugin settings), so treat every Task-tool call in this skill as conditional on the operator's environment.

• **TaskCreate**: Create new tasks with subject, description, and activeForm
• **TaskUpdate**: Update status (pending → in_progress → completed), set dependencies
• **TaskGet**: Retrieve full task details including blockers
• **TaskList**: View all tasks with status and dependency summary

Tasks enable structured work tracking, parallel coordination, and clear progress visibility.

When to Use

• Breaking down complex multi-step implementations
• Coordinating parallel work across multiple files
• Tracking progress on large features
• Managing dependencies between related changes
• Providing visibility into work status

Key Patterns

1. Task Decomposition

Break complex work into atomic, trackable units:

Feature: Add user authentication

Tasks:
#1. [pending] Create User model
#2. [pending] Add auth endpoints (blockedBy: #1)
#3. [pending] Implement JWT tokens (blockedBy: #2)
#4. [pending] Add auth middleware (blockedBy: #3)
#5. [pending] Write integration tests (blockedBy: #4)

2. Dependency Chains

Use `addBlockedBy` to create execution order:

// Task #3 cannot start until #1 and #2 complete
{"taskId": "3", "addBlockedBy": ["1", "2"]}

3. Status Workflow

pending → in_progress → completed
   ↓           ↓
(unblocked)  (active)

pending/in_progress → deleted

• **pending**: Task created but not started
• **in_progress**: Actively being worked on
• **completed**: Work finished and verified
• **deleted**: Task removed — permanently removes the task

Task Deletion

Use `status: "deleted"` to permanently remove tasks:

// Delete a task
{"taskId": "3", "status": "deleted"}

**When to delete:**

• Orphaned tasks whose blockers have all failed
• Tasks superseded by a different approach
• Duplicate tasks created in error
• Tasks from a cancelled pipeline

**When NOT to delete:**

• Tasks that might be retried later (keep as pending)
• Tasks with useful history (mark completed instead)
• Tasks blocked by in_progress work (wait for resolution)

4. activeForm Pattern

Provide present-continuous form for spinner display:

| subject (imperative) | activeForm (continuous) | |---------------------|------------------------| | Run tests | Running tests | | Update schema | Updating schema | | Fix authentication | Fixing authentication |

Agent Teams

Agent Teams provides multi-agent coordination with shared task lists and peer-to-peer messaging.

> **CC 2.1.161 — independent parallel-tool failure:** A failed tool call in a parallel batch no longer cancels siblings; each returns its own result. Teammates must check task status independently and handle failures explicitly rather than assuming a batch-wide abort.

Team Workflow

1. (implicit team — CC 2.1.178+)       → one team per session; no TeamCreate
2. TaskCreate(subject, description)    → Add tasks to shared list
3. Agent(name, team_name, prompt)      → Spawn teammates into the implicit team
4. TaskUpdate(owner: "teammate-name")  → Assign tasks
5. SendMessage(to, message, summary)   → Direct teammate communication
6. (turn / background ends)            → teammates wind down; Ctrl+F x2 for bg

> **Cross-session replies land in the parent (CC 2.1.248):** when a subagent sends `SendMessage` to another session, the reply is delivered to the parent session's conversation, never to the subagent; a subagent sends and moves on, the parent reads the answer. Cross-session `SendMessage` / `ListAgents` also work on Bedrock, Vertex and Foundry and with telemetry disabled (CC 2.1.248).

When to Use Teams vs Agent Tool

| Criteria | Agent Tool (subagents) | Agent Teams | |----------|----------------------|-------------| | Independent tasks | Yes | Overkill | | Cross-cutting changes | Limited | Yes | | Agents need to talk | No (star topology) | Yes (mesh) | | Cost sensitivity | Lower (~1x) | Higher (~2.5x) | | Complexity < 3.0 | Yes | No | | Complexity > 3.5 | Possible | Recommended |

Team Task Patterns

# Spawn teammate into shared task list. A teammate that writes files works in
# a manual worktree the lead creates first (#4557); the lead merges its branch
# before dependent tasks start. No isolation on the call: a call with name and
# isolation launches a plain subagent, not a teammate (Claude Code docs).
Bash("git worktree add .worktrees/backend -b feat/my-feature-backend feat/my-feature")
Agent(
  prompt="You are the backend archi