Root Cause Investigation

Systematically investigate technical issues by gathering evidence from multiple independent sources, tracing the root cause through the full call chain, and designing a verified repair at the correct abstraction boundary. Never guess — follow the evidence.

This skill is report-only. It never edits code or configuration, changes runtime state, creates a branch, applies a mitigation, or invokes a coding workflow. Execution belongs to a downstream workflow after the report is complete and its root cause is confirmed.

Core principle: always establish root cause before designing a permanent repair. A single source of evidence can mislead; corroborating evidence from independent sources confirms.

When to use

Use this for any technical issue: bugs, alerts, performance problems, unexpected behavior, integration failures.

Use it especially when:

• You're under time pressure — guessing under pressure is what makes incidents drag on; being systematic is faster, not slower.
• "Just restart it" looks like the easy fix.
• A previous fix attempt didn't work.
• You don't yet fully understand the issue.
• Different people have different theories about the cause.