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:
- 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.
- 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.
- Bounded -- Each task should take 2-10 minutes of agent work. Tasks estimated at more than 15 minutes should be split further.
- Independent where possible -- Minimize dependencies between tasks to maximize parallel execution.
- 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