Task Decomposer

Breaks natural-language problems into sub-tasks suitable for DAG nodes. The first step of the meta-DAG: before you can build or execute a DAG, you need to understand what the pieces are.

When to Use

✅ Use for:

Breaking a vague problem into concrete sub-tasks
Identifying phases, dependencies, and parallelization opportunities
Determining which sub-tasks are concrete vs. vague (pluripotent)
Selecting the appropriate domain meta-skill for decomposition

❌ NOT for:

Building the DAG structure from sub-tasks (use dag-planner)
Executing the tasks (use dag-runtime)
Assigning skills to tasks (use dag-skills-matcher)

Decomposition Process

flowchart TD
  P[Problem description] --> M{Domain meta-skill available?}
  M -->|Yes| L[Load meta-skill phase pattern]
  M -->|No| R{Research needed?}
  R -->|Yes| RA[Research standard decomposition]
  R -->|No| Z[Zero-shot decomposition]
  
  L --> D[Apply phase pattern to problem]
  RA --> D
  Z --> D
  
  D --> C[Identify concrete sub-tasks]
  D --> V[Identify vague/pluripotent sub-tasks]
  D --> DEP[Map dependencies between sub-tasks]
  D --> PAR[Identify parallelization opportunities]
  
  C --> O[Ordered sub-task list with metadata]
  V --> O
  DEP --> O
  PAR --> O

Step 1: Domain Detection

Classify the problem into a domain to select the right meta-skill:

Domain Signals	Meta-Skill
"build", "implement", "code", "app", "website"	`software-project-decomposition`
"research", "analyze", "report", "synthesize"	`research-synthesis-decomposition`
"design", "UI", "wireframe", "prototype"	`product-design-decomposition`
"strategy", "market", "business", "revenue"	`business-strategy-decomposition`
"data", "model", "train", "predict"	`ml-project-decomposition`

If no meta-skill matches, fall back to zero-shot decomposition.

Step 2: Phase Identification

Apply the meta-skill's phase pattern. Not all phases apply to every problem.

Decision: For each phase in the pattern, ask: "Does this problem need this phase?"

Yes, and I can specify it now → Concrete sub-task
Yes, but I can't specify it until prior phases complete → Vague/pluripotent node
No → Skip this phase

Step 3: Sub-Task Specification

For each concrete sub-task:

sub_task:
  id: unique-name
  description: "What this sub-task produces (1-2 sentences)"
  type: concrete | vague
  depends_on: [upstream-sub-task-ids]
  parallelizable_with: [sibling-sub-task-ids]
  estimated_complexity: simple | moderate | complex
  suggested_model_tier: 1 | 2 | 3
  suggested_skills: [skill-names if known]
  output_description: "What the output looks like"

For each vague/pluripotent sub-task:

sub_task:
  id: unique-name
  description: "What this phase will address (1-2 sentences)"
  type: vague
  depends_on: [upstream-sub-task-ids]
  potential_paths:
    - "Path A: [exciting possibility 1]"
    - "Path B: [exciting possibility 2]"
    - "Path C: [exciting possibility 3]"
  expansion_trigger: on_upstream_complete

Step 4: Dependency Mapping

For each pair of sub-tasks, determine:

Data dependency: Does B need A's output? → Edge from A to B
Knowledge dependency: Does B need to know what A discovered? → Edge from A to B
No dependency: A and B are independent → Parallelizable

Step 5: Output

Produce a structured decomposition:

decomposition:
  problem: "original problem description"
  domain: "detected domain"
  meta_skill_used: "meta-skill name or 'zero-shot'"
  phases:
    - phase: 1
      sub_tasks: [concrete tasks for this phase]
    - phase: 2
      sub_tasks: [mix of concrete and vague tasks]
  total_concrete: 5
  total_vague: 3
  estimated_waves: 4
  estimated_cost: "$0.08 - $0.25"

Decomposition Heuristics

Granularity

Too fine: "Step 1: Open the file. Step 2: Read line 1." → Merge into one node
Too coarse: "Step 1: Build the entire app." → Split into design, implement, test, deploy
Right: Each sub-task is completable by one agent with 1-3 skills in one LLM call

Dependency Minimization

Fewer dependencies = more parallelism = faster execution. Prefer:

Independent parallel tracks over long sequential chains
Fan-out patterns (one source, many consumers) over daisy chains
Late merging (combine results at the end, not incrementally)

Vagueness is OK

Don't force specificity where it doesn't exist yet. A vague node saying "Build the solution (details TBD after design phase)" is more honest and more useful than a fake-specific node that will be wrong.

Anti-Patterns

Premature Specificity

Wrong: Specifying exact implementation details for phases that depend on undone research. Right: Mark dependent phases as vague/pluripotent. Show potential paths.

Sequential Everything

Wrong: A linear chain of 10 tasks with no parallelism. Right: Look for independent tracks. Research and content writing can often happen in parallel.

Missing the Meta-Skill

Wrong: Decomposing a bridge design project like a software project. Right: Detect the domain, load the appropriate meta-skill, follow its phase pattern.

task-decomposer