brse-feasibility-challengelisted

# BrSE Feasibility Challenge Use this skill when relaying the customer request as-is would set the project up to fail. The skill structures a respectful pushback with a concrete alternative — not a refusal. ## When To Use - Customer requests scope that conflicts with current architecture or other commitments. - Deadline is technically impossible without scope cut. - Approach has a known failure mode (performance, security, data integrity). - Request contradicts an existing decision or contract. ## When NOT To Use - The request is feasible — do not invent objections. - The "infeasibility" is a personal preference, not evidence-backed — collect evidence first. - The customer has already agreed to the constraint and just needs status — use `brse-client-report`. - The challenge would require a contract amendment that only PM/legal can drive — escalate, do not draft as BrSE. ## Workflow 1. Restate the customer's request in your own words — verify you understood before challenging. 2. Identify which dimension is infeasible: - **Technical** — architecture, dependency, data limitation - **Scope** — too much work for the resources - **Timeline** — deadline shorter than minimum viable path - **Risk** — feasible but unsafe (security, data, compliance) - **Conflict** — contradicts a prior decision or contract clause 3. Gather evidence for the infeasibility claim — source trace, prior incident, benchmark, contract clause. Without evidence, do not challenge. 4. Design