ss-inspectlisted

# 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. Don't skip it because the issue looks simple (simple bugs have root causes too), because you're in a hurry (rushing guarantees rework), or because someone suggests "just try X" (guessing costs more time than investigating). ## The iron law ```text NO FIX WITHOUT A ROOT CAUSE CONFIRMED B