| name | heavy |
| description | Multi-perspective analysis for Codex using 3-5 parallel agents with different research territories. Use when asked for deep analysis, broad perspectives, tradeoff evaluation, or "/heavy". |
Heavy Multi-Perspective Analysis
Use /heavy when the answer gets better if multiple agents inspect different evidence before a synthesis step.
The point is information diversity, not personality cosplay. Do not ask five agents to read the same files and then pretend the output is deep because the tones are different.
Quick Start
Use this for prompts like:
/heavy should we move this service to Go?/heavy debate this architecture decision/heavy think deeply about why this queue keeps collapsing under load
Workflow
Print these labels as you go:
[1/6] Triaging question
[2/6] Designing the agent roster
[3/6] Launching parallel discovery
[4/6] Synthesizing findings
[5/6] Resolving open cruxes
[6/6] Delivering the final answer
1. Triage
Classify the question before spawning agents.
| Mode | Use when | Expected output |
|---|
| Evaluation | The user is deciding whether to do something | Recommendation with tradeoffs |
| Implementation | The user already wants to do it and needs the best path | Concrete plan or design |
| Complexity | Signals | Agent count |
|---|
| Quick | Small bounded decision | 2-3 |
| Standard | Several dimensions, but contained | 3-4 |
| Deep | Architectural, strategic, or high-stakes | 4-5 |
Default to Standard.
State the result explicitly:
TRIAGE: IMPLEMENTATION / STANDARD → 4 agents
2. Design the Agent Roster
Every agent must have:
- A perspective
- A research territory
- A concrete question to answer
Good territories:
- Code paths and call sites
- Tests, fixtures, and failure cases
- Docs, ADRs, and runbooks
- Git history and recent regressions
- External docs or recent web sources when freshness matters
- Product impact, performance risk, or operational burden
Bad territories:
- "Take a different vibe"
- "Be more optimistic"
- "Same evidence but pretend to disagree"
3. Launch Parallel Discovery
Use spawn_agent for bounded analysis tasks. Prefer explorer for codebase-specific research and default for broader analysis.
Each prompt should include:
- The exact question
- The agent's unique territory
- The evidence to inspect first
- The required output format
Suggested output format for agents:
## Discoveries
## Position
## Evidence
## Uncertainties
Rules:
- Fork context when the agent needs the full conversation
- Do not duplicate territories
- Include one adversarial agent for non-trivial questions
- Use long enough
wait timeouts to avoid busy polling
4. Synthesize
Your synthesis should not be a stitched summary. It should compress the agents into:
- Consensus
- Tensions
- Cruxes
- Surprises
- Recommendation
Useful final structure:
## Answer
## What The Agents Agreed On
## Where They Disagreed
## Cruxes That Matter
## Recommendation
## Open Questions
5. Resolve Cruxes
If one or two unresolved cruxes determine the answer, spawn follow-up agents only for those cruxes. Do not rerun the entire analysis.
Examples:
- "Check whether the bottleneck is actually Redis saturation or app-side serialization"
- "Verify whether this API limit changed recently"
6. Rules
- Prefer different evidence over different opinions
- When freshness matters, browse current sources
- When the question is about code, cite files and symbols
- When the question is strategic, include at least one downside-focused agent
- Stop when the answer is materially better than a single-agent response, not when every possible angle is exhausted
