Delegate

Delegate

Parallel execution coordinator. Read a plan or conversation context, decompose it into a dependency-ordered task graph, and spawn worker sub-agents in parallel waves. Each wave completes before the next begins. Results are collected, validated, and reported.

Core principle: maximize parallelism while respecting dependencies absolutely.

Decision Flow

flowchart TD
    A["Resolve input: $ARGUMENTS or conversation context"] --> B{Plan found?}
    B -->|No| FAIL["Report: no plan found"]
    FAIL --> MEM_FAIL[Memory Protocol]

    B -->|Yes| C["Step 2: Deep-think task decomposition"]
    C --> D["Step 3: Build dependency graph"]
    D --> E["Step 4: Create tasks + compute waves"]
    E --> F{--dry-run?}
    F -->|Yes| DRY["Report: task graph + wave plan"]
    DRY --> MEM_DRY[Memory Protocol]

    F -->|No| G["Step 5: Execute Wave N"]
    G --> G1["Worker A"]
    G --> G2["Worker B"]
    G --> G3["Worker C"]
    G1 & G2 & G3 --> H{All passed?}
    H -->|No| I["Mark dependents BLOCKED, continue independent"]
    I --> J{More waves?}
    H -->|Yes| J
    J -->|Yes| G
    J -->|No| K["Step 6: Validate"]
    K --> L["Step 7: Report"]
    L --> MEM_OP[Memory Protocol]

Instructions

1. Resolve input

Arguments received: $ARGUMENTS

• If --plan <path> is provided, read that file
• If no arguments, use the current conversation context (the plan should be visible from a prior /prd, plan discussion, or issue triage output)
• If --dry-run is present, set DRY_RUN=true

If no plan is found in either source, report:

No plan found. Provide a plan file path with --plan <path> or discuss the plan first, then run /delegate.

Run Memory Protocol and stop.

2. Decompose into tasks (use extended thinking)

Analyze the plan deeply and produce a structured task list. For each task, determine:

Field	Description
ID	Sequential: T1, T2, T3, ...
Title	Short imperative description
Description	What the worker agent needs to do (2-3 sentences, include file paths)
Depends On	Task IDs this requires first, or "none"
Files	Key files the worker will read or modify
Model	haiku (config/docs) / sonnet (standard, default) / opus (only multi-file architecture synthesis)
Acceptance	How to verify the task is done (objectively checkable)

Decomposition rules:

• Each task must be completable by a single sub-agent in one session
• Prefer more smaller tasks over fewer larger ones
• Schema/infrastructure before backend, backend before frontend
• Tasks that touch different files with no shared state CAN be parallel
• Tasks that modify the same file or depend on another's output MUST be sequential
• Every task must have at least one verifiable acceptance criterion
• Each task must have a distinct, non-overlapping scope — do not spawn redundant workers for the same files
• A task that is itself multi-step and parallelizable MAY recursively delegate via the Agent tool — but only if the worker's task description includes explicit Max depth: N and Step budget: N fields (see context/rules/recursive-delegation.md). Absent those fields, workers stay flat.

3. Build dependency graph and compute waves

Arrange tasks into parallel execution waves using topological ordering:

1. Wave 1: All tasks with Depends On: none -- run first, in parallel
2. Wave 2: All tasks whose dependencies are entirely within Wave 1
3. Wave N: All tasks whose dependencies are entirely within Waves 1..N-1

Output the wave plan:

Wave	Tasks	Parallelism	Complexity
1	T1, T2, T3	3 agents	S + S + M
2	T4, T5	2 agents	M + S
3	T6	1 agent	L

Validation:

• No circular dependencies (if found, report error and stop)
• Max 5 concurrent agents per wave (split larger waves into sub-waves)

4. Create tasks and track dependencies

Use TaskCreate for each task. Then use TaskUpdate with addBlockedBy to wire dependencies.

If --dry-run, output the full task graph and wave plan, then skip to Step 8.

5. Execute waves

For each wave, starting from Wave 1:

a) Spawn worker agents in ONE message (parallel)

Launch N Agent tool calls in a single message for parallel execution. Each worker receives:

• Task ID, title, description, files, and acceptance criteria
• Summaries of completed prior-wave results (not full output)
• Instruction: report what was done, what files changed, whether acceptance criteria are met

Worker configuration:

• Model: as specified in the task decomposition (haiku/sonnet/opus)
• run_in_background: true (for waves with 2+ tasks)

a.1) Recursion-authorization gate

If any worker's task description authorizes recursive delegation (Max depth: N with N ≥ 2), confirm before spawning that all three fields are present in that worker's briefing:

• Max depth: N
• Max children per level: M (M ≤ 5)
• Step budget: S

If any field is missing, either add it or downgrade the task to flat execution (Max depth: 1). Workers without all three fields MUST stay flat — they have no authority to spawn grandchildren regardless of how the task is described in prose. See context/rules/recursive-delegation.md for the full protocol.

b) Collect results

After all agents in the wave complete, update each task via TaskUpdate:

Task	Status	Summary	Files Changed
T1	completed	Created schema migration	prisma/schema.prisma
T2	completed	Added API route	src/app/api/...
T3	FAIL	Type error in ...	--

c) Handle failures

If any task fails:

• Log the failure with details
• Check if tasks in subsequent waves depend on the failed task
• Mark dependent tasks as BLOCKED (do not execute them)
• Continue with non-dependent tasks in the next wave

d) Advance to next wave

Pass completed task summaries as context to the next wave's workers. Repeat until all waves complete or all remaining tasks are blocked.

6. Validate

After all waves complete:

1. Review acceptance criteria for every completed task
2. If the plan involved code changes, run verification:

cd ~/harness && pnpm -r run lint 2>&1 || true
cd ~/harness && pnpm -r run build 2>&1 || true
cd ~/harness && pnpm -r run test 2>&1 || true

3. If validation fails, note which tasks likely caused the failure

7. Report

Output a structured summary:

## Delegation Report

### Task Summary
| Task | Wave | Status | Summary |
|------|------|--------|---------|
| T1   | 1    | DONE   | ...     |
| T2   | 1    | DONE   | ...     |
| T3   | 1    | FAIL   | ...     |
| T4   | 2    | BLOCKED| Depends on T3 |

### Execution Stats
- Total tasks: N
- Completed: N
- Failed: N
- Blocked: N
- Waves executed: N
- Max parallelism: N agents

### Validation
- Type check: PASS/FAIL
- Lint: PASS/FAIL
- Tests: PASS/FAIL

### Issues Requiring Attention
- [list any failures, blocked tasks, or validation errors]

8. Memory Improvement Protocol

Run at the end of every execution -- op, dry-run, or error.

a) Log -- append to memory/<today>/log.md where today = date -u +%Y-%m-%d:

## Delegate -- HH:MM UTC
- **Result**: OP | DRY-RUN | PARTIAL | FAIL
- **Plan**: "<plan title or source>"
- **Action**: [N tasks across M waves, P parallel max; X completed, Y failed, Z blocked]
- **Duration**: ~Xs
- **Observation**: [one sentence]

See context/rules/memory.md for the canonical Memory Improvement Protocol.

Reference

Wave Execution Rules

Rule	Value
Max concurrent agents per wave	5 (split larger waves)
Failure handling	Mark dependent tasks BLOCKED, continue independent ones
Context passing	Prior wave summaries, not full output
Model selection	haiku: config/docs, sonnet: standard (default), opus: synthesis only

Key Resources

Resource	Path
Agent: Implementer	.claude/agents/implementer.md
Agent: Critic	.claude/agents/critic.md
Agent: PM	.claude/agents/pm.md
Agent: Council	.claude/agents/council.md
Identity	IDENTITY.md
Memory	MEMORY.md
Daily Logs	memory/YYYY-MM-DD/log.md