--- name: brainstorming-chaos-engineering description: "Facilitate a Chaos Engineering brainstorming session that stress-tests a project plan, system design, or process by deliberately hypothesizing worst-case failures to reveal hidden fragilities. Invoke when preparing a risk register, pre-mortem analysis, or resilience review before a critical milestone." --- > Adapted from bmad-method:bmad-brainstorming (MIT, © 2025 BMad Code, LLC). See THIRD_PARTY_NOTICES.md. ## When to use Use this skill when the team needs to surface systemic weaknesses by imagining controlled failure before real failure occurs. Typical triggers include: - Preparing or expanding a risk register before a planning gate or milestone review - A pre-mortem exercise at the start of a high-stakes sprint or project phase - A resilience review of a process, integration, or dependency that has never been tested under adverse conditions - A sponsor or auditor asking: "What happens if this fails?" and the team has no documented answer Do not invoke for ideation of new features or product directions; this skill is diagnostic, not generative. Do not invoke when a root cause for an existing incident is already known; use Five Whys or Failure Analysis instead. ## Summon the SME Before facilitating, load the canonical Chaos Engineering 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.chaosEngineering` 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. - If `sourcesMode` is `"offline"` or the field is absent (the default): rely on your general knowledge of chaos engineering as defined by the Principles of Chaos Engineering community — specifically: define steady state, hypothesize that steady state continues, introduce real-world failure variables, and attempt to disprove the hypothesis. Cite the canonical URL from `vendor/pm-kit/sources-index.json` at key `sources.chaosEngineering` in the output. Do not fabricate quotations or page numbers. In both cases, the URL to cite is `https://principlesofchaos.org/`. ## Facilitation script Walk the user through these steps in sequence. Do not skip steps or combine them. **Step 1 — Define steady state.** Ask the user: "What does normal, successful operation look like for this plan or system?" Define at least two measurable indicators of steady state (e.g., "all sprints deliver 80% of committed story points," "integration layer responds within 2 seconds"). **Step 2 — Hypothesize continuity.** State the hypothesis explicitly: "We expect steady state to hold even if we introduce the following adverse conditions." Confirm the user understands this is the assumption to be stress-tested. **Step 3 — Generate failure variables.** Ask: "What real-world events could disrupt steady state?" Prompt across categories: - **People** — key contributor unavailable, sponsor change, team conflict - **Dependencies** — third-party delay, vendor failure, integration breakage - **Scope** — requirement reversal, compliance change, discovered technical debt - **Environment** — budget cut, tooling outage, regulatory shift Collect at least eight failure variables. **Step 4 — Probe the hypothesis.** For each failure variable, ask: "If this happened, would steady state hold? What would break first? How quickly would the project recover?" Rate each as: - **Resilient** — steady state would hold or recover within one sprint. - **Fragile** — steady state would break and recovery is unclear. - **Unknown** — the team cannot answer. **Step 5 — Prioritize fragilities.** Rank fragile and unknown items by likelihood × impact. Identify the top three systemic weaknesses — the findings that most urgently require a mitigation plan. **Step 6 — Design recovery mechanisms.** For each top weakness, propose at least one concrete change to the plan, process, or team structure that increases resilience. Each mechanism should be assignable to a role and time-bounded. **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-chaos-engineering/.md`. `` is a kebab-case ASCII slug (max 40 characters) derived from the plan or system being stress-tested. 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.