investigate

Diagnose production incidents using a five-phase evidence-based investigation methodology.

Updated Mar 26, 2026
One-click install
npx skills add https://github.com/erwinv2k-TKG/AgentesVSC --skill investigate-erwinv2k-tkg
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: investigate
Source: https://github.com/erwinv2k-TKG/AgentesVSC/tree/main/packs/incidentfox/local/claude_code_pack/skills/investigate
Command: npx skills add https://github.com/erwinv2k-TKG/AgentesVSC --skill investigate-erwinv2k-tkg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When production systems fail or degrade, engineers often jump straight into raw logs and guess at causes, wasting time and missing the real root cause. This Skill provides a structured five-phase SRE investigation methodology that enforces evidence-based reasoning before conclusions. ## Core Features & Use Cases - Systematic 5-Phase Workflow: Scope the problem, gather statistics-first evidence, form ranked hypotheses, test them, and conclude with a structured root-cause report. - Tool-Guided Evidence Gathering: Directs use of Datadog and CloudWatch metrics, anomaly detection, change-point analysis, log aggregation, and Kubernetes pod events before raw logs. - Structured Conclusions: Produces root cause statements with supporting evidence, confidence levels, remediation actions, and explicit caveats. - Use Case: A latency spike hits your API after a deployment. The Skill walks you through correlating metrics, finding the change point, checking pod events, and ranking hypotheses before declaring a cause. ## Quick Start Investigate the current latency spike in the payments service and identify the root cause with supporting evidence.

Frequently Asked Questions about investigate

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I investigate a production incident systematically?

Follow the five-phase methodology: scope the symptom and impact, gather metrics and log statistics first, form ranked hypotheses, test each against specific evidence, then conclude with a root cause, confidence level, and remediation actions.

What tools does this incident investigation workflow use?

It uses Datadog and CloudWatch metrics queries, anomaly detection, metric correlation, change-point analysis, CloudWatch Insights log aggregation, and Kubernetes commands like get_pod_events, list_pods, and get_pod_resources.

Why should I check metrics before raw logs during an outage?

Metrics and aggregated statistics reveal the scale and timing of a problem faster than raw logs. Starting with anomaly detection and change-point analysis narrows the search space before you sample individual log lines.

Should I check Kubernetes pod events or pod logs first?

Check pod events first with get_pod_events, since events explain most issues faster, such as scheduling failures, OOM kills, or image pull errors. Use get_pod_logs only after events and overall pod health are reviewed.

What are the limitations of this investigation methodology?

It depends on the availability of metrics, logs, and Kubernetes tooling in your environment, and it caps investigation at roughly 6-8 tool calls per phase. It explicitly acknowledges uncertainty rather than fabricating conclusions when evidence is insufficient.