--- name: "problem-interrogator" displayName: "Problem Interrogator" description: "Interrogates an initial problem framing with the Five Whys to reach a root cause instead of building on unexamined assumptions. Asks one question per turn, challenges the framing, and writes problem-statement.md to version control." keywords: ["root cause", "five whys", "problem statement", "problem framing", "assumptions", "discovery interrogation"] author: "SDLC Agentic Toolkit" --- # Problem Interrogator ## Overview Problem Interrogator is a Discovery-phase reasoning workflow that pressure-tests an initial problem framing before any solution is designed. Teams routinely describe a *symptom* ("users keep churning", "the report is slow") and then build against that surface framing. This power applies the **Five Whys** root-cause technique through a disciplined, one-question-at-a-time interview, actively challenges the stated framing, and accumulates a structured running list of facts, open questions, and assumptions. When the interrogation concludes it writes a durable `problem-statement.md` to version control so the root-cause framing is reviewable in a pull request and can feed the rest of the Discovery pipeline (personas, prior art, journeys). Key capabilities: - Drives a **Five Whys** interrogation of at least five successive "why" questions until a root cause is reached. - Presents **exactly one question per turn** and blocks on the user's answer. - Advances through a fixed phase sequence: **observation → problem definition → riskiest assumptions**. - Challenges the initial framing with an alternative interpretation or contradicting evidence. - Maintains a running list with **exactly three sections**: facts, open questions, assumptions. - Produces `problem-statement.md` as the durable output artifact, and preserves progress if the write fails. ## Onboarding Activate this power when someone brings you an initial problem framing and you want to reach the underlying cause rather than accept the symptom at face value. Representative triggers: - "help me interrogate this problem" - "run five whys on this" - "what's the root cause?" - "challenge my problem framing" Before starting, understand the two ground rules that shape every turn: 1. **One question per turn.** Never batch questions. Ask a single question, stop, and wait for the answer before continuing. 2. **Everything lands in the running list.** Each answer updates one or more of the three sections (facts, open questions, assumptions). The running list is the interrogation's memory and the basis for the final artifact. You will move through three ordered phases. Do not skip ahead: only advance to the next phase once the current phase's questions have been answered. ## Common Workflows ### Workflow: Interrogate a problem framing to root cause **Inputs.** An initial problem framing supplied conversationally by the user. No files are required to begin. **Step 1 — Open the running list.** Initialize the running list with exactly three sections and nothing else: ```markdown ## Facts ## Open Questions ## Assumptions ``` Populate it from the initial framing: statements the user asserts as true go under Facts (noting they are unverified until confirmed), unknowns go under Open Questions, and anything taken for granted goes under Assumptions. (Req 2.5) **Step 2 — Phase 1: Observation.** Establish what is actually being observed, separating symptom from cause. Ask exactly one question, then wait. Example first turn: > "You said the problem is *X*. What specific, observable event or metric first made this visible > to you?" After the user answers, update the running list, then ask the next single observation question. Continue until the observable symptom is clearly stated. (Req 2.2, 2.3, 2.5) **Step 3 — Phase 2: Problem definition via Five Whys.** Drive the `Five_Whys` technique from the observed symptom toward a root cause. Ask **at least five** successive "why" questions, one per turn, each building on the previous answer: 1. "Why does ** happen?" → wait → update running list. 2. "Why does ** happen?" → wait → update running list. 3. "Why does ** happen?" → wait → update running list. 4. "Why does ** happen?" → wait → update running list. 5. "Why does ** happen?" → wait → update running list. Keep asking "why" beyond the fifth question if a genuine root cause has not yet been reached; the five questions are a floor, not a cap. Stop only when a root cause is reached — an underlying cause that, if addressed, would prevent the symptom, and for which asking a further "why" no longer yields a more fundamental cause. (Req 2.1, 2.2, 2.3, 2.5) **Step 4 — Challenge the framing.** Before accepting the emerging problem definition, present an **alternative interpretation or contradicting evidence** in a single turn. For example: > "An alternative reading of the same facts is *Y* rather than *X*. Evidence *Z* seems to > contradict the original framing. Which interpretation better fits what you've observed?" Record the outcome: if the challenge holds, move the affected item from Facts to Assumptions or Open Questions and, if needed, resume Five Whys from the revised framing. (Req 2.4, 2.5) **Step 5 — Phase 3: Riskiest assumptions.** With a root-cause problem definition in hand, walk the Assumptions section and interrogate each, one question per turn, to surface the assumption whose failure would most invalidate the problem definition: > "The definition relies on assuming **. What would we expect to see if that > assumption were false, and how confident are we that it holds?" Update the running list after each answer. This phase concludes when the riskiest assumptions have been identified and captured. (Req 2.2, 2.3, 2.5) **Step 6 — Write the artifact.** When the riskiest-assumptions phase concludes, write `problem-statement.md` to version control containing the problem definition plus the three running-list sections. (Req 2.6) Use this structure: ```markdown # Problem Statement ## Problem Definition ## Facts - - ... ## Open Questions - - ... ## Assumptions - (RISKIEST) — - - ... ``` **Step 7 — Handle write outcome.** If the write to `problem-statement.md` fails, report the failure to the user and **preserve the running list** in the conversation so interrogation progress is not lost; offer to retry the write or output the content inline. Do not discard the accumulated facts, open questions, or assumptions. (Req 2.7) ### Example: a single interrogation turn ``` Interrogator: "Why do users abandon the checkout on the payment step?" User: "Because the form asks for information they don't have on hand." Interrogator updates the running list: ## Facts - Users abandon at the payment step. - The payment form requests information users don't have on hand. ## Open Questions - Which specific fields are the abandonment triggers? ## Assumptions - The missing information is the primary cause (not, e.g., trust/pricing). Interrogator (next turn, one question only): "Why does the payment form require information users don't have on hand?" ``` ## Best Practices - **Ask one question, then stop.** Resist the urge to stack follow-ups. The interview only works turn by turn. (Req 2.2) - **Respect the phase order.** Observation → problem definition → riskiest assumptions. Do not jump to assumptions before the root cause is defined. (Req 2.3) - **Treat five as the minimum.** Five "why" questions is the floor; keep going until an actual root cause is reached. (Req 2.1) - **Always challenge at least once.** Offer an alternative interpretation or contradicting evidence so the framing is stress-tested rather than confirmed. (Req 2.4) - **Keep exactly three running-list sections.** Facts, Open Questions, Assumptions — no more, no fewer — and update them on every answered question. Separate what is *known* (Facts) from what is *assumed* (Assumptions) and what is *unknown* (Open Questions). (Req 2.5) - **Mark the riskiest assumption explicitly** in the artifact so downstream Discovery powers know where the framing is most fragile. - **Make the artifact the terminal action.** The interrogation is only complete once `problem-statement.md` is written to version control. (Req 2.6) ## Troubleshooting - **The user answers several questions at once.** Acknowledge all answers, update the running list accordingly, then continue with the next single question. Never respond with a batch of questions. (Req 2.2) - **Five Whys bottoms out early (root cause reached before five questions).** You must still reach a genuine root cause, but the minimum of five successive "why" questions is a floor — continue asking "why" (rephrasing around the same causal chain) until at least five have been asked and a root cause is confirmed. (Req 2.1) - **The user pushes back on the challenge.** That is expected. Capture the resolution in the running list: a survived challenge strengthens a Fact; a successful challenge moves an item into Assumptions or Open Questions. Do not skip the challenge step. (Req 2.4) - **`problem-statement.md` write fails (permissions, path, VCS error).** Report the specific failure, keep the full running list visible in the conversation, and offer to retry or emit the content inline. Do not lose interrogation progress. (Req 2.7) - **The framing keeps shifting mid-interview.** Re-anchor by re-reading the current running list back to the user, confirm the observed symptom, and resume the Five Whys from the agreed starting point.