brse-requirement-clarifierlisted

# BrSE Requirement Clarifier ## Overview Convert ambiguous Japanese or bilingual customer input into an implementation-ready requirement without inventing facts. **Core principle:** Every uncertainty becomes an `Assumption`, `Open Question`, or `Needs Source Trace` — never a fabricated answer. ## When To Use - Customer just sent a Japanese or bilingual request that mixes goal, constraint, and example without clear scope. - A spec inherited from another BrSE has gaps before it can be forwarded to dev. - Stakeholder message contains assumptions that the offshore team will read differently. - Before invoking `brse-spec-verify`, `brse-impact-trace`, or `brse-ticket-breakdown` — they all expect a structured requirement as input. ## When NOT To Use - Input is already a verified, structured spec — go to `brse-spec-verify` or `brse-ticket-breakdown` directly. - Customer message is purely a status reply (no new request) — use `brse-client-report` instead. - Question is from a developer about how to implement, not from a customer about what to build — use `brse-dev-triage`. - Input is so vague it cannot be parsed even literally — escalate to the customer for resubmission; do not invent. ## Workflow 1. Identify the source language and intended audience: customer, PM, developer, QA, or mixed. 2. Preserve product names, route names, task IDs, Japanese labels, table headers, and code identifiers exactly. 3. Extract the real request: - goal - affected users - affected scre