Use when a defect is selective (some endpoints/regions/users/times affected, not all) and the cause is unclear — map what IS vs IS-NOT affected; the boundary contrast points at the root cause.
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/thinking-kepner-tregoe
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when a defect is selective (some endpoints/regions/users/times affected, not all) and the cause is unclear — map what IS vs IS-NOT affected; the boundary contrast points at the root cause.
📊 Stats
Stars863
Forks126
LanguageJavaScript
LicenseMIT
📦 Ships with thinking-skills
</> SKILL.md
thinking-kepner-tregoe.SKILL.md
---name: thinking-kepner-tregoe
description: Use when a defect is selective (some endpoints/regions/users/times affected, not all) and the cause is unclear — map what IS vs IS-NOT affected; the boundary contrast points at the root cause.
---# Kepner-Tregoe Problem Analysis
## Overview
Kepner-Tregoe (KT) is a structured root-cause method. **This skill focuses on Problem Analysis (PA) — the IS/IS-NOT boundary contrast — which is the high-value KT process for debugging.** When a defect is *selective* (some cases affected, others not), the boundary between IS and IS-NOT reveals the distinction that points at the root cause.
Decision Analysis (DA) and Potential Problem Analysis (PPA) are de-emphasized here. For pure decision-making among alternatives, use `thinking-opportunity-cost`. For risk anticipation before a change, use `thinking-pre-mortem`. Those skills are purpose-built for those tasks; KT's DA/PPA add overhead without unique mechanism.
Situation Analysis (SA) is retained as a lightweight triage step when facing multiple concerns, but it is not a required preamble — jump directly to PA when the problem is already clear.
**Core Principle:** The boundary between what IS affected and what IS NOT affected encodes the root cause. Find the distinction, find the cause.
## When to Use
- A defect is **selective**: affects some endpoints/regions/users/times but NOT others — there is an IS-vs-IS-NOT boundary to contrast
- The cause is unclear and not obvious from a stack trace, error message, or a single recent change
- Multiple possible causes exist and you need a systematic way to narrow them
- A complex situation has multiple concerns that need triage before diving in
Decision flow:
```
Defect is selective (not 100%)? → No → IS/IS-NOT has no signal; use direct debugging or thinking-systems
→ Yes → Cause obvious from stack trace/recent change? → Yes → Just fix it
→ No → APPLY KT PROBLEM ANALYSIS
```
## When NOT to Use
- **The failure is uniform** (affects 100% of requests/everything) — there is no IS-vs-IS-NOT boundary to contrast; PA gives no signal. Use `thinking-systems` or direct debugging.
- **The cause is already obvious** from a stack trace, error message, or a single recent change — just fix it; IS/IS-NOT is overhead here.
- **A quick hypothesis is cheaply testable** — test it (`thinking-occams-razor`) before building a full specification matrix.
- **Pure decision-making with no deviation to diagnose** — use `thinking-opportunity-cost`, not KT's Decision Analysis.
- **Risk assessment for a planned change** — use `thinking-pre-mortem`, not KT's Potential Problem Analysis.
## Trigger Card
When a defect is selective (some cases affected, others not) and the cause is unclear:
1. **State the problem precisely** — what is the deviation? In what object? Where/when does it occur?
2. **Map IS vs IS-NOT** — what IS affected vs what IS NOT, side by side. The boundary is the signal.
3. **Find the distinction** — what is different about the IS cases vs the IS-NOT cases? That distinction IS the cause.
Skip if the failure is uniform (100%) — there's no boundary to contrast; use direct debugging. If the cause is obvious from a stack trace or recent change, just fix it. For a single cheaply-testable hypothesis, test it first.
2. **IS/IS-NOT Matrix** — all four dimensions with distinctions extracted
3. **Changes List** — what changed near the distinctions around the first observation
4. **Cause Test Table** — each candidate tested against IS and IS-NOT
5. **Confirmed Root Cause** — with verification evidence
6. **If used, SA Triage** — prioritized concern list with assigned processes
## Anti-Patterns
| Anti-Pattern | Symptom | Correction |
|---|---|---|
| **KT on uniform failure** | Running PA when 100% of requests fail | No boundary to contrast; use direct debugging or `thinking-systems` |
| **Over-specifying the matrix** | Filling every IS/IS-NOT cell for a simple bug | Stop when the distinction is clear; don't ritualize |
| **DA/PPA sprawl** | Running full Decision Analysis or Potential Problem Analysis for routine tasks | Redirect to `thinking-opportunity-cost` (decisions) or `thinking-pre-mortem` (risks) |
| **Skipping cause testing** | Pursuing the first plausible cause without testing against IS-NOT | Every cause must explain BOTH IS and IS-NOT |
| **SA as mandatory preamble** | Running full Situation Analysis before every PA | Jump directly to PA when the problem is already clear |
| **Ignoring the distinction** | Building the matrix but not extracting what's unique about IS | The distinction IS the signal; without it, the matrix is just a table |
