| name | progressive-research |
| description | Broad-to-narrow research Orchestration - start with a wide census, harden the scope from returned Evidence, and specialize Subagents only once the exact situation is proven. TRIGGER when the Architect says "progressive research", "start broad", or when dispatching research or debugging Subagents into a situation whose cause or shape is unknown. DO NOT TRIGGER when the exact scope is already proven - dispatch the specialized Subagent per /subagents directly. |
Progressive Research
- The Orchestrator owns every scoping judgment; Subagents never widen their own Task.
- One Process: widen first, narrow on Evidence, specialize last.
1. Census the whole surface first
Dispatch one broad read-only Subagent with no preconceived taxonomy: inventory what is observably true, quoted and cited.
Never dispatch on a guess
A narrow dispatch encodes the Orchestrator's guess as the Subagent's Task. The Subagent then verifies the guess instead of reality, and one bad guess burns every Subagent downstream.
Never: "the padding system is broken — fix it" before a census showed the padding system owns the symptom.
2. Harden the scope on returned Evidence
Fold the census findings into a narrower question and dispatch sharper Subagents, repeating until the exact nature of the situation is proven.
Keep research Subagents read-only
Research Subagents return findings only — no fixes, no scope changes, no recommendations.
IF a Subagent's findings contradict the current scope:
Re-widen instead of pushing the Subagent
The scope was wrong, not the Subagent. Return to the census Evidence with the contradiction as new input.
3. Specialize only at proven scope
Dispatch the implementing Subagent per /subagents with one singular, unchanging Task.
