--- name: brainstorming-resource-constraints description: "Facilitate a Resource Constraints ideation session to generate creative solutions under explicit budget, time, or capacity limitations. Invoke when the user needs to unlock innovative options in the face of a binding project constraint." --- > 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 team must generate actionable options despite one or more binding resource limits. Typical triggers include: - A sponsor has frozen or reduced the budget mid-project and the team must re-scope deliverables - A schedule constraint (regulatory deadline, market window, semester end date) makes the original timeline unachievable - A key resource (team member, vendor, infrastructure) has become unavailable and alternatives must be identified - A risk response plan requires identifying options that fit within a cost or capacity ceiling Do not invoke for open-ended ideation with no stated constraint; prefer this skill only when at least one explicit limit is on the table and the goal is to find solutions *within* that limit, not to remove it. ## Summon the SME Before facilitating, load the canonical reference to ground the session in established constraint-management thinking. **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.resourceConstraints` 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 constraint-based problem solving as described by Theory of Constraints literature (Goldratt, 1984) and its application in project management contexts. Cite the canonical URL from `vendor/pm-kit/sources-index.json` at key `sources.resourceConstraints` in the output. Do not fabricate quotations or page numbers. In both cases, the URL to cite is `https://en.wikipedia.org/wiki/Theory_of_constraints`. ## Facilitation script Walk the user through these steps in sequence. Do not skip steps or combine them. **Step 1 — Name the constraint.** Ask the user to state the binding constraint as a single, concrete, measurable sentence. Example: "The remaining budget for the delivery sprint is $8,000 and cannot be increased." Confirm the constraint is observable and quantified before proceeding. **Step 2 — Current approach inventory.** Ask the user to list the approaches they were using before the constraint became binding. This establishes the baseline the team must adapt or replace. **Step 3 — Constraint-forced options.** Ask: "What could we still deliver if we kept only the highest-value elements and eliminated everything else?" Capture at least three options. Prompt the team to be specific about what would be cut and what would remain. **Step 4 — Analogy prompt.** Ask: "What do teams with permanently limited resources do that we have not tried?" Prompt with domains the team has not yet considered (for example: lean manufacturing, volunteer organizations, academic research projects, open-source communities). Capture the options generated. **Step 5 — Extreme-constraint thought experiment.** Ask: "If the constraint were ten times tighter — if we had one-tenth the budget, one-tenth the time, or one-tenth the staff — what single action would we take?" This forces identification of the highest-leverage option. Capture the answer. **Step 6 — Option scoring.** Present the full list of options gathered in steps 3–5. Ask the user to mark each option as High / Medium / Low for both feasibility within the constraint and impact on the project goal. Identify the top two or three options. **Step 7 — Action plan.** For each top option, confirm: the owner (role or team), the target date or sprint, and the specific first action to take within the constraint. **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-resource-constraints/.md`. `` is a kebab-case ASCII slug (max 40 characters) derived from the constraint statement (e.g., `budget-freeze-sprint-4`). 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): ``` ``` ## 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.