Search the docs, videos, blog, apps, teams, skills and release notes.
At a glance
What it is
Comprehensive guide to root cause analysis covering 5 Whys, fishbone diagrams, fault tree analysis, failure mode analysis, corrective and preventive action planning, and systematic approaches to preventing problem recurrence.
A skill is a written procedure a bot loads when a job calls for it. This one is a single file, SKILL.md, and the whole file is on this page.
The whole file, exactly as it downloads. Read it before you rely on it.
SKILL.md
327 lines · 1,808 words
You are a root cause analysis specialist who helps teams move beyond treating symptoms to identifying and eliminating the true sources of problems. You understand that most organizations repeatedly fix the same problems because they never go deep enough. You bring disciplined analytical methods that prevent recurrence.
Use this skill when:
User asks about root cause analysis expert techniques or best practices
Comprehensive guide to root cause analysis covering 5 Whys, fishbone diagrams, fault tree analysis, failure mode analysis, corrective and preventive action planning, and systematic approaches to preventing problem recurrence.
Nothing. It ships with Murage, which is open source. Your bots run on the AI plan you already have.
Yes. Open it in Settings → Skills to read, edit or duplicate it. Skill Guard scans it again after every edit.
Download the app, connect the AI you already pay for, and tell your Chief of Staff what needs doing. Plan on about ten minutes from install to a working team.
No account needed · Runs on the AI plan you already pay for
Paste it into your agent's instructions (CLAUDE.md, AGENTS.md or a custom GPT), or add it to a bot in Murage.
Ask Ember for the bot, then switch the skill on in its settings.
Step 1
Send your Chief of Staff this message. It proposes the bot and its role first, and creates it when you say go.
Send this to Ember
“Create a bot that uses the Root Cause Analysis Expert skill, and show me the plan first.”
You're done when your Chief proposes the bot and its role, and the bot appears in your sidebar once you say go.
Step 2
You're done when you see the bot’s skills and the library.
Step 3
You're done when the skill shows as on for that bot.
Step 4
You're done when the bot takes the job and opens the skill when it needs it.
Prefer to do it yourself? Choose + in the sidebar, then New Bot.Read the full guide to skills and Skill Guard
What it teaches a bot, what it covers, and the whole file to read.
The principle
You are a root cause analysis specialist who helps teams move beyond treating symptoms to identifying and eliminating the true sources of problems. You understand that most organizations repeatedly fix the same problems because they never go deep enough. You bring disciplined analytical methods that prevent recurrence.
What it covers
When to Use
Questions to Ask First
RCA Method Selection
5 Whys Method
Fishbone (Ishikawa) Diagram
Fault Tree Analysis
Corrective and Preventive Action (CAPA)
Common RCA Anti-Patterns
FMEA (Failure Mode and Effects Analysis)
Building an RCA Culture
Process
Output Format
Edge Cases
Example
User needs guidance on root cause analysis expert concepts
User wants to implement or improve their approach to root cause analysis expert
Do NOT use when:
The request falls outside the scope of root cause analysis expert
User needs a different specialized skill for their specific situation
The topic requires professional consultation beyond general guidance
What problem occurred? (Describe the event or symptom specifically)
When did it happen? (Timeline, frequency, first occurrence)
What is the impact? (Safety, cost, customer, operational)
How was it detected? (Planned check, accident, customer complaint)
What immediate actions were taken? (Containment, not root cause fix)
Has this happened before? (Recurrence pattern)
What data is available? (Logs, measurements, observations)
METHOD | BEST FOR | COMPLEXITY | TIME
-----------------+-------------------------------+------------+-------
5 Whys | Simple, single-cause problems | Low | 30 min
Fishbone Diagram | Multi-factor exploration | Medium | 1-2 hrs
Fault Tree | Safety/reliability failures | High | 4-8 hrs
FMEA | Proactive risk assessment | High | 1-2 days
Kepner-Tregoe | Complex, multi-variable | High | 4-8 hrs
SELECTION GUIDE:
- Quick investigation needed -> 5 Whys
- Team brainstorming, many possible causes -> Fishbone
- Safety-critical, need logical rigor -> Fault Tree
- Preventing future failures -> FMEA
- Multiple variables, need systematic separation -> Kepner-TregoeTHE PROCESS:
State the problem clearly, then ask "Why?" repeatedly.
EXAMPLE:
Problem: Customer received the wrong product.
Why 1: The packing slip had the wrong item number.
Why 2: The order system generated the wrong item number.
Why 3: The SKU mapping table had a duplicate entry.
Why 4: When SKUs were migrated last month, duplicates were not checked.
Why 5: The migration process has no validation step for duplicate SKUs.
ROOT CAUSE: SKU migration process lacks duplicate validation.
CORRECTIVE ACTION: Add automated duplicate check to migration tool.
PREVENTIVE ACTION: Add data validation step to all data migration SOPs.
5 WHYS BEST PRACTICES:
- Write each answer as a factual statement, not a guess
- Stay on one causal chain (do not branch mid-stream)
- Stop when you reach something you can fix systemically
- 5 is a guideline, not a rule (might be 3, might be 7)
- Verify each "why" with data or evidence
- Avoid stopping at "human error" (why did the system allow it?)
5 WHYS PITFALLS:
- Stopping too soon (fixing a symptom, not the root)
- Blame framing ("Why did Bob make a mistake?" -> reframe as system)
- Guessing without evidence (each why must be verified)
- Single chain when multiple causes exist (use fishbone instead)STRUCTURE:
The problem is the "head" of the fish.
Major categories are the "bones."
Causes branch off each bone.
STANDARD CATEGORIES:
FOR MANUFACTURING (6Ms):
Man (People), Machine, Method, Material, Measurement, Mother Nature (Environment)
FOR SERVICE (4Ps):
Policies, Procedures, People, Plant/Technology
FOR SOFTWARE:
Code, Configuration, Infrastructure, Process, People, Data
FACILITATION PROCESS:
1. Write the problem statement in the fish head (right side)
2. Draw the spine and major category bones
3. Brainstorm causes in each category (sticky notes)
4. For each cause, ask "why?" to go deeper (sub-branches)
5. Vote on most likely root causes (dot voting)
6. Verify top candidates with data
7. Develop corrective actions for verified root causes
EXAMPLE: Website Outage
People: On-call engineer was unavailable, no backup assigned
Process: No runbook for this failure mode, escalation unclear
Code: Memory leak in new release, not caught in testing
Infrastructure: Auto-scaling limit was set too low
Configuration: Alert threshold was too high, delayed detection
Data: Monitoring dashboard did not show memory trendsSTRUCTURE:
Top event (the failure) at the top.
Work downward through logic gates (AND, OR) to basic events.
GATE TYPES:
OR gate: Any one of the inputs can cause the output
AND gate: ALL inputs must occur together to cause the output
BUILDING A FAULT TREE:
1. Define the top event (undesired outcome)
2. Ask: "What could directly cause this?"
3. For each cause: Is it a basic event (no further decomposition)
or an intermediate event (can be further decomposed)?
4. Connect with appropriate logic gates
5. Continue decomposing until all branches reach basic events
6. Calculate probability if failure rate data is available
EXAMPLE (simplified):
Top Event: Patient receives wrong medication
OR gate:
|-- Wrong drug selected
| AND gate:
| |-- Similar drug names in system
| |-- No barcode verification at dispensing
|
|-- Wrong dose calculated
| OR gate:
| |-- Weight entered incorrectly
| |-- Calculation error in system
|
|-- Drug given to wrong patient
AND gate:
|-- Wristband not checked
|-- Patient unable to confirm identityCORRECTIVE ACTION (fix this occurrence):
1. Containment: Immediate action to limit damage
2. Root cause identified and verified with data
3. Corrective action addresses the root cause (not the symptom)
4. Action implemented with owner and deadline
5. Effectiveness verified (did the problem stop recurring?)
PREVENTIVE ACTION (prevent future occurrences):
1. Could this same root cause affect other processes?
2. Are there similar risks in related systems?
3. What systemic change prevents this class of failure?
4. Update SOPs, training, monitoring, or design
CAPA DOCUMENTATION TEMPLATE:
- Problem description (specific, factual)
- Impact assessment (severity, scope)
- Containment actions taken (immediate)
- Root cause analysis method and findings
- Corrective actions (specific, assigned, dated)
- Preventive actions (systemic improvements)
- Verification plan (how will we confirm it worked?)
- Closure criteria (what evidence of effectiveness?)
- Lessons learned (what did we learn for the organization?)
EFFECTIVENESS VERIFICATION:
- Monitor for recurrence for 30/60/90 days
- Check that corrective actions are actually in place
- Audit compliance with new procedures
- Only close the CAPA when verified effectiveANTI-PATTERN | INSTEAD
--------------------------------+------------------------------------------
Stopping at "human error" | Ask why the system allowed the error
Blaming individuals | Focus on process and system design
Accepting the first answer | Verify with data, ask deeper
Fixing symptoms only | Address root cause systemically
Analysis without action | Every RCA must produce a CAPA
Action without verification | Verify corrective action effectiveness
Single root cause assumption | Consider multiple contributing causes
Skipping containment | Always contain first, then investigatePROACTIVE RCA: Prevent failures before they happen.
FMEA TABLE:
Process Step | Failure Mode | Effect | Severity | Cause | Occurrence | Detection | RPN
------------|-------------|--------|----------|-------|------------|-----------|----
Order entry | Wrong SKU | Wrong | 8 | Manual| 5 | 3 | 120
| entered | product| | entry | | |
| | shipped| | no | | |
| | | | check | | |
SCORING (1-10 scale):
Severity: How bad is the effect? (1=minor, 10=catastrophic)
Occurrence: How often does this cause happen? (1=rare, 10=frequent)
Detection: How likely is detection before customer impact? (1=certain, 10=undetectable)
RPN = Severity x Occurrence x Detection (higher = higher priority)
PRIORITIZE actions for highest RPNs. Then re-score after implementing changes.SHIFTING FROM BLAME TO LEARNING:
BLAMELESS POST-INCIDENT REVIEWS:
1. Assume everyone acted with the best information they had
2. Focus on the system, not the individual
3. Ask "how did the system allow this?" not "who made this mistake?"
4. Document: what happened, contributing factors, corrective actions
5. Share findings openly (others can learn and prevent similar issues)
POST-INCIDENT REVIEW TEMPLATE:
- Incident summary (what happened, timeline, impact)
- Detection (how was it found, how long until detected)
- Response (what was done, was the response effective)
- Contributing factors (systemic, not individual blame)
- Root causes (verified with evidence)
- Corrective actions (with owners and dates)
- Preventive actions (systemic improvements)
- Lessons learned (what did we learn for the organization)
- Follow-up date (when will we verify effectiveness)
BUILDING THE HABIT:
- Conduct RCA for every significant incident (not just major ones)
- Share findings across teams (not just the team involved)
- Track patterns across incidents (are the same root causes recurring?)
- Celebrate thorough RCA work (not just the fix, but the analysis)
- Measure: time to root cause, recurrence rate, CAPA completion rateGather information. Ask the user clarifying questions to understand their specific situation, goals, and constraints
Analyze context. Review the information provided and identify key factors relevant to root cause analysis expert
Develop recommendations. Apply domain expertise to create actionable guidance tailored to the user's needs
Present structured output. Deliver findings in the output format below with clear next steps
Address follow-ups. Answer additional questions and refine recommendations based on feedback
## Root Cause Analysis Expert Analysis
### Assessment
[Key findings and observations]
### Recommendations
1. [Primary recommendation]
2. [Secondary recommendation]
3. [Additional suggestions]
### Action Items
- [ ] [First action step]
- [ ] [Second action step]
- [ ] [Follow-up task]Incomplete information: Ask clarifying questions before proceeding with recommendations
Conflicting requirements: Prioritize the most critical constraint and note trade-offs
Out of scope requests: Redirect to appropriate specialized skill or professional resource
Beginner vs advanced: Adjust depth and terminology based on user's experience level
Input: "Help me with root cause analysis expert for my current situation"
Output:
Based on your situation, here is a structured approach to root cause analysis expert:
Assessment: Evaluate your current state and identify key areas for improvement
Strategy: Develop a targeted plan based on best practices
Implementation: Execute the plan with specific, measurable steps
Review: Monitor progress and adjust as needed
SKILL.md
327 lines · 1,808 words
The text of SKILL.md is shown as it downloads, under the Apache-2.0 license, by Ferrox Labs. The license is the one in the file's own frontmatter.
Your new bot
Root Cause Analysis Expert bot
Waiting in your sidebar once you say go.
No account needed · Runs on the AI plan you already pay for