---
name: parallel-investigation
description: Coordinates parallel investigation threads to simultaneously explore multiple hypotheses or root causes across different system areas. Use when debugging production incidents, slow API performance, multi-system integration failures, or complex bugs where the root cause is unclear and multiple plausible theories exist; when serial troubleshooting is too slow; or when multiple investigators can divide root-cause analysis work. Provides structured phases for problem decomposition, thread assignment, sync points with Continue/Pivot/Converge decisions, and final report synthesis.
version: 1.0.0
triggers:
  - investigate in parallel
  - multiple approaches
  - divide investigation
  - complex problem
  - explore options
tags:
  - collaboration
  - investigation
  - parallel
  - problem-solving
difficulty: advanced
estimatedTime: 15
relatedSkills:
  - debugging/root-cause-analysis
  - collaboration/handoff-protocols
---

# Parallel Investigation

Coordinate parallel investigation threads to explore multiple hypotheses simultaneously. Most effective for production incidents, performance regressions, or integration failures where the root cause is unclear.

## Core Principle

**When uncertain, explore multiple paths in parallel. Converge when evidence points to an answer.**

Parallel investigation reduces time-to-solution by eliminating serial bottlenecks.

## Investigation Structure

### Phase 1: Problem Decomposition

Break the problem into independent investigation threads:

```
Problem: API responses are slow

Investigation Threads:
├── Thread A: Database performance
│   └── Check slow queries, indexes, connection pool
├── Thread B: Application code
│   └── Profile endpoint handlers, check for N+1
├── Thread C: Infrastructure
│   └── Check CPU, memory, network latency
└── Thread D: External services
    └── Check third-party API response times
```

Each thread should be independent (no blocking dependencies), focused (clear scope), and time-boxed.

### Phase 2: Thread Assignment

Assign threads with clear ownership:

```markdown
## Thread A: Database Performance
**Investigator:** [Name/Agent A]
**Duration:** 30 minutes
**Scope:**
- Query execution times
- Index utilization
- Connection pool metrics
**Report Format:** Summary + evidence
```

### Phase 3: Parallel Execution

Each thread follows this pattern:

1. Gather evidence specific to thread scope
2. Document findings as you go
3. Identify if thread is a lead or dead end
4. Prepare summary for sync point

**Thread Log Template:**
```markdown
## Thread: [Name]
**Start:** [Time]

### Findings
- [Timestamp] [Finding]

### Evidence
- [Log/Metric/Screenshot]

### Preliminary Conclusion
[What this thread suggests about the problem]
```

### Phase 4: Sync Points

Regular convergence to share findings:

```
Sync Point Agenda:
1. Each thread report (2 min each)
2. Discussion & correlation (5 min)
3. Decision: Continue, Pivot, or Converge (3 min)
```

**Sync Point Decisions:**
- **Continue**: Threads are progressing, maintain parallel execution
- **Pivot**: Redirect threads based on new evidence
- **Converge**: One thread found the answer, others join to validate

### Phase 5: Convergence

When a thread identifies the likely cause:

1. **Validate** — Other threads verify the finding
2. **Deep dive** — Focused investigation on identified cause
3. **Document** — Compile findings from all threads

## Coordination Patterns

**Hub and Spoke**: One coordinator assigns threads, tracks progress, calls sync points, and makes convergence decisions. Best when one person has the most context.

**Peer Network**: Equal investigators post findings to a shared channel and self-organize convergence when a pattern emerges. Best when investigators have similar expertise.

## Communication Protocol

### During Investigation

```
[Thread A] [Status] Starting query analysis
[Thread B] [Finding] No N+1 patterns in user endpoint
[Thread A] [Finding] Slow query: SELECT * FROM orders WHERE...
[Thread C] [Dead End] CPU and memory within normal
[Thread A] [Hot Lead] Missing index on orders.user_id
```

### At Sync Point

```markdown
## Thread A Summary

**Status:** Hot Lead
**Key Finding:** Missing index on orders.user_id
**Evidence:** Query taking 3.2s, explain shows full table scan
**Recommendation:** Likely root cause — suggest converge
```

## Decision Framework

| Thread Status | Action |
|---------------|--------|
| All exploring | Continue parallel |
| One hot lead | Validate lead, others support |
| Multiple leads | Prioritize by evidence strength |
| All dead ends | Reframe problem, new threads |
| Confirmed cause | Converge, begin fix |

## Time Management

A typical two-hour investigation:

```
0:00  Problem decomposition & thread assignment
0:15  Parallel investigation begins
0:45  Sync point #1 → Continue/Pivot/Converge decision
1:30  Sync point #2 (if continuing)
1:35  Final convergence & documentation
```

Adjust sync point cadence based on incident severity — every 20 minutes for critical outages, every 45 minutes for lower-urgency investigations.

## Documentation

### Final Report Structure

```markdown
# Investigation: [Problem]

## Summary
[Brief description and resolution]

## Threads Explored

### Thread A: [Area]
- Investigator: [Name]
- Findings: [Summary]
- Outcome: [Lead / Dead End / Root Cause]

## Root Cause
[Detailed explanation of what was found]

## Evidence
- [Evidence 1]
- [Evidence 2]

## Resolution
[What was done to fix]

## Lessons Learned
- [Learning 1]
```

## Integration with Other Skills

- **debugging/root-cause-analysis**: Each thread follows RCA principles
- **debugging/hypothesis-testing**: Threads test specific hypotheses
- **handoff-protocols**: When passing a thread to another person