The AI 5 Whys Analyst skill for Claude

The method is generally attributed to Sakichi Toyoda, the founder of Toyota Industries. Taiichi Ohno made it well known as a fixed part of the Toyota Production System and described it in his 1978 book about that system. The reasoning behind it is simple: every visible problem is the result of something that lies deeper, and you only reach that deeper cause once you have worked down through a few layers. Five is not a magic number here. It is a rule of thumb that says you are probably not there yet at the first plausible explanation.

The AI 5 Whys Analyst translates that method into a fixed way of working for Claude. A skill is an instruction file, SKILL.md, that gives an AI assistant a fixed approach for a task. Not software you install, no subscription, no connection to your systems: a text file of 2,189 words that tells Claude how a root cause analysis should be structured, what to ask first, how to mark certainty per layer, and what it must never invent itself. You download the zip at the top of this page, put it in your Claude environment, and from that moment every root cause question runs through this logic.

What makes the skill different from simply asking why five times yourself comes down to three things. First, it forces you to make the problem measurable before anything else. Before a single why gets asked, it rewrites your complaint into a factual sentence with place, time and scale. Second, it labels every layer by evidence, so at the end you can see which part of your analysis rests on data and which part on a story that happens to check out. Third, it separates the plaster from the intervention: the quick fix that stops the symptom this week stands apart from the structural measure that removes the cause, each with its own owner and deadline.

The file belongs to the TheSEO skill library NL, where 100 skills are free to download, and it comes out of the AI and automation service. New to files like this? Start with what Claude skills are NL: it explains in plain terms what a skill is and is not.

The chain points at people. This is the best known trap, and Eric Ries gave it a name in The Lean Startup from 2011: Five Blames. Every layer ends up with someone who forgot something, failed to pass something on, or was not paying attention. It feels satisfying, because there is a culprit. But you can repair a system and you cannot repair a human being, so an analysis like that always ends in a conversation and never in a measure. The skill flatly refuses to name a person as the root cause, and it deliberately writes causes in the passive voice to remove the question of blame. Not Jan forgot the check, but the check was skipped because there was no required field.

The chain rephrases instead of explaining. Layer three says the same thing as layer two in different words. Quotes take a long time because the turnaround time is high: that looks like a step deeper, but you are still standing in the same spot. In the skill's review mode this is the first checkpoint, and the file explicitly calls rephrasing the most common mistake.

The chain stops in the technical layer. The SKILL.md distinguishes three kinds of layers you usually encounter: the technical layer, where something went wrong in an action, a setting or a piece of code; the process layer, where the process allowed that mistake or even invited it; and the system layer, where nobody owned it, the incentives were wrong, or an earlier decision unintentionally caused this. A good analysis rarely ends in the technical layer. That is where the quick fix sits, not the structural solution.

Or the chain acts as if everything is certain. Five answers listed one after another read like five facts, even if three of them were guesses. That is why every layer in the output gets a certainty line, with one of three values: confirmed by data, plausible but unproven, or pure hypothesis. In FIG.01 two layers sit at hypothesis, and those two return at the end in a separate block of what you still need to find out. That block is the most honest section of the entire output.

In diff form, with a chain that reasons itself towards a person set against the same chain carried through to the system:

Next comes a chapter on the theory: Toyoda and Ohno, the three layers of technical, process and system, and four variants the skill may use when the context calls for it. The branching chain for when a layer has more than one valid cause. The combination with the Ishikawa diagram for when nobody yet knows where the problem sits. Five whys plus how, where after the root cause you run the chain back upward asking how you guard against each layer. And the lean startup variant from Eric Ries, where per layer you make an investment proportional to how serious the problem is.

At its core is a list of seven things the skill always does. It rewrites the problem into a factual, measurable sentence with place, time and scale before any why gets asked. It asks the five questions one at a time and answers them based on what you have supplied, not on assumption. It marks per layer how certain the answer is. It visibly splits the chain into branches as soon as a layer has more than one valid cause, and follows the branch with the greatest impact through.

It names the root cause in one sentence, phrased as a system or process. It delivers the quick fix and the structural measure separately, each with an owner and a deadline. And it closes with a verification step.

Before anything gets analysed, the skill runs through a mandatory input checklist of six points: the problem in your own words, when it occurs and how often, who or what suffers from it, what has already been tried and why that did not help, which facts or figures are available, and what you can and cannot change about budget, mandate and influence on other departments. It only asks about what is missing and then stops asking. If you do not know something, it carries on and marks that layer as unproven. So you do not get a form, at most two or three targeted questions.

A striking number of rules are about language. Plain Dutch (the file itself is written in Dutch), addressing the reader directly, no dashes in running text, AI written in capitals, no lists of exactly three items, concrete over abstract, a figure over an adjective, and short sentences alternating with long ones. There is even a list of words and turns of phrase that are banned because they smell of AI. And there is a writing rule that is substantive rather than cosmetic: write causes passively where that removes the question of blame. If you want to understand how rules like that end up in a skill file, writing a SKILL.md NL explains the structure step by step.

The output is fixed into seven blocks in a set order: problem statement, the chain of whys, root cause, quick fix, structural measure, verification, and what you still need to find out. The file also contains a separate review mode for existing analyses, a list of seven things the skill never does, and a source list of five titles. The last two get their own section further down this page.

The method itself comes from Toyoda and Ohno. Taiichi Ohno described the Toyota Production System in 1978, with the English edition in 1988, and credits the five why questions in it to Sakichi Toyoda. What often gets skipped is the context: at Toyota, asking why was not a meeting technique but a habit on the shop floor, close to the machine, with the people doing the work. That explains why the skill hammers so hard on facts and on what you can observe yourself.

The antechamber comes from Kaoru Ishikawa. His Guide to Quality Control from 1968 contains the cause and effect diagram that in practice is almost always used together with the 5 whys method. The division of roles is clear: the fishbone diagram widens, the chain of whys deepens. If you want to widen first and only then choose, the MECE Problem Structure Coach skill is another option, which splits a problem into boxes that do not overlap and together cover everything.

The trap comes from Eric Ries. The Lean Startup from 2011 describes the 5 whys method in product development and introduces the term Five Blames for the chain that points every layer at a person. Ries also attached an investment rule to it: the effort you put into a measure should be proportional to how serious the problem is, so you do not start a six month project after a minor incident.

The coaching side comes from Mike Rother. Toyota Kata from 2009 is about the way improving and coaching are structured within Toyota. That matters because a root cause analysis is rarely a one off action: run the same questioning routine every week and asking why becomes a habit rather than an occasional exercise.

The warning comes from Sidney Dekker. The Field Guide to Understanding Human Error from 2006 explains why root cause analyses that end at a person are useless. Human error is not an explanation but the point where you need to start looking. This source is the reason the ban on blame in the skill is not a courtesy rule but an analytical tool: as long as the chain ends at a name, you have not yet answered the question.

Even without installing the skill you can improve your own analyses with these principles: make the problem measurable first, label per layer how certain you are, and force yourself to phrase the final layer as a process rather than as a person.

After that, using it is simple: describe the problem as you experience it, with whatever figures or logs you have. The rawer, the better, as long as there is real information in it. It asks itself what is still missing and carries on with what is there. If installing gets stuck anywhere, the full explanation per environment sits in installing Claude skills NL, including the common mistakes with folders and permissions. And if you want to learn more broadly about working with AI, you will find the background articles in the knowledge base.

Two adjustments the file itself names, which many people miss. You may stop earlier than five layers if you are already at a cause you have influence over, provided you say that you are stopping and why. And you may go further than five layers if the fifth layer is still a symptom. For incidents with a safety or financial impact, the skill also adds an extra layer that is not about the cause but about detection: why was this not noticed sooner. That question often produces a second measure separate from the first.

There are also situations where you are better off leaving it be, and the skill says so itself in its frontmatter. Not during an ongoing incident: put out the fire first and analyse afterwards, because analysing during a fault costs attention you need to stop it. In brainstorm sessions where you actually want to widen your options it works against you, because this method narrows down rather than fanning out. It does not write text either. And not for several problems at once.

One more honest limit that is not in the file but counts in practice: the skill makes your analysis better, not your organisation. If the root cause is a decision someone above you made and will not reverse, you end up with a sharp analysis and still the same problem. What the skill does do then is put that sharply on paper, with a verification step underneath, so the conversation is about facts rather than impressions. Want to go from a cause to a priority? The Pareto Analyst skill is the logical next step: it works out which causes explain the largest share of the problem.

If the problem you are looking into sits at the front end, in too few enquiries rather than in the turnaround time afterwards, then the work starts somewhere else: at being found by the people looking for you. The free SEO scan shows in a few seconds where your site stands. And if you want to talk further about what else AI can do for your business, from separate skills to full automation, we simply do that in a conversation.