| name | brainstorming-first-principles-thinking |
| description | Facilitate a First Principles Thinking session that strips assumptions from a problem and rebuilds understanding from verified foundational truths. Invoke when the team is trapped in inherited constraints, over-specified solutions, or scope debates that cannot be resolved by incremental negotiation. |
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's framing of a problem is blocking progress because it is built on unexamined assumptions. Typical triggers include:
- A scope debate where every proposed constraint seems immovable, yet the total scope is undeliverable
- A planning assumption that has never been tested ("we have to use the legacy system," "the budget ceiling is fixed")
- A recurring redesign cycle caused by requirements that were inherited rather than derived
- A stakeholder challenge: "Why are we building this at all?" that cannot be answered with the current framing
Do not invoke for root-cause analysis of a specific event; use Five Whys instead. Do not invoke when the goal is to generate many divergent ideas; this skill converges on validated foundational truths, not a broad option list.
Summon the SME
Before facilitating, load the canonical First Principles reference to ground the session in established reasoning 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.firstPrinciplesThinking 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 first principles reasoning as articulated in Aristotle's Posterior Analytics and its contemporary application in engineering and project management. Cite the canonical URL from vendor/pm-kit/sources-index.json at key sources.firstPrinciplesThinking in the output. Do not fabricate quotations or page numbers.
In both cases, the URL to cite is https://plato.stanford.edu/entries/aristotle-logic/.
Facilitation script
Walk the user through these steps in sequence. Do not skip steps or combine them.
Step 1 — Problem frame. Ask the user to state the problem or decision they are trying to resolve. Capture it as a single sentence. Confirm the statement describes a real, current project situation.
Step 2 — Assumption inventory. Ask: "What do you currently believe to be true about this problem?" List every assumption the user names. Do not evaluate them yet — collect all stated constraints, design choices, stakeholder expectations, and resource limits.
Step 3 — Challenge each assumption. For each assumption, ask: "Is this verifiably true, or is it inherited convention?" Classify each as:
- Verified — the team has confirmed this directly and it cannot change.
- Unverified — accepted as true but not checked.
- Convention — "the way we have always done it," with no structural reason.
Step 4 — Identify the bedrock. From the verified assumptions, identify the irreducible facts about the problem: physical constraints, legal requirements, confirmed stakeholder commitments. These are the first principles — the foundations you build from.
Step 5 — Rebuild from bedrock. Ask: "If we started only from these verified facts, how would we frame the problem? What solutions become visible that were hidden by the unverified assumptions?" Generate at least two alternative framings.
Step 6 — Evaluate alternatives. For each alternative framing, assess: Is this technically feasible given our verified constraints? Does it satisfy the core stakeholder need? What would it cost to pursue it?
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-first-principles-thinking/<short-slug>.md. <short-slug> is a kebab-case ASCII slug (max 40 characters) derived from the problem statement. 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-first-principles-thinking 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.
