| name | brainstorming-role-playing |
| description | Facilitate a Role Playing ideation session to generate solutions and surface blind spots by viewing the project through multiple stakeholder perspectives. Invoke when the user needs empathy-based insight or a more complete view of who is affected by a project decision. |
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 or design needs to be examined from more than one stakeholder perspective. Typical triggers include:
- A change request or new requirement is likely to meet resistance from a stakeholder whose viewpoint is not represented on the team
- Stakeholder identification is incomplete and the team suspects groups are missing from the register
- A communication plan or risk response must account for stakeholder reactions that the team has not yet modeled
- A retrospective surfaces recurring conflict between teams or roles that no one has fully articulated from the other side
Do not invoke for purely technical problem-solving with no stakeholder dimension; prefer this skill only when understanding a human perspective is the bottleneck.
Summon the SME
Before facilitating, load the canonical reference to ground the session in established design-thinking 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.rolePlaying 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 role-based empathy and perspective-taking techniques as described in design-thinking practice, including the Stanford d.school's Design Thinking Bootleg. Cite the canonical URL from vendor/pm-kit/sources-index.json at key sources.rolePlaying in the output. Do not fabricate quotations or page numbers.
In both cases, the URL to cite is https://dschool.stanford.edu/resources/design-thinking-bootleg.
Facilitation script
Walk the user through these steps in sequence. Do not skip steps or combine them.
Step 1 — Frame the decision. Ask the user to state the project decision, change, or problem to be examined in a single sentence. Example: "We are proposing to compress the final testing phase from three weeks to one." Confirm the framing is clear before proceeding.
Step 2 — Identify roles to embody. Ask the user to list four to six stakeholder roles who are meaningfully affected by the decision. Include roles that are typically underrepresented (end users, regulators, downstream teams). Record each role.
Step 3 — Role embodiment — round one. For each role, ask: "Stepping into the perspective of [role]: What do you most want from this decision? What are your top concerns? What would make this outcome unacceptable to you?" Record the responses in first person, attributed to the role.
Step 4 — Conflict mapping. Review the responses collected in step 3. Identify where two or more roles have directly conflicting wants or concerns. List each conflict explicitly.
Step 5 — Opportunity mining. For each conflict identified in step 4, ask: "What change to the plan, communication, or deliverable could address both sides of this conflict?" Capture options without filtering.
Step 6 — Consensus signals. Ask: "Across all the roles, where is there alignment — what do all or most roles want?" List the common ground. These are the safe anchors for the decision.
Step 7 — Action plan. For each option from step 5, confirm: the owner (role or team), the target date or sprint, and the specific first action. Confirm that at least one action addresses the most critical conflict.
Step 8 — Output. Produce the completed analysis 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-role-playing/<short-slug>.md. <short-slug> is a kebab-case ASCII slug (max 40 characters) derived from the decision statement (e.g., compress-testing-phase). Confirm the final path with the user before writing. If the file exists, ask: overwrite, append a date suffix (e.g., -2026-04-20), or pick a new slug. The artifact begins with the three-line provenance header below (HTML comments, do not render):
<!-- Generated by agentic-pm-kit:brainstorming-role-playing on YYYY-MM-DD -->
<!-- Languages: communication=<value>, output=<value> -->
<!-- Source mode: offline | online -->
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 session 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.
