| name | brainstorming-alien-anthropologist |
| description | Facilitate an Alien Anthropologist session in which the team examines their own project, processes, or user environment through the eyes of a completely uninitiated outside observer to surface hidden assumptions. Invoke when requirements elicitation, stakeholder onboarding, or user research is hampered by familiarity blindness. |
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 is too close to the domain to see it clearly and fresh observation is needed. Typical triggers include:
- A requirements workshop that produces assumptions rather than verified user needs
- A new PM, analyst, or stakeholder joining a project whose internal logic has never been written down
- A user-research step where interview questions are loaded with insider language the end-user does not share
- A process review where the team can no longer explain why certain steps exist
Do not invoke as a substitute for formal user research when empirical data collection is warranted. Do not invoke when the goal is root-cause analysis of a known problem; prefer Five Whys or Failure Analysis for that.
Summon the SME
Before facilitating, load the canonical ethnographic field-study reference to ground the session in established observation methods.
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.alienAnthropologist 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 ethnographic observation and field-study methods as described in the Nielsen Norman Group's field-studies research, and design-thinking literature that uses the "outsider observer" framing. Cite the canonical URL from vendor/pm-kit/sources-index.json at key sources.alienAnthropologist in the output. Do not fabricate quotations or page numbers.
In both cases, the URL to cite is https://www.nngroup.com/articles/field-studies/.
Facilitation script
Walk the user through these steps in sequence. Do not skip steps or combine them.
Step 1 — Choose the subject. Ask the user to identify what will be observed: a user workflow, an internal process, a meeting structure, a product interaction, or a domain concept. Confirm the subject is specific enough to observe in detail.
Step 2 — Adopt the alien posture. Instruct the user: "Describe the subject as if you are an outside observer who has never encountered this organization, this industry, or this technology before. Use no jargon. Explain every term as if your audience is from a different planet." Prompt with: "What happens first? What happens next? Who is involved and why? What objects or systems are present and what do they do?"
Step 3 — Catalogue the strange. Ask: "What would strike an outside observer as unusual, redundant, contradictory, or unexplained?" List every observation the user names without defending or explaining it. Defer explanations to the next step.
Step 4 — Explain the strange. For each item in the catalogue, ask: "Why does this exist? If you do not know, say so." Classify each as:
- Explained — a clear functional reason exists.
- Historical — "it used to be necessary" or "someone set it up that way."
- Unknown — no one can explain it.
Step 5 — Identify assumptions embedded in the design. From the unexplained and historical items, derive the assumptions the project or process has inherited. Ask: "What would have to be true for this to make sense? Is it true today?"
Step 6 — Implications for the project. Ask: "Which of these inherited assumptions are load-bearing for our plan? Which are risks? Which could be dropped or redesigned?" Produce at least two concrete recommendations.
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-alien-anthropologist/<short-slug>.md. <short-slug> is a kebab-case ASCII slug (max 40 characters) derived from the observed subject. 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):
<!-- Generated by agentic-pm-kit:brainstorming-alien-anthropologist 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 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.
