claude-code-tasks

name: claude-code-tasks description: Reference for Claude Code's 6 Task Management tools — TaskCreate, TaskGet, TaskList, TaskUpdate (structured tracking) and TaskOutput, TaskStop (background execution). Covers tool parameters, status lifecycle, completion rules, dependency management, and conventions user-invocable: false disable-model-invocation: false last-verified: 2026-03-07

Claude Code Tasks Reference

This skill is a shared reference for Claude Code's 6 Task Management tools. Load it when your skill or agent needs to create, manage, or coordinate tasks.

The tools serve two distinct purposes:

• Structured tracking — TaskCreate, TaskGet, TaskList, TaskUpdate — for organizing work items, tracking progress, managing dependencies, and coordinating agents
• Background execution — TaskOutput, TaskStop — for monitoring and controlling background processes (shells, agents, remote sessions)

Both share the task ID namespace but serve different operational needs.

This reference covers:

• Complete tool parameter tables for all six Task tools
• Status lifecycle, transition rules, and completion rules
• Naming conventions (subject vs. activeForm)
• Dependency management with DAG design principles
• Metadata conventions for categorization and tracking

For deeper content, load the reference files listed at the end of this document.

TaskCreate

Creates a new task. Returns the created task object with a system-assigned id.

Use TaskCreate for complex multi-step tasks (3+ distinct steps), plan mode tracking, or when the user provides multiple tasks or requests a todo list. Skip it for single straightforward tasks or trivial work completable in under 3 steps.

Parameters

Behavior

• All tasks are created with status pending
• No owner is assigned at creation — use TaskUpdate to assign
• Use TaskUpdate after creation to set up dependencies (blocks/blockedBy)

Return Value

Returns the full task object including:

• id — System-assigned unique identifier
• subject — The subject provided
• description — The description provided
• activeForm — The activeForm provided (if any)
• status — Always pending for newly created tasks
• metadata — The metadata provided (if any)
• blockedBy — Empty array (no dependencies yet)
• blocks — Empty array (no dependents yet)

Example

TaskCreate:
  subject: "Create user authentication module"
  description: "Implement JWT-based auth with login, logout, and token refresh endpoints."
  activeForm: "Creating user authentication module"
  metadata:
    priority: "high"
    complexity: "medium"
    task_group: "user-auth"

TaskGet

Retrieves a single task by its ID. Use this to get full task details including description, metadata, and dependency information.

Use TaskGet before starting work on a task to get the full description with acceptance criteria. Also use it to verify the blockedBy list is empty before beginning work, and to read the latest state before calling TaskUpdate (staleness check). Use TaskList first for an overview, then TaskGet for full details on a specific task.

Parameters

Return Value

Returns the full task object:

• id — Task identifier
• subject — Task title
• description — Full description (may be long)
• activeForm — Present-continuous form (if set)
• status — Current status (pending, in_progress, completed, deleted)
• metadata — Key-value pairs
• blockedBy — Array of task IDs this task depends on
• blocks — Array of task IDs that depend on this task
• owner — The agent or session that owns this task (if set)

TaskUpdate

Updates an existing task. Only the fields you provide are changed; omitted fields remain unchanged.

Always read the latest state via TaskGet before updating to avoid acting on stale data.

Parameters

Return Value

Returns the updated task object with all current fields.

Example

TaskUpdate:
  taskId: "5"
  status: "in_progress"
  activeForm: "Implementing user authentication module"

TaskList

Lists all tasks in the current task list. Takes no parameters.

Use TaskList to see available work (pending, unblocked tasks), check overall progress, or find the next task after completing one. For teammate workflows: call TaskList, find tasks with pending status and empty blockedBy, prefer the highest-priority unblocked task, then claim it via TaskUpdate.

Parameters

None.

Return Value

Returns an array of task summary objects. Each summary includes:

• id — Task identifier
• subject — Task title
• status — Current status
• owner — Agent ID if assigned, empty if available
• blockedBy — Array of blocking task IDs
• blocks — Array of dependent task IDs
• metadata — Key-value pairs

Note: TaskList returns summary objects. Use TaskGet to retrieve the full description for a specific task.

TaskOutput

Retrieves output from a running or completed background task. Works with background shells, async agents, and remote sessions.

Use TaskOutput to check on background task progress, retrieve results from completed background work, or monitor long-running operations.

Parameters

Behavior

• block: true — Waits for the task to finish (up to timeout ms), then returns the output. Use this when you need the result before proceeding.
• block: false — Returns immediately with current status and any available output. Use this for progress checks without blocking.

TaskStop

Terminates a running background task.

Use TaskStop to cancel a long-running task that is no longer needed or to force-terminate a background process (e.g., a timed-out executor agent).

Parameters

Return Value

Returns success or failure status of the stop operation.

Status Lifecycle

Tasks follow a three-state lifecycle with an additional terminal state.

┌──────────┐    TaskUpdate     ┌─────────────┐    TaskUpdate     ┌───────────┐
│ pending  │ ──────────────→  │ in_progress │ ──────────────→  │ completed │
└──────────┘   status:         └─────────────┘   status:         └───────────┘
  TaskCreate   in_progress                       completed
      │                             │
      │ TaskUpdate                  │ TaskUpdate
      │ status: deleted             │ status: deleted
      ▼                             ▼
┌───────────┐                 ┌───────────┐
│  deleted   │                │  deleted   │
└───────────┘                 └───────────┘

States

Transition Rules

• pending -> in_progress: Set when an agent begins working on the task.
• in_progress -> completed: Set when the task is verified as done. Only mark complete after verification passes.
• in_progress -> pending: Valid for resetting a task (e.g., after a failed attempt or interrupted session).
• pending -> deleted: Remove a task that is no longer needed.
• in_progress -> deleted: Cancel a task that is in progress.
• Blocked tasks: A task with non-empty blockedBy (where blockers are not yet completed) should not be started. The system does not enforce this automatically — your orchestration logic must check dependencies before transitioning to in_progress.

Completion Rules

These rules prevent premature completion, which wastes execution resources on retries:

• Only mark completed when the task is fully accomplished — all acceptance criteria met
• If errors or blockers are encountered, keep the task as in_progress and address them
• Never mark completed if: tests are failing, implementation is partial, errors are unresolved, or dependencies are missing
• Always read the latest state via TaskGet before updating status (staleness check)

Naming Conventions

Subject (Imperative)

The subject field uses imperative mood — a command that describes what the task will accomplish:

activeForm (Present-Continuous)

The activeForm field uses present-continuous tense — describing what is happening while the task runs:

The activeForm appears in the task list UI while the task status is in_progress. If omitted, the UI falls back to the subject.

Dependency Management

Tasks support dependency tracking via blockedBy and blocks fields, forming a Directed Acyclic Graph (DAG).

Fields

• blockedBy: Array of task IDs that must complete before this task can start. Set via addBlockedBy in TaskUpdate.
• blocks: Array of task IDs that are waiting on this task. Set via addBlocks in TaskUpdate. This is the inverse of blockedBy.

Setting Dependencies

Dependencies are set after task creation using TaskUpdate:

TaskUpdate:
  taskId: "5"
  addBlockedBy: ["3", "4"]

This means task 5 cannot start until tasks 3 and 4 are both completed.

DAG Design Principles

1. No cycles: Never create circular dependencies (A blocks B, B blocks C, C blocks A). This creates deadlocks where no task can proceed.
2. Minimize depth: Prefer wider, shallower dependency graphs. Deep chains (A -> B -> C -> D -> E) serialize execution and slow throughput.
3. Depend on producers, not peers: A task should depend on the task that produces what it needs, not on unrelated tasks at the same level.
4. One-way information flow: Dependencies should follow the data flow — upstream tasks produce artifacts that downstream tasks consume.
5. Independent tasks run in parallel: Tasks at the same dependency level (no dependencies between them) can execute concurrently.

Common Dependency Patterns

Metadata Conventions

The metadata field accepts arbitrary string key-value pairs. These common keys are used across the agent-alchemy ecosystem:

Metadata Merge Behavior

TaskUpdate's metadata field performs a merge with the existing metadata. Keys you provide are added or updated; keys you omit remain unchanged. Set a key to null to delete it.

# Task 5 currently has metadata: { priority: "high", task_group: "auth" }

# Add complexity without affecting existing keys:
TaskUpdate:
  taskId: "5"
  metadata:
    complexity: "medium"
# Result: { priority: "high", task_group: "auth", complexity: "medium" }

# Delete a key by setting it to null:
TaskUpdate:
  taskId: "5"
  metadata:
    task_group: null
# Result: { priority: "high", complexity: "medium" }

Reference Files

For deeper content on task design patterns and common mistakes, load these reference files. These cover patterns for the structured tracking tools (TaskCreate, TaskGet, TaskList, TaskUpdate).

Task Patterns

Covers dependency graph design patterns (linear, fan-out, fan-in, diamond), task right-sizing guidance, multi-agent coordination via tasks, and metadata strategies.

Read ${CLAUDE_PLUGIN_ROOT}/skills/claude-code-tasks/references/task-patterns.md

Anti-Patterns

Documents common mistakes when using Tasks: circular dependencies, over-granular tasks, missing activeForm, batch status update pitfalls, duplicate task creation, and more. Each anti-pattern includes the problem, why it matters, and the correct alternative.

Read ${CLAUDE_PLUGIN_ROOT}/skills/claude-code-tasks/references/anti-patterns.md