kepner-tregoe-network-troubleshooting

Diagnose network faults using structured Kepner-Tregoe root-cause analysis workflows.

650|182|Updated Feb 19, 2026
One-click install
npx skills add https://github.com/automateyournetwork/netclaw --skill kepner-tregoe-network-troubleshooting
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kepner-tregoe-network-troubleshooting
Source: https://github.com/automateyournetwork/netclaw/tree/main/workspace/skills/kepner-tregoe-network-troubleshooting
Command: npx skills add https://github.com/automateyournetwork/netclaw --skill kepner-tregoe-network-troubleshooting

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Network troubleshooting often devolves into guess-and-swap: engineers pattern-match to familiar causes, swap components, and fix symptoms instead of root causes. This Skill enforces the Kepner-Tregoe rational-process method so an agent specifies the fault boundary before hypothesizing, tests candidate causes against evidence, verifies the root cause before changing anything, and separates the fast reversible incident fix from the permanent fix.

Core Features & Use Cases

  • Problem Analysis: Build an IS/IS-NOT specification across WHAT, WHERE, WHEN, and EXTENT dimensions, generate causes only from observed distinctions and changes, and verify the most probable cause with a read-only test before acting.
  • Situation Appraisal: Triage alert storms by rating concerns on Seriousness, Urgency, and Growth, collapsing correlated alarms into one root, and hunting the outlier that signals a second incident.
  • Decision Analysis & Potential Problem Analysis: Choose fixes with MUST/WANT screening plus adverse-consequence review, and protect planned changes with preventive and contingent actions that have explicit triggers and owners.
  • Use Case: During an outage where checkout, payments, and a warehouse app all fail while a core switch logs errors, use the Skill to collapse the symptoms to one infrastructure fault, specify the boundary, verify a misconfigured LAG change as the cause, apply a reversible rollback, and protect the permanent fix.

Quick Start

Use the kepner-tregoe-network-troubleshooting skill to diagnose why users at one branch site cannot reach the ERP application while all other sites work fine.

Frequently Asked Questions about kepner-tregoe-network-troubleshooting

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

FAQPage Schema
How do I troubleshoot a network outage with root cause analysis?

Use Problem Analysis: state one object and one defect, build an IS/IS-NOT specification across WHAT, WHERE, WHEN, and EXTENT, generate causes only from observed distinctions and changes, then test each cause against the full specification. Verify the most probable cause with a read-only command or log check before applying any fix.

How do I triage multiple network alarms during an alert storm?

Use Situation Appraisal: list each concern separately, rate it on Seriousness, Urgency, and Growth, then collapse alarms sharing a time and location signature into one root cause. Investigate the single outlier alarm separately because it may be a second independent incident.

What is the IS/IS-NOT method in Kepner-Tregoe problem analysis?

IS/IS-NOT is a specification grid recording where a fault appears versus the nearest comparable place, time, or object where it could appear but does not. The IS-NOT boundary eliminates whole classes of causes, since any candidate cause that contradicts an IS-NOT observation is ruled out.

When should I not run the full Kepner-Tregoe troubleshooting process?

Skip the full method for known trivial faults with obvious fixes, such as an admin-down port, full disk, or expired certificate. Reserve the complete apparatus for genuinely unknown causes, large blast radius, cluttered situations, or changes that are expensive to reverse.

Can this skill make configuration changes to network devices automatically?

No. The skill diagnoses and recommends freely but requires explicit human authorization before any state-changing action such as config changes, failovers, or reboots. Read-only investigation and verification commands need no confirmation.

How do I protect a planned network change or migration from failing?

Use Potential Problem Analysis: for each vulnerable step, define a preventive action that reduces the probability of failure and a contingent action with an observable trigger and named owner. Never remove the fallback until the replacement is verified working.