--- name: brainstorming-decision-tree-mapping description: "Facilitate a Decision Tree Mapping session to visualize all paths, outcomes, and risks of a complex project decision before committing. Invoke when the user faces a multi-branch decision where each choice leads to distinct consequences and the full option space has not been charted." --- > 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 decision has multiple branches, each with distinct downstream consequences, and the team must understand the full option space before committing. Typical triggers include: - A build-vs-buy-vs-partner decision where each path implies different costs, timelines, and risk profiles - A go/no-go milestone gate where partial completion of one workstream changes the feasibility of others - A resource allocation decision with contingent outcomes (e.g., hiring depends on funding, which depends on a client decision) - A risk response planning session where the team must map trigger events to response branches Do not invoke for open-ended ideation without clear decision points; prefer Mind Mapping or Morphological Analysis. Do not invoke when the primary need is root-cause analysis; prefer Five Whys. ## Summon the SME Before facilitating, load the canonical Decision Tree reference to ground the session 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.decisionTreeMapping` 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 decision trees as used in decision analysis and project management, as described by Kepner-Tregoe. Cite the canonical URL from `vendor/pm-kit/sources-index.json` at key `sources.decisionTreeMapping` in the output. Do not fabricate quotations or page numbers. In both cases, the URL to cite is `https://kepner-tregoe.com/training/decision-analysis-refresher/`. ## Facilitation script Walk the user through these steps in sequence. Do not skip steps or combine them. **Step 1 — Decision statement.** Ask the user to state the root decision in one sentence. Confirm it is a genuine decision point (the team has agency over the outcome) rather than a risk event (which belongs in a risk matrix). **Step 2 — First-level branches.** Ask: "What are the distinct options at this decision point?" Record each option as a branch from the root node. Use square-bracket labels for decision nodes (e.g., `[Build]`, `[Buy]`, `[Partner]`). **Step 3 — Outcomes and chance events.** For each first-level branch, ask: "What happens next — is it another decision, an uncertain event, or a terminal outcome?" Record chance events as circle nodes with a brief probability estimate if known. Record terminal outcomes as leaf nodes with a brief description of the consequence. **Step 4 — Second-level branches (if applicable).** Expand each chance or sub-decision node by repeating Step 3 until all paths reach a terminal outcome or a natural stopping point agreed with the user. **Step 5 — Probability and impact estimates.** Where the user can estimate probabilities for chance nodes, record them. Where outcomes can be quantified (cost, time, revenue), record the values. Estimates are optional but increase the artifact's utility. Do not fabricate numbers — record only what the user supplies. **Step 6 — Path comparison.** Ask the user to identify the two or three most likely or most important paths. For each, summarize the chain of choices and events that lead to the terminal outcome. **Step 7 — Recommended path.** Ask the user to state which path they currently favor and why, given the full picture. **Step 8 — Output.** Produce the completed decision tree using the structure in `TEMPLATE.md` (sibling file). Fill every section. Leave no placeholder unfilled. **Step 9 — Save the artifact.** Save the filled artifact to `docs/pm-kit/outputs/brainstorming-decision-tree-mapping/.md`. `` is a kebab-case ASCII slug (max 40 characters) derived from the root decision (e.g., `build-vs-buy-auth-service`). 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): ``` ``` ## 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.