--- 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//.md`. For this skill, `` is `brainstorming-five-whys`. `` 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): ``` ``` 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.