--- name: brainstorming-assumption-reversal description: "Facilitate an Assumption Reversal session that surfaces hidden constraints by inverting core beliefs about a challenge. Invoke when the user needs to break out of conventional solution space, challenge inherited design decisions, or stress-test a plan's underlying logic." --- > Adapted from bmad-method:bmad-brainstorming (MIT, © 2025 BMad Code, LLC). See THIRD_PARTY_NOTICES.md. ## When to use Use this skill when a team's options feel artificially narrow or when prior decisions are being treated as immovable constraints without verification. Typical triggers include: - A solution has been "the only way" for several planning cycles without being re-examined - A stakeholder challenge reveals the team assumed something that was never confirmed - A project retrospective surfaces that a failed approach rested on a false assumption - A new-product or new-feature discovery session needs to escape inherited design patterns - A risk review identifies a high-severity assumption with no validation plan Do not invoke when constraints are already verified as hard (regulatory, legal, physical) and cannot be changed; use the Constraint Mapping skill to work within them instead. Do not invoke for root-cause analysis of a known failure; use Five Whys instead. ## Summon the SME Before facilitating, load the canonical Assumption Reversal 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.assumptionReversal` 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 Assumption Reversal technique as described in lateral thinking literature, including Edward de Bono's principle of challenging accepted assumptions to generate new perspectives. Cite the canonical URL from `vendor/pm-kit/sources-index.json` at key `sources.assumptionReversal` in the output. Do not fabricate quotations or page numbers. In both cases, the URL to cite is `https://en.wikipedia.org/wiki/Lateral_thinking`. ## Facilitation script Walk the user through these steps in sequence. Do not skip steps or combine them. **Step 1 — Topic.** Ask the user to identify the plan, design, feature, or decision they want to examine. Write it down as the session topic. **Step 2 — Assumption elicitation.** Ask the user to list every assumption embedded in the topic — things the team believes to be true that have not been formally confirmed. Prompt with: "What must be true for this to work?" and "What are we taking for granted?" Aim for a minimum of six assumptions before moving to Step 3. Capture each assumption as a declarative statement. **Step 3 — Reversal.** For each assumption, formulate its direct reversal: the opposite or negation of the original statement. The reversal does not need to be realistic — it only needs to be the logical inverse. Capture reversals alongside their source assumptions. **Step 4 — Impact analysis.** For each reversal, ask: "If this reversal were true, what would change about our plan, design, or decision?" Capture the consequences as a brief statement. Consequences may be practical changes, new opportunities, or previously invisible risks. **Step 5 — Prioritize.** Identify the two or three reversals whose consequences are most significant — either highest-risk (the assumption is likely wrong) or highest-opportunity (the reversal reveals a better path). Mark these for follow-up. **Step 6 — Follow-up actions.** For each prioritized reversal, define a concrete action: validate the original assumption, or explore the reversal's consequences further. Each action is assigned to a role and given a target date. **Step 7 — Output.** Produce the completed analysis using the structure in `TEMPLATE.md` (sibling file). Fill every section. Leave no placeholder unfilled. **Step 8 — Save the artifact.** Save the filled artifact to `docs/pm-kit/outputs/brainstorming-assumption-reversal/.md`. `` is a kebab-case ASCII slug (max 40 characters) derived from the session topic (e.g., `checkout-flow-assumptions`). 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.