nw-five-whys-methodology
Toyota 5 Whys methodology with multi-causal branching, evidence requirements, and validation techniques
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
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/nw-five-whys-methodology/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How nw-five-whys-methodology Compares
| Feature / Agent | nw-five-whys-methodology | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/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
Deep knowledge for Outside-In TDD - double-loop architecture, ATDD integration, port-to-port testing, walking skeletons, and test doubles policy
nw-research-methodology
Research output templates, distillation workflow, and quality standards for evidence-driven research
nw-leanux-methodology
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
Question-first approach to understanding user journeys. Load when starting a new journey design or when the discovery phase needs deepening.
nw-design-methodology
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
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
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
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
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
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
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
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.