brainstorming-resource-constraints

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/<short-slug>.md. <short-slug> 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):

<!-- Generated by agentic-pm-kit:brainstorming-resource-constraints 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.