problem-firewall

name	problem-firewall
description	Use when the user wants help solving something but the problem is vague, symptom-level, or framed as a premature solution. Enforce a problem-solution firewall: clarify the desired outcome, obstacles, root-cause condition, and user-owned plain-language Problem Frame before moving to solution methods.

Problem Firewall

Do not solve until the user owns the problem. The firewall separates problem definition from problem solving so the user does not optimize a symptom, jargon, or someone else's framing.

Core principles:

• Definition principle: the user must take responsibility for defining the problem. Help them understand it; do not define it for them. Strip jargon.
• Root-cause principle: identify the root-cause condition. Do not accept symptom treatment as problem definition.
• Test of Time principle: explicitly check whether a likely fix would prevent recurrence or merely treat a symptom.
• Problem-solution firewall: park solution ideas until the Clarity Gate is passed.

Steps

1. Enforce the firewall.

   • If the user starts with a solution, label it as a candidate solution and put it in the Solution Parking Lot.
   • Do not evaluate, improve, compare, or implement parked solutions yet.
   • Completion criterion: every proposed solution has been parked or translated into a problem-clarifying question.

2. Build the Problem Frame.

   • Clarify what the user wants to achieve.
   • Clarify what obstacle stands in the way.
   • If the user uses vague or expert-sounding language, ask for a plain-language version.
   • Ask one question at a time. If available evidence can answer a question, inspect the evidence instead of asking.
   • Completion criterion: the desired outcome and obstacle are stated plainly enough that a non-expert could understand them.

3. Find the Root-Cause Condition.

   • Ask: "What would have to be true for this problem not to exist in the first place?"
   • Call out the Test of Time for every proposed root-cause condition before accepting it: say, "Let's run the Test of Time: would this fix prevent the problem from returning, or would it only treat the symptom?"
   • If the problem would return later, label the current frame as symptom-level and keep tracing the root-cause condition.
   • Completion criterion: the obstacle has been traced to a plausible condition that has passed the Test of Time: if changed, it would prevent the problem from recurring.

4. Run the Teach-Back Check.

   • Default to a lightweight confirmation when the user has already given clear plain-language answers for the desired outcome, obstacle, and root-cause condition: summarize the Problem Frame and ask, "Does this match?"
   • A simple confirmation such as "yes," "yep," or "that's right" passes the Clarity Gate when the prior answers provide enough evidence of understanding.
   • If the user says "mostly," "not exactly," corrects part of the summary, or otherwise signals mismatch, treat that as a repair signal: update the Problem Frame, ask one focused repair question only if needed, then offer the summary confirmation again.
   • Require the full teach-back only when clarity is uncertain — for example, if the user keeps using vague jargon, contradicts themselves, or confirms without enough prior evidence.
   • Full teach-back shape: "I want ___, but ___ is standing in the way. The deeper condition seems to be ___. If that changed, this problem likely would not exist."
   • Completion criterion: the user can plainly confirm or state the desired outcome, obstacle, and root-cause condition.

5. Perform the Problem Handoff.

   • Only after the Teach-Back Check passes, ask whether the user already knows how they want to start solving.
   • If yes, follow their preferred solving path.
   • If no, recommend 2–4 next methods or relevant skills based on the clarified problem and available skill descriptions.
   • Include the Solution Parking Lot in the handoff, but still do not evaluate parked solutions unless the chosen next method requires it.

Reference

Problem Frame — the desired outcome plus the obstacle standing in the way, tested for root-cause depth and user understanding.

Solution Parking Lot — a temporary holding area for solution ideas mentioned during problem definition.

Root-Cause Condition — the condition that, if true or changed, would prevent the problem from existing.

Clarity Gate — the problem-defining phase is complete only when the user can plainly state the desired outcome, obstacle, and root-cause condition.

Problem Handoff — the post-firewall routing step into solution methods or other skills.

Source inspiration: Shane Parrish, Clear Thinking, problem definition and root-cause safeguards.