5WHY root cause analysis guide

intent

this skill guides users through structured root cause analysis using the 5WHY method. it takes an initial problem statement, drives iterative questioning with explicit validation gates, and terminates only when a root cause is identified (i.e., a countermeasure that prevents recurrence). use this for equipment failures, production anomalies, quality defects, or any scenario where you need to trace from symptom to origin rather than surface fix.

inputs

• user problem statement: the initial anomaly or failure reported (plain text, no special format required). examples: "device shuts down with alarm after startup", "product surface has scratches", "production output dropped 20% this shift"
• no external dependencies: this skill requires no API keys, database connections, or third-party services. it operates purely on conversation state and logical rules.
• context assumed: user is present and responsive for multi-turn dialogue. if user becomes unresponsive, the analysis pauses at that turn.

procedure

phase 1: intake

step 1: receive initial problem

• user states the anomaly or failure.
• you do not elaborate on or restate the problem; instead, move directly to step 2.

step 2: launch round one inquiry

• output: 【round 1 inquiry】why did [core problem from user] occur?
• optionally add 1-2 concrete thinking directions (e.g., "consider device-side failures like sensor malfunction vs. operational process deviation vs. material parameter drift"). do not hand over answers; guide thought only.

phase 2: core dialogue loop

step 3: receive user answer

• user responds to the prior inquiry.

step 4: validate answer (three-layer check, execute in order)

validation layer 1: simplicity check

• user answer must contain a single causal element.
• reject if answer bundles multiple causes (e.g., "operator error AND equipment not inspected"). if fail, output: 【answer validation alert】multiple elements detected (operator error + equipment state), please separate and address one factor at a time.
• move to layer 2 only if user provides single-element answer.

validation layer 2: eliminate invalid answer types

• subjective judgment without evidence: "employee lacked responsibility", "team not careful", "poor management". reject because not actionable and not measurable.
• uncontrollable factors: "weather conditions changed", "raw material batch variation is inevitable", "customer rushed the order". reject because countermeasures cannot prevent.
• normal field state: "equipment normal aging", "routine staff rotation", "standard production cycle". reject because not a deviation or anomaly trigger.
• if answer matches any type above, output: 【answer validation alert】[type name] answer detected, invalid. please restate with objective, controllable, anomaly-specific factor.
• move to layer 3 only if answer avoids all three invalid types.

validation layer 3: ambiguity check

• if you cannot definitively classify the answer against layers 1-2, ask user for clarification before judging. example: 【ambiguity check】you mentioned "pressure imbalance", do you mean the relief valve failed to open on schedule, or that the system over-pressurized unexpectedly? please clarify.
• only after clarification, re-run layers 1-2.

validation pass format (shown to user):

validation result:
- simplicity check: passed (single element)
- invalid answer screening: passed (objective, controllable, anomaly-specific)

current answer: [user statement]

step 5: root cause judgment (three principles)

principle 1: propose countermeasure

• based on user answer, state exactly one concrete, implementable countermeasure. example: "install oil filtration on the lubrication loop, disassemble and clean relief valve spool monthly, verify spool freedom weekly."
• countermeasure must be specific and doable, not vague ("improve maintenance").

principle 2: core judgment

• ask yourself: if we execute this countermeasure flawlessly, will the same anomaly type never recur?

principle 3: judgment decision

• if yes: judgment = root cause found. proceed to step 6 (close analysis).
• if no: judgment = intermediate cause. proceed to step 5b (next inquiry).

step 5b: intermediate cause (continue loop)

judgment output format:

validation result:
- simplicity check: passed (single element)
- invalid answer screening: passed (objective, controllable, anomaly-specific)

current answer: [user statement]
proposed countermeasure: [specific action]
root cause judgment: [ ] yes [ ] no
judgment reason: this countermeasure [does/does not] prevent recurrence because [explain why measure is insufficient or complete].

【next round inquiry】why did [user's prior answer] occur?
[optional 1-2 thinking directions to guide next response]

inquiry logic:

• each new inquiry takes the prior answer as its starting point. layer upward; do not jump sideways or reverse back to initial problem.
• use sentence form: "why did [prior user answer] occur?"
• ask one question only. keep language direct and clear.
• if you sense user may struggle to articulate the next layer, add 1-2 thinking directions.

phase 3: termination

step 6: root cause confirmed

judgment output format:

validation result:
- simplicity check: passed (single element)
- invalid answer screening: passed (objective, controllable, anomaly-specific)

current answer: [user statement]
proposed countermeasure: [specific action]
root cause judgment: [x] yes [ ] no
judgment reason: this countermeasure prevents recurrence because [explain why measure is sufficient and complete].

【final conclusion】the root cause of [initial problem] is: [user answer]. landing measure: [proposed countermeasure].

step 7: record complete dialogue trace

• output a chronological summary:

  【complete dialogue trace】
  
  initial problem: [user statement from step 1]
  
  round 1 inquiry: why did [initial problem] occur?
  user answer: [response]
  validation: passed
  countermeasure: [action]
  judgment: [yes/no] ,  reason
  
  round 2 inquiry: why did [round 1 answer] occur?
  user answer: [response]
  validation: passed
  countermeasure: [action]
  judgment: [yes/no] ,  reason
  
  [... continue for all rounds ...]
  
  final root cause: [user answer from step 6]
  final landing measure: [proposed countermeasure from step 6]
  

• this trace becomes the record user retains and references later.

decision points

if validation layer 1 (simplicity) fails

• output validation alert, request user split the multi-element answer into single factors.
• do not proceed to layer 2 or 3 until answer is reshaped to single element.
• re-run step 4 with revised answer.

if validation layer 2 (invalid type) fails

• output validation alert with type name.
• do not proceed to step 5 (root cause judgment).
• loop back to step 3: ask user to restate the answer.

if validation layer 3 (ambiguity) triggers

• ask clarifying question before running layers 1-2 again.
• do not guess or assume user intent.

if user cannot propose a countermeasure or is uncertain

• you propose one based on the answer given.
• if user disputes the countermeasure's likelihood to prevent recurrence, accept their input and revise judgment.
• if both you and user remain uncertain, ask user directly: "do you believe this countermeasure would prevent the same anomaly from happening again?" their confidence informs the judgment.

if analysis extends beyond 5 rounds without reaching root cause

• this is normal and acceptable. do not force artificial closure.
• continue applying steps 3-5b until a countermeasure is identified that user and you both agree will prevent recurrence.
• number of rounds is flexible; only "root cause found" triggers termination.

if user gives answer that reveals prior countermeasure was insufficient

• acknowledge this. do not backtrack the entire analysis.
• example: user said "relief valve was sticking" in round 2, you proposed "check valve weekly"; user now says round 3 answer is "oil contamination prevented valve from moving", this tells you the round 2 countermeasure was too shallow.
• adjust judgment from "yes" to "no" for round 2, and continue forward. this is expected and correct.

output contract

on validation pass (step 4):

• structured text block showing: simplicity check result, invalid answer type result, single-line statement of current answer.

on root cause judgment (step 5 or 5b):

• structured text block showing: validation result, current answer, proposed countermeasure, binary yes/no judgment, judgment reason (one sentence explaining sufficiency or insufficiency), and either final conclusion or next inquiry.

on analysis complete (step 7):

• chronological dialogue trace in plain text format, listing all rounds, answers, validations, countermeasures, and final root cause.
• trace is plain text suitable for copying into a document, email, or wiki for retention.

format discipline:

• all output blocks use the exact structures shown above. do not add or remove sections, do not reorder.
• validation results, judgment results, and final conclusion always appear in the specified format.
• no additional commentary or theory outside these blocks during the analysis.

outcome signal

user knows the skill worked when:

1. a root cause is explicitly stated in the final conclusion block (step 6 output).
2. the proposed countermeasure is concrete and specific, not vague (e.g., "install oil filtration and disassemble spool monthly" vs. "improve maintenance").
3. the judgment reason explains why the countermeasure prevents recurrence, not just why it fixes the current symptom.
4. a dialogue trace is provided that user can review, share, and store as a record of the analysis session.
5. no further "why" question appears after the final conclusion, the analysis is closed.

if the skill stops mid-dialogue without a final conclusion, analysis is incomplete. if final conclusion lists a vague countermeasure (e.g., "do better") or does not explain prevention, the skill misfired.