problem-framinglisted

# Problem Framing ## Purpose Make the assistant define the real problem before it designs or writes code. ## Preserves Problem definition. ## Required Evidence - User request or symptom. - Current evidence, or an explicit note that evidence is missing. - Constraints, non-goals, or success signal if known. ## Failure Signs - The response proposes implementation before naming the problem. - Assumptions are presented as facts. - No first verification step is defined. ## When To Use - The request starts with an implementation idea instead of a problem. - A bug report lacks reproduction evidence. - A feature request mixes goals, constraints, and solution guesses. - Success is described as "make it work" rather than a verifiable outcome. ## When Not To Use - Pure formatting, typo fixes, or copy edits. - Mechanical dependency bumps with clear validation. - Work already framed by a current issue, PRD, failing test, or incident note. ## Inputs Expected - User request or issue summary. - Any known symptom, affected workflow, user, logs, screenshots, or failing command. - Relevant constraints, deadlines, or non-goals if known. ## Output Expected ```md Problem: Current evidence: Assumptions: Non-goals: Success condition: First verification step: ``` ## Process 1. Restate the request as a problem, not a solution. 2. Identify actor, workflow, boundary, and observable symptom. 3. Separate facts from interpretation. 4. Name assumptions that still need checking. 5. Define su