Skip to content
Beta Multi-model support (OpenAI, Gemini, and more) launching soon.
RBA RBA Skills

five-whys-root-cause

Installable Ships in discovery-synthesizer — or copy the raw skill below.
Open Claude.ai

Paste into Claude Code, Claude.ai, the desktop app, or the browser extension — ⌘/Ctrl+V.

ExperimentalNo security review

Five Whys Root-Cause Analysis

Trace a stated problem back to its actionable root cause using structured Five Whys chains. Produces a cause chain, a fishbone diagram (Ishikawa), and root-cause recommendations calibrated for digital-experience and content-operations contexts.

When this skill applies

  • User states a problem and wants to understand why it happens
  • Discovery interviews have surfaced a recurring pain point the team needs to understand before designing a solution
  • A platform is underperforming and the team wants to separate symptoms from causes
  • Post-launch retrospective: understanding why a launch issue occurred

Workflow

Step 1 — State the problem clearly

A good problem statement is:

  • Observable — something you can see or measure
  • Specific — not "the website is bad" but "content authors spend an average of 3 extra hours per week duplicating content across two systems"
  • Bounded — describes one failure mode, not a cluster

If the user's problem statement is vague, offer a more specific version and ask for confirmation before proceeding.

Step 2 — Run the Five Whys chain

Starting from the problem statement, ask "Why does this happen?" iteratively. For each answer:

  1. Ground the answer in evidence from the provided material where possible; flag assumptions where evidence is absent
  2. Test whether the answer is a cause or just another symptom — if it could still ask "why?", it is a symptom
  3. Stop when you reach a root cause — something that, if addressed, would prevent the symptom from recurring — or when you hit a system boundary (regulatory constraint, irreversible resource decision)

Run parallel chains when an answer at step N has multiple independent causes. Label parallel chains A, B, C.

Format:

Problem: [Statement]
  Why 1: [First cause]
    Why 2: [Cause of cause 1]
      Why 3: [Cause of cause 2]
        Why 4: [Cause of cause 3]
          Why 5: [Root cause]

Standard depth is 5. Extend to 7 if the chain has not reached an actionable root cause by Why 5. Stop at 3 if the root cause is clearly identified before Why 5 — do not pad to reach 5.

Step 3 — Validate each root cause

For each identified root cause, evaluate:

  • Evidence quality: Is this root cause supported by interview data, system logs, observation, or is it inferred?
  • Actionability: Can the project team address this root cause, or does it require a decision beyond the project's scope?
  • Independence: Is this root cause truly independent, or is it itself a symptom of a deeper cause in another chain?
  • Recurrence test: If this root cause were addressed, would the problem be permanently resolved or merely suppressed?

Flag root causes that fail the recurrence test with [SYMPTOMATIC — further analysis needed].

Step 4 — Build the fishbone diagram

Organize root causes and intermediate causes into a fishbone (Ishikawa) structure. For DXP and digital-experience engagements, use these standard bone categories:

  • People — skills gaps, ownership gaps, training deficits, org structure misalignment
  • Process — workflow breakdowns, approval bottlenecks, missing governance, manual workarounds
  • Platform — capability gaps, integration failures, performance issues, configuration debt
  • Data — poor data quality, missing data, inaccessible data, inconsistent data models
  • Governance — policy gaps, unclear decision rights, compliance obligations not operationalized
  • Environment — external factors: market, regulatory, vendor-imposed constraints

Each intermediate cause maps to one bone. Root causes sit at the bone tips. The problem statement is the fish head.

Render as an ASCII diagram or structured markdown table depending on output preference.

Step 5 — Produce root-cause recommendations

For each validated root cause, produce a recommendation entry:

Root cause Category Evidence quality Recommended intervention Scope (project / engagement / org) Priority
[Root cause statement] People / Process / Platform / Data / Governance / Environment High / Medium / Low [Specific action] [Scope] High / Medium / Low

Scope guidance:

  • Project — addressable within the current engagement without additional budget or decisions
  • Engagement — requires a change in the engagement scope or a new workstream; surface to the engagement lead
  • Org — a structural or policy change the client organization needs to make; outside RBA's direct control; flag as a recommendation, not a commitment

Step 6 — Self-check before returning

  • Every root cause is either evidence-grounded or explicitly flagged as inferred
  • Parallel chains are clearly labeled and separated
  • No cause has been skipped to reach a desired conclusion
  • Root causes at "Org" scope are framed as client recommendations, not RBA deliverables
  • The fishbone categories cover all identified causes; nothing is left in "miscellaneous"

Common DXP root-cause patterns

See reference.md for a library of pre-mapped Five Whys chains for recurring DXP pain points — use these as starting points, not pre-built answers.

Technical details
Plugin
discovery-synthesizer
Author
Dakota Smith
Skill name
five-whys-root-cause
Maturity
experimental
Security review
No security review
Owners
  • strategy
Argument hint
[problem statement] [--evidence transcripts or @file-path] [--depth 3|5|7] [--output chain|fishbone|report]
Allowed tools
  • Read
  • Write
Source
plugins/discovery-synthesizer/skills/five-whys-root-cause/SKILL.md

Edit this skill on GitHub — opens GitHub's web editor. No git knowledge needed.