Applicable: handling after any "receiving problem/exception/experience feedback"——don't fix directly, first deep-dive then seek truth then land it. Generalization: methodology decoupled from tools——research channels, evidence forms, and project context are all runtime-adaptable parameters.
Trigger Timing
When the user gives feedback of the following typesimmediately enter this process(don't directly start changing):
- "experience complete/experience terminated" + feedback
- "there's a problem/error/stuck/failure/exception/not quite right"
- "first look at the logs/records/session" "analyze it" "what's going on" "what's the root cause"
- "I say/I found X has a problem"
Core Principles (Seven)
- Evidence > impression——first look at logs/records/trace to reconstruct the scene, don't guess from impression
- Root cause > symptom——phenomenon→root cause→root cause of the root cause (why×N), hypotheses must be falsified and verified by actual testing
- General > special-case——no fallback/whitelist exhaustive enumeration——find general mechanisms (fix the environment not the command, fix the configuration not the singleton)
- Research > intuition——personal understanding is only a hypothesis——multi-source cross-verification (≥2 independent channels + official docs + source code + actual testing) → find the most suitable solution
- Context > abstraction——test the solution under the current project/environment context (multi-project parallel/host isolation/environment unification)
- Small steps > big changes——decision checklist → start from the simple ones one by one (don't pile up a bunch at once)
- Closed loop > divergence——after changing, take stock of "what remains unsolved"——continuous closed loop
Five Stages, 11 Steps
Stage ① Scene Reconstruction (evidence first)
- Look at evidence first——first read logs/records to reconstruct the scene, don't guess from impression. Evidence forms are taken according to observability maturity:
structured logs (
tail <log> | jqtype) → correlated trace/span chain (event order and causality) → metrics (anomaly detection/baseline comparison) → reproduction path. When there is a trace chain,read along the chain, don't just grep a single-point log - Read all in order——read the session/records completely in chronological order, don't stare at just one point——find all problems
- Deep-dive instances——go to early conversations/continuous operations/specific stuck points to find evidence (continuous calls to find repetition, authorization records to find duplicate authorization)
Stage ② Root Cause Deep-Dive (don't stop at the surface)
- Root cause questioning——phenomenon→root cause→root cause of the root cause ("tool unavailable"→"why"→"what is returned"→ locate by actual testing)——ask "why" at every layer. While questioning, also askdirect trigger and latent conditions(Environment/process/tool layer — "fix the environment, not the command" is latent conditional thinking). Optional RCA tool mapping (use according to complexity): 5 Whys (simple linear) → Fishbone/Ishikawa (multiple candidate factors) → Fault Tree Analysis FTA (combinations of conditions) → Kepner-Tregoe IS/IS NOT (delineate the phenomenon boundary: what it is/what it is not, when/when not)
- Empirical falsification— don't guess: turn root-cause hypotheses intofalsifiable expectations, and run experiments to verify.Prefer designing experiments that can refute the hypothesis(Popper); bisection/minimization verification (delta debugging idea: narrow down to the minimal failing input) rather than exhaustive enumeration. For every adopted root cause, find at least one piece ofevidence that does not support it(counterexample search) — to prevent confirmation bias
4 ↔ 5 is an iterative loop, not a single linear pass: questioning produces a list of root-cause hypotheses → falsify each one empirically → if it does not converge, return to 4 and continue questioning (a hypothesis being refuted = progress, not failure).
Insufficient-evidence branch: when there are no logs/cannot reproduce — explicitly mark
unverified, ask the user for the reproduction path/environment information, narrow the input and retry; if you cannot get evidence, do not give a root-cause conclusion ("cannot reproduce" is itself a valid conclusion; continuing to analyze = fabrication).
Phase ③ Solution truth-seeking (do not settle)
- Reject special-casing— do not use fallbacks/special cases/exhaustive whitelists ("it is X now, what about other cases? Can you enumerate them all?") — findgeneral mechanisms; use bisection/spectrum localization to narrow the suspect surface (the opposite of exhaustive enumeration)
- Due-diligence research— multi-source cross-validation: independent search channels (≥2 mutually independent sources) + source code of similar implementations + official documentation + empirical testing — only settle on a solution when ≥2 independent sources agree
- Project-context check— check the solution in the current project/environment context: multiple projects in parallel/host isolation/unified environment/single source from start to finish — an abstract solution must pass the reality check
- Completeness review— after confirmation, still ask: record it? reuse it? unified from start to finish? (solving means precipitating — KCS perspective: is this solution reusable knowledge or yet another special case?)
Phase ④ Execution rhythm
- Decision list + small steps— "list pending decisions": for each problem, a table of phenomenon/root cause/candidate solutions → user chooses → start with the simple ones, one at a time(especially wait for confirmation when told "don't rush to change" or "analyze first")
Phase ⑤ Closure
- Continuous inventory— "what is still unresolved" — list by severity, user chooses the next step — nothing omitted, continuous closure
Cognitive bias defense (throughout ②③)
| Bias | Defense |
|---|---|
| Confirmation bias (only accepting data that supports the prior) | For each root-cause hypothesis, listfalsifiable expectations + at least one piece of non-confirmatory evidence; actively look for counterexamples |
| Anchoring (first impression locks in) | In Phase ①, read the complete sequence before drawing conclusions; IS/IS NOT boundary delineation prevents premature anchoring |
| Availability (the most recent/most salient is treated as the root cause) | Candidate causes are ranked by strength of evidence, not by "just seen" |
Output format (per stage)
- ①-③：Analysis report(phenomenon/evidence/root cause/solution comparison + counterexample list) — do not fix, wait for user confirmation
- ④: Decision list (number + phenomenon/root cause/candidate solutions + recommended priority)
- ⑤: Unresolved issues inventory table (resolved ✓ / unresolved by severity)
Key follow-up questions (trigger hints — when the user pushes for deeper investigation, map to the corresponding stage; the process itself is self-sufficient and can run on its own)
| User's words | Meaning |
|---|---|
| "Look at the logs/records first" | Stage ① — evidence first |
| "Read in order first" | Stage ① step 2 — read completely, find all issues |
| "Focus on consecutive tool calls" | Stage ① step 3 — dig into specific instances |
| "What is the root cause" | Stage ② — keep asking why |
| "Don't use fallbacks, can you exhaustively enumerate them" | Stage ③ step 6 — reject special-casing, find the general solution |
| "I want you to do due diligence research" | Stage ③ step 7 — multi-source cross-validation |
| "What about putting it under the current project" | Stage ③ step 8 — context check |
| "Does it need to be recorded" | Stage ③ step 9 — completeness review |
| "List the pending decisions" | Stage ④ — decision list |
| "Take them one at a time" | Stage ④ — advance in small steps |
| "What is still unresolved" | Stage ⑤ — continuous inventory |
Anti-patterns
- Start fixing immediately upon receiving feedback (skipping the process)
- Only look at the local part of the problem without reading the records completely (missing issues)
- Stop at surface symptoms (not tracing the root cause; only finding direct triggers without finding latent conditions)
- Use special-casing/whitelisting (cannot be exhaustively enumerated)
- Treat single-source research as a conclusion (no independent two-source cross-validation)
- Hypothesis only seeks supporting evidence (confirmation bias — no counterexample search)
- Solutions do not check the project context (missing multi-project/host/unification)
- Change a bunch at once ("don't rush to change")
- Do not review after changes (missing remaining issues)
Relationship with adjacent skills
| Skill | Boundary |
|---|---|
problem-dive(this skill) |
After receiving problem/experience feedback,deep-dive methodology— evidence first, root cause, research, decision list,do not fix directly |
systematic-debugging |
Once identified ascode defectroot cause investigation protocol (reproduce → hypothesize → verify) |
problem-resolution-flow |
From symptom tofix and releaseend-to-end pipeline (locate → classify → research → fix → verify → wrap up) — this skill hands off after producing a solution |
Order: when feedback comes in, run this skill first; within the code path call systematic-debugging; after the solution is confirmed, run problem-resolution-flow to implement and wrap up.
Methodology sources (2026-08 research)
- RCA tool lineage: Toyota 5 Whys, Ishikawa fishbone diagram, FTA, Kepner-Tregoe IS/IS NOT (kepner-tregoe.com)
- Incident investigation/safety engineering: James Reason Swiss Cheese (active/latent failure); HFACS human factors hierarchy
- Observability engineering: OpenTelemetry (unified logs/metrics/traces and span correlation); Honeycomb high-cardinality debugging perspective
- Evidence-driven debugging: Zeller delta debugging (binary search for the minimal failing input—TSE 2002); Why Programs Fail (hypothesis → prediction → experiment)
- Cognitive biases: empirical evidence on confirmation bias/anchoring/availability in software engineering (arXiv 2508.11278); traceability mitigates bias (ACM CACM)
- Scientific method: Popper's falsificationism (design experiments that can refute hypotheses)
- Knowledge capture: KCS (Knowledge-Centered Service) Solve/Evolve loop—solving is capturing, feeding back into reuse