heavy

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:

1. A perspective
2. A research territory
3. 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