root-cause-investigator

What this skill does

# Root Cause Investigator

Apply systematic 5-Why methodology to identify fundamental root causes of issues rather than treating symptoms. Guide thorough investigation through structured evidence gathering and analysis.

## Activation Triggers

- errors, bugs, or unexpected behavior
- build failures or test failures
- performance issues or degradation
- integration problems
- any "it's not working" scenarios

## The 5-Why Methodology

Systematically ask "why" five times to drill down to root cause:

1. **Why #1**: identify immediate cause (symptoms)
2. **Why #2**: uncover process/workflow issues
3. **Why #3**: find system-level problems
4. **Why #4**: discover design/architecture issues
5. **Why #5**: reveal fundamental root cause

## Investigation Workflow

### 1. Gather Initial Context

Collect information about the issue:

```
## Issue Summary
[brief description of reported problem]

## Initial Symptoms
- what user is experiencing
- error messages or logs
- observable behavior

## Context Gathering
- environment details
- recent changes
- related components
- steps to reproduce
```

### 2. Apply 5-Why Analysis

Structure the investigation with progressive depth:

```
## 5-Why Analysis

### Why #1: [surface cause]
Evidence: [logs, errors, behavior]
Impact: [what this affects]

### Why #2: [deeper cause]
Evidence: [code, configuration]
Impact: [cascading effects]

### Why #3: [system cause]
Evidence: [architecture, dependencies]
Impact: [broader implications]

### Why #4: [process/design cause]
Evidence: [patterns, decisions]
Impact: [long-term effects]

### Why #5: [root cause]
Evidence: [fundamental issue]
Impact: [core problem]
```

### 3. Identify Root Cause

Document the fundamental issue requiring attention:

```
## Root Cause Identified
[the fundamental issue that needs addressing]

## Recommended Investigation Areas
- specific files to examine
- components to test
- systems to verify
```

## Investigation Principles

1. **Avoid solution bias** - focus on understanding before fixing
2. **Gather evidence** - don't assume, verify with data
3. **Consider multiple causes** - issues often have multiple contributing factors
4. **Document findings** - clear documentation prevents repeat issues
5. **Think systemically** - consider broader implications
6. **Question assumptions** - challenge "it should work" thinking
7. **Use version control** - check when issue was introduced

## Using Reference Materials

Load reference files as needed during investigation:

- **references/patterns.md** - common root cause patterns by category (configuration, race conditions, resource exhaustion, integration failures, build/deployment issues)
- **references/techniques.md** - investigation techniques with command examples (error analysis, code investigation, dependency analysis, environment investigation)

## Best Practices

- resist proposing solutions until root cause is identified
- be thorough and methodical
- document evidence at each level of analysis
- verify assumptions with concrete data
- consider the issue from multiple perspectives (technical, environmental, architectural, external dependencies, process)

The goal is to find the fundamental cause, not just fix symptoms.