nw-five-whys-methodology

Toyota 5 Whys methodology with multi-causal branching, evidence requirements, and validation techniques

322 stars

Best use case

nw-five-whys-methodology is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Toyota 5 Whys methodology with multi-causal branching, evidence requirements, and validation techniques

Teams using nw-five-whys-methodology should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/nw-five-whys-methodology/SKILL.md --create-dirs "https://raw.githubusercontent.com/nWave-ai/nWave/main/nWave/skills/nw-five-whys-methodology/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/nw-five-whys-methodology/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How nw-five-whys-methodology Compares

Feature / Agentnw-five-whys-methodologyStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Toyota 5 Whys methodology with multi-causal branching, evidence requirements, and validation techniques

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Five Whys Methodology

## Philosophical Foundation

Taiichi Ohno: "By repeating why five times, the nature of the problem as well as its solution becomes clear."

Core tenets: scientific evidence-based investigation | address fundamental causes not symptoms | solve to prevent recurrence | use findings for Kaizen

## Multi-Causal Investigation

Complex problems have multiple root causes. Investigate comprehensively:
- **Parallel**: investigate all symptoms/conditions simultaneously
- **Branch**: follow each cause through all five WHY levels
- **Cross-cause**: ensure multiple causes don't contradict
- **Comprehensive**: address all root causes, not just primary

## WHY Level Definitions

### WHY 1: Symptom Investigation
What is immediately observable? Investigate all symptoms. Each branch continues independently. Document verifiable evidence per symptom.

```
WHY 1A: Path not found [Evidence: file exists but wrong context -- Windows vs WSL paths]
WHY 1B: Permission denied [Evidence: user context mismatch between host and container]
WHY 1C: Timing issues [Evidence: race conditions with file system operations]
```

### WHY 2: Context Analysis
Why does this condition exist? Follow each WHY 1 through context. Check if factors connect multiple causes. Examine system/environment/operational context.

### WHY 3: System Analysis
Why do conditions persist? How system enables multiple failure modes. How causes interact systemically. Analyze design/architecture decisions.

### WHY 4: Design Analysis
Why not anticipated? Review design assumptions. Identify all design blind spots. Trace decisions to original context.

### WHY 5: Root Cause Identification
Fundamental causes. Multiple root causes expected for complex issues. Ensure all contributing causes identified. Focus on deepest level.

## Validation and Verification

### Evidence Requirements
Each WHY level must have verifiable evidence for all causes. Root causes must explain all symptoms collectively. Solutions must address all root causes.

### Backwards Chain Validation
1. Trace each root cause forward to symptom | 2. "If this exists, would it produce this symptom?" = must be yes
3. Cross-validate: multiple roots must not contradict | 4. Completeness: "Missing contributing factors?" at each level

### Solution Completeness
Every root cause -> corresponding solution | Prevent recurrence, not just mitigate | Use findings for system improvement

## Branch Documentation Format

```
PROBLEM: [clear problem statement]

WHY 1A: [symptom] [Evidence: ...]
  WHY 2A: [context] [Evidence: ...]
    WHY 3A: [system factor] [Evidence: ...]
      WHY 4A: [design factor] [Evidence: ...]
        WHY 5A: [root cause] [Evidence: ...]
        -> ROOT CAUSE A: [fundamental cause]
        -> SOLUTION A: [prevention strategy]

WHY 1B: [symptom] [Evidence: ...]
  WHY 2B: [context] [Evidence: ...]
    ...

CROSS-VALIDATION:
- Root Cause A + Root Cause B: [consistent/contradictory]
- All symptoms explained: [yes/no, gaps if any]
```

Related Skills

nw-tdd-methodology

322
from nWave-ai/nWave

Deep knowledge for Outside-In TDD - double-loop architecture, ATDD integration, port-to-port testing, walking skeletons, and test doubles policy

nw-research-methodology

322
from nWave-ai/nWave

Research output templates, distillation workflow, and quality standards for evidence-driven research

nw-leanux-methodology

322
from nWave-ai/nWave

LeanUX backlog management methodology - user story template, story sizing, story states, task types, Definition of Ready/Done, anti-pattern detection and remediation

nw-discovery-methodology

322
from nWave-ai/nWave

Question-first approach to understanding user journeys. Load when starting a new journey design or when the discovery phase needs deepening.

nw-design-methodology

322
from nWave-ai/nWave

Apple LeanUX++ design workflow, journey schema, emotional arc patterns, and CLI UX patterns. Load when transitioning from discovery to visualization or when designing journey artifacts.

nw-bdd-methodology

322
from nWave-ai/nWave

BDD patterns for acceptance test design - Given-When-Then structure, scenario writing rules, pytest-bdd implementation, anti-patterns, and living documentation

nw-ux-web-patterns

322
from nWave-ai/nWave

Web UI design patterns for product owners. Load when designing web application interfaces, writing web-specific acceptance criteria, or evaluating responsive designs.

nw-ux-tui-patterns

322
from nWave-ai/nWave

Terminal UI and CLI design patterns for product owners. Load when designing command-line tools, interactive terminal applications, or writing CLI-specific acceptance criteria.

nw-ux-principles

322
from nWave-ai/nWave

Core UX principles for product owners. Load when evaluating interface designs, writing acceptance criteria with UX requirements, or reviewing wireframes and mockups.

nw-ux-emotional-design

322
from nWave-ai/nWave

Emotional design and delight patterns for product owners. Load when designing onboarding flows, empty states, first-run experiences, or evaluating the emotional quality of an interface.

nw-ux-desktop-patterns

322
from nWave-ai/nWave

Desktop application UI patterns for product owners. Load when designing native or cross-platform desktop applications, writing desktop-specific acceptance criteria, or evaluating panel layouts and keyboard workflows.

nw-user-story-mapping

322
from nWave-ai/nWave

User story mapping for backlog management and outcome-based prioritization. Load during Phase 2.5 (User Story Mapping) to produce story-map.md and prioritization.md.