Purpose
Take a raw problem statement from a nonconformance, deviation, or field failure and drive it through a rigorous root cause analysis — separating symptoms from causes, categorizing findings, and distinguishing occurrence root causes from detection escapes — so the resulting CAPA addresses why the defect happened and why it wasn't caught, not just what broke.
When to Use
Invoke this skill when the user asks to:
- Investigate a nonconformance (NCR), deviation, or CAPA
- Run a 5-Why, fishbone (Ishikawa), or fault tree analysis
- Find the root cause of a customer complaint or field return
- Analyze a repeat failure or recurring defect
- Prepare a root cause section for an audit finding response (ISO 9001, IATF 16949, AS9100, ISO 13485)
- Determine why a defect escaped inspection or test
Inputs Required
Before starting, collect:
- Problem statement: What happened, when, where, and how it was detected — factual, no assumed cause
- Product/process affected: Part number, process step, line, or work center
- Detection point: Where and how the problem was found (incoming, in-process, final test, customer)
- Quantity/scope: How many units affected, single event vs. recurring
- Preferred method: 5-Why, Fishbone, or Fault Tree (default: 5-Why for single-event; Fishbone for multi-factor; Fault Tree for safety/high-severity)
- Known evidence: Any data, measurements, timeline, or physical findings already gathered
- Regulatory context: Applicable quality standard, if the output must map to a specific CAPA format
If method is not specified, select based on problem type and state the choice with a one-line rationale.
Instructions
Step 1: Sharpen the Problem Statement
Restate the problem as a specific, measurable, single-issue statement before any analysis.
- Convert vague inputs into "What / Where / When / Extent / How detected" form
- Strip embedded assumptions ("operator error," "bad supplier") — those are hypotheses, not facts
- Flag if the statement is actually multiple problems bundled together; split them
- Note the gap between "what should happen" and "what did happen"
Step 2: Run the Selected Method
Method A — 5-Why Analysis (single, linear causal chain)
- Ask "why" iteratively from the problem statement, each answer becoming the next question
- Continue until reaching a cause that is systemic and actionable (typically 4–6 levels, not fixed at 5)
- Run two parallel chains: one for occurrence (why the defect was produced) and one for detection (why it escaped)
- Mark each level as verified (supported by evidence) or hypothesis (needs confirmation)
- Stop when the answer becomes "human error" or "bad luck" — that means you stopped one why too early; push to the process/system reason behind it
Method B — Fishbone / Ishikawa (multi-factor branching) Generate candidate causes across the 6M categories:
- Man (People): training, competency, workload, shift, instructions followed
- Machine (Equipment): calibration, maintenance, wear, tooling, fixturing
- Method (Process): procedure clarity, sequence, parameters, setup
- Material: incoming quality, lot variation, substitution, handling, storage
- Measurement: gage capability, inspection method, sampling plan, MSA
- Mother Nature (Environment): temperature, humidity, contamination, ESD, lighting For each branch, list plausible causes, then rank each as Probable / Possible / Ruled Out with the evidence basis.
Method C — Fault Tree Analysis (top-down, for high-severity/safety)
- Define the top undesired event
- Decompose into contributing events using AND / OR gates
- Identify basic events (root causes) at the bottom of each branch
- Note which combinations of events must occur together (AND) vs. any single event sufficing (OR)
- Highlight single points of failure — basic events under an OR gate near the top
Step 3: Classify Root Causes
Sort confirmed causes into:
- Occurrence root cause(s): Why the defect was created
- Detection/escape root cause(s): Why existing controls did not catch it
- Contributing factors: Conditions that increased likelihood or severity but are not the primary cause
- Systemic root cause: The management-system gap (procedure, training system, control plan, FMEA gap) behind the immediate cause
Step 4: Verification Prompts
For each root cause labeled "hypothesis," specify the evidence or test that would confirm or reject it (e.g., retrieve calibration record, review training log, replicate condition, pull SPC data). A cause is not a root cause until it can be turned off and on to make the problem disappear and reappear — note this test where feasible.
Step 5: Root Cause Statement
Write a single, defensible root cause statement (occurrence and detection) suitable for the CAPA record — traceable back to the evidence and precise enough to drive corrective action.
Output Format
- Structure: Sharpened problem statement → selected method with rationale → full method worklog (chain, fishbone branches, or fault tree) → classified causes → verification prompts → final root cause statement
- Length: 700–1,100 words
- Format: Structured document; method worklog as indented chains or category bullets; classification as a labeled list; fishbone/fault tree rendered as nested text hierarchy
- Sections: Problem Statement (Refined) → Method & Rationale → Analysis Worklog → Root Cause Classification → Verification Actions → Root Cause Statement
- Tone: Quality engineering — factual, evidence-first, no speculation presented as conclusion
Quality Checklist
Before delivering output, verify:
- [ ] The problem statement is specific and free of embedded cause assumptions
- [ ] Both occurrence and detection causes are analyzed — not occurrence only
- [ ] No chain terminates at "operator error" or "human error" without a system-level cause behind it
- [ ] Every root cause is labeled verified or hypothesis, with hypotheses paired to a verification action
- [ ] Contributing factors are separated from true root causes
- [ ] The final root cause statement is traceable to evidence in the worklog
Notes
- Fishbone generates breadth; 5-Why drives depth — for complex problems, use fishbone to surface candidate branches, then 5-Why the top-ranked branch
- The most common CAPA failure is stopping at the occurrence cause and ignoring detection escape — a robust CAPA fixes both the "make" and the "catch"
- If evidence contradicts a leading hypothesis, say so explicitly rather than forcing the chain to a predetermined conclusion
- Reserve Fault Tree Analysis for safety-critical or high-severity events where combinations of failures matter; it is heavier than most routine NCRs require
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills