cortivex-task-decomposition

Cortivex Task Decomposition

This skill covers how TaskDecomposer nodes break complex work into atomic tasks with dependency ordering, priority assignment, and cost estimation. TaskDecomposer is the planning layer that sits between a user's high-level request and the execution pipeline.

Overview

When a user requests something like "refactor the authentication module and add tests," the work contains multiple sub-tasks with implicit dependencies and varying priorities. A TaskDecomposer node analyzes the request, breaks it into atomic work units, determines execution order, estimates cost, and feeds the resulting task queue to the SwarmCoordinator or pipeline DAG.

When to Use

• The user provides a broad, multi-part request that needs decomposition
• You need to plan work for multiple agents before execution begins
• The work has implicit dependencies (tests must run after code changes)
• You want cost and time estimates before committing to execution
• Tasks have different priorities and some are optional

You do NOT need a TaskDecomposer for:

• Running a pre-defined pipeline template (the DAG is already defined)
• Single-step operations (one agent, one task)
• Pipelines where the node sequence is fixed and known at definition time

How It Works

Task Lifecycle

User Request
    |
    v
TaskDecomposer (analysis phase)
    |-- Parse request into goals
    |-- Identify sub-tasks for each goal
    |-- Determine dependencies between sub-tasks
    |-- Assign priorities
    |-- Estimate cost and duration
    |-- Produce ordered task queue
    |
    v
Task Queue
    |
    v
SwarmCoordinator / Pipeline DAG (execution phase)
    |-- Assigns tasks to agents based on priority and dependencies
    |-- Tasks flow through: Backlog -> Ready -> In Progress -> Review -> Done
    |
    v
Results

Task States

Backlog --> Ready --> In Progress --> Review --> Done
                          |
                        Failed --> Backlog (auto-retry if configured)

| State | Meaning | |-------|---------| | backlog | Task is decomposed but dependencies are not yet satisfied | | ready | All dependencies are satisfied; task can be assigned to an agent | | in_progress | An agent is actively working on the task | | review | Task completed; awaiting validation or downstream verification | | done | Task completed and validated | | failed | Task execution failed; may be retried or escalated |

Decomposition Rules

The TaskDecomposer follows these rules when breaking down work:

1. Atomic -- Each task must be completable by a single agent in a single session. If a task requires coordination between agents, it is too large.
2. Specific -- Each task has clear acceptance criteria. "Improve code quality" is too vague; "Fix the 3 ESLint errors in src/utils/parser.ts" is specific.
3. Bounded -- Each task should take 2-10 minutes of agent work. Tasks estimated at more than 15 minutes should be split further.
4. Independent where possible -- Minimize dependencies between tasks to maximize parallel execution.
5. Prioritized -- Every task receives an explicit priority score from 1 (lowest) to 10 (highest).

Priority Guide

| Priority | Label | Scheduling Behavior | Examples | |----------|-------|---------------------|----------| | 9-10 | Critical | Scheduled first; blocks all lower-priority work | Security vulnerabilities, data loss risks, production crashes | | 7-8 | High | Scheduled early; preempts medium tasks | Core feature implementation, CI failures, blocking bugs | | 4-6 | Medium | Scheduled in order; runs in parallel with peers | Enhancements, refactoring, new API endpoints | | 1-3 | Low | Scheduled last; may be dropped if budget is tight | Documentation updates, code cleanup, cosmetic fixes |

Pipeline Configuration

TaskDecomposer Node in a Pipeline

name: decompose-and-execute
version: "1.0"
description: Decompose a user request and execute the resulting tasks
nodes:
  - id: decompose
    type: TaskDecomposer
    config:
      strategy: dependency-aware
      max_tasks: 50
      min_priority: 1
      estimate_cost: true
      estimate_duration: true
      output_format: task-queue
      auto_detect_dependencies: true
      split_threshold_minutes: 15

  - id: coordinator
    type: SwarmCoordinator
    depends_on: [decompose]
    config:
      pool_size: 3
      task_strategy: priority-queue
      source: decompose.task_queue

  - id: monitor
    type: AgentMonitor
    depends_on: [coordinator]
    config:
      auto_recovery: true

Using TaskDecomposer via MCP Tool

cortivex_decompose({
  request: "Refactor the authentication module to use JWT, add input validation, and write tests",
  repo: "/path/to/project",
  options: {
    strategy: "dependency-aware",
    estimate_cost: true,
    dry_run: true
  }
})

Output:

{
  "goal": "Refactor authentication to JWT with validation and tests",
  "tasks": [
    {
      "id": "task-1",
      "title": "Analyze current auth module structure",
      "description": "Map all files, functions, and dependencies in src/auth/",
      "type": "ArchitectAnalyzer",
      "priority": 8,
      "depends_on": [],
      "estimated_duration_seconds": 50,
      "estimated_cost": "$0.020",
      "tags": ["auth", "analysis"]
    },
    {
      "id": "task-2",
      "title": "Implement JWT token generation and validation",
      "description": "Replace session-based auth in src/auth/session.ts with JWT using jsonwebtoken library",
      "type": "RefactorAgent",
      "priority": 9,
      "depends_on": ["task-1"],
      "estimated_duration_seconds": 60,
      "estimated_cost": "$0.025",
      "tags": ["auth", "refactor", "jwt"]
    },
    {
      "id": "task-3",
      "title": "Add input validation to login and signup endpoints",
      "description": "Validate email format, password strength, and username uniqueness in src/api/auth.ts",
      "type": "AutoFixer",
      "priority": 8,
      "depends_on": ["task-1"],
      "estimated_duration_seconds": 30,
      "estimated_cost": "$0.012",
      "tags": ["auth", "validation"]
    },
    {
      "id": "task-4",
      "title": "Update existing tests for new JWT auth flow",
      "description": "Modify tests/auth.test.ts to use JWT tokens instead of session cookies",
      "type": "RefactorAgent",
      "priority": 7,
      "depends_on": ["task-2"],
      "estimated_duration_seconds": 45,
      "estimated_cost": "$0.020",
      "tags": ["auth", "testing"]
    },
    {
      "id": "task-5",
      "title": "Generate unit tests for input validation",
      "description": "Write tests for email, password, and username validation functions",
      "type": "TestGenerator",
      "priority": 7,
      "depends_on": ["task-3"],
      "estimated_duration_seconds": 55,
      "estimated_cost": "$0.022",
      "tags": ["validation", "testing"]
    },
    {
      "id": "task-6",
      "title": "Run full test suite and verify coverage",
      "description": "Execute npm test and confirm coverage remains above 80%",
      "type": "TestRunner",
      "priority": 8,
      "depends_on": ["task-4", "task-5"],
      "estimated_duration_seconds": 60,
      "estimated_cost": "$0.003",
      "tags": ["testing", "verification"]
    }
  ],
  "summary": {
    "total_tasks": 6,
    "parallelizable": ["task-2 + task-3", "task-4 + task-5"],
    "estimated_total_cost": "$0.102",
    "estimated_total_duration": "4m 30s (with parallel execution)",
    "critical_path": "task-1 -> task-2 -> task-4 -> task-6"
  }
}

Dependency Graph Visualization

The decomposition above produces this dependency DAG:

task-1 (Analyze)
  |         \
  v          v
task-2      task-3
(JWT)       (Validation)
  |              |
  v              v
task-4      task-5
(Update     (Generate
 tests)      tests)
  |          /
  v         v
task-6 (Run tests)

Tasks 2 and 3 can run in parallel. Tasks 4 and 5 can run in parallel. This parallelism