SkillVaultskills Browse all 500 skills

Reliability · Version 1.6.0 · Reviewed 2026-08-02

Root Cause Analysis Agent

Reduce production risk in contributing factor analysis and trigger versus cause with evidence, explicit trade-offs, and a verification plan.

4 method steps 5 documented failure modes 5 diagnostic checks 7 quality gates

Separates trigger from cause, walks the contributing-factor chain, and stops at systemic fixes rather than the first plausible culprit.

₹99 one-time

Get this skill archive

What this skill helps you do

  • Contributing factor analysis
  • Trigger versus cause
  • Systemic remediation

How Root Cause Analysis Agent works

You provide

Symptom timeline, change log, and affected subset

It inspects

What changed, what correlates, and what recovered

It decides

The cause that explains onset, symptoms, and recovery

You verify

The cheapest test that falsifies the remaining hypothesis

What it checks first

Root Cause Analysis Skill separates trigger from cause, walks the contributing-factor chain, and stops at systemic fixes rather than the first plausible culprit. Use it when the work involves Contributing factor analysis, Trigger versus cause, Systemic remediation.

  1. What changed within the window before onset: deploys, flags, config, traffic, data volume, and certificate or token expiry.
  2. Whether the failure is correlated with a subset (region, tenant, version, device) — a correlated subset localizes the cause immediately.
  3. The first failing component in the dependency chain, distinguished from the loudest alert.
  4. Whether the symptom is a step change or a gradual degradation, which separates a change-driven from a growth-driven cause.
  5. Whether the system recovered on its own, which points to saturation rather than corruption.

Failure modes it recognizes

  • Resource exhaustion where the visible failure occurs in an unrelated component that shares a connection pool.
  • A dependency slowdown surfacing as caller thread-pool exhaustion, so the caller looks broken instead.
  • Clock skew or expiry (certificate, token, license) producing a sharp failure with no correlated deploy.
  • A data-dependent bug triggered by a record that first appeared in production traffic that day.
  • Cascading failure where the retry behavior of healthy clients sustains the outage after the original fault clears.

Answers it will reject

  • Accepting correlation as causation because the timing matched, without a mechanism that explains every symptom.
  • Stopping at the component that alerted, which is frequently the victim rather than the cause.
  • Changing multiple variables at once during diagnosis, which destroys the ability to attribute recovery.
  • Declaring root cause when the hypothesis explains the failure but not the recovery, or vice versa.

Decision rules it applies

  • A candidate cause must explain onset, every observed symptom, the affected subset, and the recovery. If it explains only some, it is incomplete.
  • Prefer the cheapest test that can eliminate the largest number of hypotheses.
  • If nothing changed in the system, something changed in its inputs — look at data and traffic shape.
  • Update confidence only on evidence; time spent believing a hypothesis is not evidence for it.

Evidence it asks for

  • Overlay the deploy and config-change timeline on the error-rate graph at the same resolution.
  • Break the metric down by region, version, tenant, and instance to find the correlated subset.
  • Compare saturation signals (queue depth, pool utilization, connection count) against the latency onset.

The method inside

  1. Reconstruct the symptom timeline and define what healthy behavior would look like for contributing factor analysis.
  2. Rank hypotheses for trigger versus cause by evidence, blast radius, and ability to explain every observed symptom.
  3. Run the cheapest discriminating check for systemic remediation; update confidence only when evidence changes.
  4. Separate immediate stabilization, confirmed cause, contributing conditions, and prevention; finish with a reproducible verification.

Deliverables

  • Contributing factor analysis assessment
  • Trigger versus cause decision and action plan
  • Systemic remediation verification checklist

Evidence requirements

  • User-visible symptoms and SLO impact
  • Timeline, telemetry, deploys, and dependency state
  • Current mitigations and operational constraints

Quality gates

  • Every material claim traces to supplied evidence or is labeled as a hypothesis.
  • The response follows the declared deliverable contract.
  • No execution, access, measurement, or verification is invented.
  • Secrets and personal data are redacted rather than repeated.
  • The user receives a concrete independent verification step.
  • The relevant failure modes in this domain were considered rather than only the reported symptom.
  • No listed anti-pattern was recommended as a solution.

Example task

Input

A deploy caused an outage. Leadership wants to know the root cause and whether we should slow releases.

Expected output

The deploy was the trigger. The cause is that a single slow dependency could saturate the request pool, which the deploy merely exposed...

Boundaries and compatibility

Ideal for

  • Contributing factor analysis: produce a decision or artifact grounded in supplied evidence.
  • Trigger versus cause: produce a decision or artifact grounded in supplied evidence.
  • Systemic remediation: produce a decision or artifact grounded in supplied evidence.

Out of scope

  • Replacing incident command authority
  • Calling a trigger the root cause without a causal chain

Agent compatibility

  • GitHub Copilot custom agents
  • Claude Agent Skills / SKILL.md
  • Any instruction-following chat model

Tool policy: Advisory by default. No tools are assumed. If the host provides tools, use read-only evidence gathering unless the user explicitly approves a scoped write or execution action.