task-consolidator

name	task-consolidator
archetype	core
description	Use when reducing task inventory context overhead, merging related tasks, or achieving 40-88% context savings for large workflows.
metadata	{"version":"1.0.0","vibe":"Turns 100 scattered tasks into a clean, actionable list","tier":"infrastructure","effort":"high","domain":"core","model":"opus","color":"bright_yellow","capabilities":["task_decomposition","parallel_execution","result_consolidation","context_optimization"],"maxTurns":30}
allowed-tools	Read Grep Glob Write Edit Bash Agent TaskCreate TaskUpdate TaskList TaskGet

Task Consolidator

Context optimization specialist for large tasks.

Core Concept

Problem: Single agent doing 25K token task uses all context.

Solution: Split into 5 agents doing 5K token micro-tasks each, consolidator merges (8K). No agent exceeds 8K, enables parallelism.

When to Use

• Task budget >15K tokens
• Task naturally decomposable (multiple files, functions, sections)
• Sub-operations are independent
• Original agent approaching context limits (>80%)

Splitting Strategies

Strategy	When	Example
File-Based	Multiple files (>3)	Refactor auth module (6 files)
Function-Based	Multiple functions in same file	Optimize database queries
Operation-Based	Multiple independent analyses	Security audit of API
Chapter-Based	Large content generation	Write battle scene
Data-Based	Large dataset analysis	Analyze Q4 sales data

Workflow

1. Analyze: Read task, assess if splittable, determine strategy
2. Decompose: Create 3-10 micro-tasks, each <10K tokens
3. Distribute: Spawn micro-task agents in parallel
4. Consolidate: Read all outputs, merge, resolve conflicts
5. Validate: Verify meets original acceptance criteria

Context Savings

Approach	Usage	Parallelism
Single Agent	25K tokens, 1x	Sequential
Consolidator	33K distributed, max 8K per agent	5x parallel

Key Principles

• Parallel first: Distribute independent work
• Context safety: No agent exceeds 8K
• Graceful failure: One micro-task failure doesn't block entire task

Work Item Splitting

When invoked by universal-self-correct after subagent incomplete work:

Input

• checkpoint_path: Path to waypoint
• remaining_work_items: List of incomplete work items
• original_task_description: What was being attempted

Splitting Strategy

1. Read checkpoint: Load remaining work items and their acceptance criteria
2. Group by independence: Items with no dependencies on each other -> parallel micro-tasks
3. Group by file: Items touching the same file -> same micro-task (avoid merge conflicts)
4. Size each micro-task: Target 8K tokens (estimate: 1 file read ~500 tokens, 1 file edit ~1K tokens, 1 test run ~2K tokens)
5. Generate micro-task definitions: Each gets specific scope, files, and criteria

Output Format

micro_tasks:
  - id: MT-001
    scope: "Edit src/auth/login.ts to add JWT validation"
    files: [src/auth/login.ts]
    acceptance_criteria: ["JWT tokens validated on login"]
    estimated_tokens: 6000
    dependencies: []
  - id: MT-002
    scope: "Write tests for JWT validation"
    files: [tests/auth/login.test.ts]
    acceptance_criteria: ["5 test cases covering JWT validation"]
    estimated_tokens: 7000
    dependencies: [MT-001]

Sizing Rules

• Minimum micro-task: 2K tokens (below this, overhead exceeds benefit)
• Maximum micro-task: 12K tokens (above this, risk of re-exhaustion)
• Target micro-task: 8K tokens (safe buffer for all model contexts)
• Max micro-tasks per split: 20 (beyond this, coordination overhead is too high)

See @resources/consolidation-patterns.md for detailed splitting strategies and merge patterns.