brainstorming-five-whys

name	brainstorming-five-whys
description	Facilitate a Five Whys root-cause analysis. Invoke when the user needs to find the underlying cause of a project impediment, schedule slip, recurring defect, or stakeholder dissatisfaction signal.

Adapted from bmad-method:bmad-brainstorming (MIT, © 2025 BMad Code, LLC). See THIRD_PARTY_NOTICES.md.

When to use

Use this skill when a project problem keeps recurring or its immediate cause is clearly a symptom of something deeper. Typical triggers include:

• A sprint impediment that teams have "fixed" before but keeps returning
• A milestone slip whose stated reason is "the schedule was too aggressive" or "requirements changed"
• A recurring defect type surfacing across multiple sprints
• A stakeholder dissatisfaction signal raised in a retrospective or status review

Do not invoke for ambiguous brainstorming or divergent ideation; prefer a convergent root-cause analysis only when a specific, observable problem is on the table.

Summon the SME

Before facilitating, load the canonical Five Whys reference to ground your analysis in established practice.

Reading the config. Check .pm-kit.config.json for the sourcesMode field:

• If sourcesMode is "online" (opt-in): fetch the URL stored at the key sources.fiveWhys in vendor/pm-kit/sources-index.json using your available web-fetch capability. Do not name a specific tool — use whatever your runtime provides. Ground the facilitation in what you read. Do not fabricate quotations or page numbers from any version of that page.
• If sourcesMode is "offline" or the field is absent (the default): rely on your general knowledge of the Five Whys technique as developed by Taiichi Ohno and described by the Lean Enterprise Institute. Cite the canonical URL from vendor/pm-kit/sources-index.json at key sources.fiveWhys in the output. Do not fabricate quotations or page numbers.

In both cases, the URL to cite is https://www.lean.org/lexicon-terms/5-whys/.

Facilitation script

Walk the user through these steps in sequence. Do not skip steps or combine them.

Step 1 — Problem statement. Ask the user to state the problem in a single, concrete, time-bounded sentence. Example: "Three of the last four sprint reviews were accepted with open defects on the payment flow." Confirm the statement is observable and bounded before proceeding.

Step 2 — Why #1. Ask: "Why did this happen?" Capture the answer verbatim. Prompt for a causal answer if the user restates the problem instead of explaining it.

Step 3 — Why #2. Ask: "Why did [Why #1 answer] happen?" Capture the answer. Check that the answer is a new causal layer, not a synonym or restatement of the previous answer. If so, prompt the user to go deeper.

Step 4 — Why #3. Repeat the same pattern with Why #2's answer.

Step 5 — Why #4. Repeat with Why #3's answer.

Step 6 — Why #5. Repeat with Why #4's answer. The number five is a guideline, not a hard limit — continue if the root cause has not yet been reached, or stop earlier if the causal chain terminates naturally.

Step 7 — Root cause. Summarize the root cause identified at the bottom of the chain. Confirm with the user that the root cause is actionable and is not an attribution of blame to a person.

Step 8 — Corrective actions. Propose at least two corrective actions that target the root cause, not a symptom. Each action should be assignable to a role or team and time-bounded.

Step 9 — Output. Produce the completed analysis using the structure in TEMPLATE.md (sibling file). Fill every section. Leave no placeholder unfilled.

Step 10 — Save the artifact. Save the filled artifact to docs/pm-kit/outputs/<skill-name>/<short-slug>.md. For this skill, <skill-name> is brainstorming-five-whys. <short-slug> is a kebab-case ASCII slug (max 40 characters) derived from the problem statement (e.g., payment-flow-defects). Confirm the final path with the user before writing. If the target file already exists, ask the user whether to overwrite, append a date suffix (e.g., -2026-04-20), or choose a different slug. The artifact must begin with the three-line provenance header below (preserved as HTML comments so they do not render):

<!-- Generated by agentic-pm-kit:brainstorming-five-whys on YYYY-MM-DD -->
<!-- Languages: communication=<value>, output=<value> -->
<!-- Source mode: offline | online -->

This save-to-disk path and provenance-header pattern are the convention for every skill in the kit; only the skill name in the first comment changes per skill.

Languages

The kit separates the language used for live agent–user dialogue from the language used in the saved artifact. Both values live in .pm-kit.config.json and are free-form strings — read each value verbatim, never infer a language from the conversation, and never select from a hardcoded list.

Facilitation dialogue. Speak to the user during facilitation in the language at language.communication. Use the string verbatim.

Filled artifact (saved TEMPLATE.md output). Produce the written artifact in the language at language.output. If language.output is absent or empty, fall back to language.communication.

Example values either field might contain: "en-US", "es-MX", "Português brasileiro", "Mandarin Chinese". Accept any string as given. This bifurcation is the normative pattern for every skill in the kit.

Acceptance gate

When the analysis is complete, point the user to CHECKLIST.md (sibling file) and ask them to verify each item. Remind them that the output must be marked PASS or FAIL. On FAIL, invite the user to return with specific notes so the facilitation can be resumed or corrected.