Task Decomposer

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.

Decision Points

1. DOMAIN CLASSIFICATION
   ├─ Contains {"build", "implement", "code", "app"} → Use software-project-decomposition
   ├─ Contains {"research", "analyze", "report"} → Use research-synthesis-decomposition
   ├─ Contains {"design", "UI", "prototype"} → Use product-design-decomposition
   ├─ Contains {"data", "model", "train", "ML"} → Use ml-project-decomposition
   └─ No clear domain signals → Zero-shot decomposition

2. SUB-TASK GRANULARITY
   ├─ Can one agent complete in one call? → Correct granularity
   ├─ Requires multiple agent calls/skills? → Split into smaller sub-tasks
   └─ Too trivial (open file, read line)? → Merge with adjacent sub-task

3. DEPENDENCY DETECTION
   ├─ B needs A's output data? → Create data dependency A→B
   ├─ B needs A's knowledge/decisions? → Create knowledge dependency A→B
   ├─ A and B share no inputs/outputs? → Mark as parallelizable
   └─ Circular reference detected? → Invalid, restructure phases

4. VAGUENESS CLASSIFICATION
   ├─ Can specify concrete steps now? → Create concrete sub-task
   ├─ Depends on upstream discoveries? → Create vague node with 3+ potential paths
   └─ Requires human decision? → Mark as human-gate candidate

5. COMPLEXITY ESTIMATION
   ├─ Single skill, clear inputs/outputs? → Mark as "simple" (Tier 1 model)
   ├─ 2-3 skills, moderate reasoning? → Mark as "moderate" (Tier 2 model)
   └─ Complex reasoning, multiple domains? → Mark as "complex" (Tier 3 model)

Failure Modes

Worked Examples

Example 1: Software Project - "Build a URL shortener API"

Step 1: Domain Classification

• Keywords: "build", "API" → software-project-decomposition
• Load phases: [requirements, design, implement, test, deploy]

Step 2: Phase Application

• Requirements: Concrete (can specify API endpoints now)
• Design: Concrete (database schema, API structure)
• Implement: Vague (depends on design decisions)
• Test: Vague (depends on implementation approach)
• Deploy: Concrete (standard containerization)

Step 3: Sub-task Creation

phase_1_requirements:
  - id: "api-spec"
    type: concrete
    description: "Define REST endpoints, request/response schemas"
    complexity: simple

phase_2_design:
  - id: "data-model"
    type: concrete
    description: "Design database schema for URLs, clicks, users"
    complexity: moderate
  
  - id: "system-architecture"
    type: concrete
    description: "Choose tech stack, define service boundaries"
    complexity: moderate

phase_3_implement:
  - id: "core-logic"
    type: vague
    depends_on: ["data-model", "system-architecture"]
    potential_paths:
      - "Microservices with Redis cache"
      - "Monolith with in-memory cache"
      - "Serverless with DynamoDB"

Step 4: Dependency Mapping

• api-spec → data-model (knowledge dependency)
• data-model + system-architecture → core-logic (data dependency)
• api-spec and data-model parallelizable (no shared inputs)

Expert insight: Novice would make implementation concrete too early. Expert keeps it vague until design completes.

Example 2: Research Project - "Analyze remote work impact on productivity"

Step 1: Domain Classification

• Keywords: "analyze", "research" → research-synthesis-decomposition
• Load phases: [scope, gather, analyze, synthesize, report]

Step 2: Critical Decisions

• Scope concrete: Can define research questions now
• Gather vague: Data sources depend on scoping decisions
• Analysis vague: Methods depend on what data we find

Step 3: Decomposition

phase_1_scope:
  - id: "research-questions"
    type: concrete
    description: "Define 3-5 specific research questions about remote work productivity"

phase_2_gather:
  - id: "data-collection"
    type: vague
    depends_on: ["research-questions"]
    potential_paths:
      - "Academic papers + industry reports"
      - "Survey new dataset of remote workers"
      - "Interview case studies from companies"

phase_3_analyze:
  - id: "statistical-analysis"
    type: vague
    depends_on: ["data-collection"]
    potential_paths:
      - "Quantitative analysis if numerical data"
      - "Qualitative coding if interview data"
      - "Meta-analysis if literature review"

Expert insight: Research decomposition keeps analysis methods vague until data characteristics are known. Novice would prematurely commit to statistical methods.

Quality Gates

Task decomposition is complete when:

• Every vague node has 3+ potential paths listed
• No concrete sub-task requires more than 3 skills
• All dependencies form valid DAG (no cycles)
• At least 30% of sub-tasks are parallelizable
• Each sub-task has clear output description
• Domain meta-skill selected (or justified why zero-shot)
• Complexity estimates assigned (simple/moderate/complex)
• Total estimated cost under $5 for initial wave
• Critical path identified (longest dependency chain)
• Human gates marked for irreversible decisions

NOT-FOR Boundaries

This skill should NOT be used for:

• DAG Structure Building: Once you have sub-tasks, use dag-planner to create node/edge graph
• Task Execution: Use dag-runtime to actually run the decomposed tasks
• Skill Assignment: Use dag-skills-matcher to assign specific skills to each node
• Project Management: For tracking progress/deadlines, use project management tools
• Code Generation: This creates task plans, not code. Use appropriate coding skills for implementation
• Data Processing: This plans data workflows, doesn't process data. Use data analysis skills for execution

Delegation rules:

• For executing any decomposed sub-task → Use appropriate domain skill
• For building DAG from sub-tasks → Use dag-planner
• For assigning skills to nodes → Use dag-skills-matcher
• For runtime orchestration → Use dag-runtime