RecursiveProcessor

RecursiveProcessor is a GitHub Copilot subagent utility for recursive divide-and-conquer list processing. It is designed to be invoked by other agents/tools (not directly by end users), splitting a list into two ordered halves, processing both branches, and merging the results while respecting VS Code nesting limits.

Canonical contract at a glance

The normative behavior is defined in agents/RecursiveProcessor.agent.md.

user-invocable: false subagent-only design
Default depth is 1
Maximum nesting depth is 5
depth > 5 must always process locally/directly (never spawn subagents)
len(list) > 4 uses recursive split-and-process
len(list) <= 4 processes locally/directly

Prerequisites

Nested subagents are disabled by default in VS Code. Enable this setting to allow recursive subagent fan-out:

chat.subagents.allowInvocationsFromSubagents: true

VSCode Chat Plug-in

Agent plugins are currently in preview. Enable the following setting:

chat.plugins.enabled: true

After enabling, install the plugin with one click:

Local fallback when nested subagents are disabled

If nested subagent invocation is unavailable, RecursiveProcessor must fall back to local direct processing in the current invocation.

Correctness is preserved.
Parallelism is reduced.
End-to-end latency may increase for large lists.

Mode	Split when `len(list) > 4`	Subagent spawning	Parallel branches	Expected performance
ON (`allowInvocationsFromSubagents=true`)	Yes	Yes	Yes (left and right in the same batch)	Better parallel fan-out on large inputs
OFF	Yes (logical split may still be applied)	No	No	Correct but typically slower for large inputs

Algorithm

Each invocation receives a list and a current depth (default 1).

If depth > 5: process all items locally/directly. Never spawn subagents.
If depth == 5: process all items locally/directly (spawning would exceed platform limit).
Otherwise, if len(list) > 4:
- Split using the exact odd-size rule: left half gets ceil(n/2), right half gets floor(n/2)
- If nested subagents are enabled, invoke both halves as RecursiveProcessor subagents in the same parallel batch with depth + 1.
- If nested subagents are disabled, process both halves locally/directly.
- Merge both branch results.
Otherwise (len(list) <= 4): process items locally/directly.

Subagent description format

Level {N} | Group {X}/{T} | {first_item} → {last_item}

N = subagent depth (current_depth + 1)
X = 1-based group index at that level
T = total groups at that level (2^(N-1))
first_item / last_item = boundaries of the assigned slice

Repository structure

recursive-processor/ ├── agents/ │ └── RecursiveProcessor.agent.md # Canonical subagent contract ├── commands/ │ └── taxonomy-example.prompt.md # Example prompt for recursive list processing └── skills/ └── recursive-processor/ └── SKILL.md # Project skill that teaches when/how to invoke the subagent

Included example: biological taxonomy

commands/taxonomy-example.prompt.md demonstrates recursive processing on a list of 40 animals across 5 levels:

Level 1 (root): 40 items → split
Level 2:        2 groups of 20 → split (parallel when enabled)
Level 3:        4 groups of 10 → split (parallel when enabled)
Level 4:        8 groups of  5 → split (parallel when enabled)
Level 5:       16 groups of ≤3 → local direct processing

This yields the expected divide-and-conquer execution tree and bottom-up result merge.

Usage model

RecursiveProcessor is intended to be orchestrated by other agents and skills in this repository.

skills/recursive-processor/SKILL.md teaches discovery and usage patterns.
The taxonomy prompt is a repository example for invoking that orchestration flow.

This project is repository-scoped and focused on reusable recursive processing behavior.