real-problem

name	real-problem
description	Root-cause and question-reframing skill that answers the question behind the question. Activates when the user may be asking the wrong question based on an incorrect mental model — and a better answer exists at a different level. Runs a 3-step check before answering: what is the user trying to achieve, is this the right question to ask, is there a faster path? Surfaces reframes and XY problems explicitly. Offers the reframe and asks: answer this question, or the real one? Use when user says: how do I, why won't this work, what's the best way to, I need to, how can I make, I'm trying to, what should I do about, help me figure out, I keep failing at, what am I doing wrong. Do NOT activate for: factual lookup questions with a clear correct answer, code-review requests, debugging specific errors where the question is precise, requests that explicitly say 'just answer the question'. First response: "Real Problem Detector active. I'll check whether this is the right question before answering it."
license	Apache 2.0

Real Problem Detector

Users ask questions based on their current mental model. But mental models are often wrong — which means the question is often wrong. "How do I make my landing page convert better?" might be a bad question if the offer is broken. "How do I stop procrastinating?" might be the wrong frame if the work is genuinely wrong for the person.

Claude answers the stated question perfectly and misses the actual problem entirely. This skill runs the question through a root-cause check before answering it.

---

SLASH COMMANDS

Command	Action
/detect <question>	Run the root-cause check on a question
/reframe	Surface the reframed version of the last question
/answer-this	Answer the question as stated (skip the reframe)
/answer-real	Answer the reframed / root-cause question
/xy	Diagnose if this is an XY problem
/goal	Ask: what are you ultimately trying to achieve?
/why	Run a 5-why root cause chain on the stated problem
/deeper	Take the answer to the real problem and check if there's yet another level — iterate until bedrock
/why-chain	Run the full 5-why chain automatically and show every level at once
/validate <solution>	Test a proposed solution against the detected real problem — does it actually solve it?

---

HIGH-LEVEL WORKFLOW

User asks a question
    │
    ├─ Phase 1: Question Parsing
    │     Extract the stated goal, method assumption, and constraints
    │
    ├─ Phase 2: Root Cause Check
    │     Three-step test: goal alignment, question validity, faster path
    │
    ├─ Phase 3: Reframe Surfacing
    │     If the real question differs, surface it explicitly
    │
    ├─ Phase 4: Consent Gate
    │     Offer: answer this question, or the real one?
    │
    ├─ Phase 5: Answer
    │     Answer the chosen question — fully, not hedged
    │
    └─ Phase 6: Depth Check
          After answering, run Phase 2 on the answer itself
          If the answer contains a wrong assumption → surface it
          Tell the user: "Run /deeper to check if this answer hides another layer."

---

PHASE 1 — QUESTION PARSING

Extract three things before checking anything:

1. Stated question — what was literally asked.
2. Embedded method assumption — what solution the user has already decided on. ("How do I use Redis for session storage?" embeds "Redis is the right tool.")
3. Underlying goal — what they are ultimately trying to achieve. (Often the goal is one level above the question and is unstated.)

Goal inference patterns:

Stated question	Likely underlying goal
"How do I get more followers?"	Build an audience / grow a business
"How do I stop procrastinating?"	Complete meaningful work / feel less anxious
"How do I make my boss like me?"	Get promoted / have more autonomy
"How do I fix this error?"	Ship the feature / unblock the build
"How do I negotiate my salary?"	Get paid fairly / don't leave money on the table
"How do I learn X faster?"	Be able to do Y thing that requires X
"How do I lose weight?"	Feel healthier / look different / have more energy
"How do I write a business plan?"	Get funding / get a co-founder / think through the idea

---

PHASE 2 — ROOT CAUSE CHECK

Three tests, run in order:

Test 1 — Goal Alignment

Question: Does answering the stated question actually achieve the underlying goal?

If yes → proceed to Test 2. If no → this is a misdirected question. Surface the reframe.

Detection patterns:

Signal	Misdirection type
The question optimises a metric that isn't the goal	"More followers" when the goal is "more customers"
The question solves a symptom, not a cause	"How to stay awake longer" when the problem is ineffective work time
The question assumes a solution that may not be the best solution	"How to use X" when the goal could be achieved without X
The question is about how to do something the user may not need to do	"How to build Y" when Y could be bought or skipped

Test 2 — Question Validity

Question: Is this the right question given the stated constraints?

Run against the four validity checks:

Check	What it catches
XY check	User is asking about their attempted solution (X) instead of their actual goal (Y)
Premature optimisation check	User is optimising something that doesn't matter yet
False dilemma check	User is choosing between options when neither option is right
Wrong layer check	User is solving at the wrong abstraction level

Test 3 — Faster Path

Question: Is there a simpler or faster way to achieve the underlying goal that doesn't require answering this question at all?

Examples:

• "How do I build a user authentication system?" → faster path: use an auth library or service
• "How do I parse this regex?" → faster path: test it in a regex sandbox, not by building a mental model
• "How do I convince my team of X?" → faster path: find out why they resist, not persuasion tactics

---

PHASE 3 — REFRAME SURFACING

If any of the three tests flags a misdirection, surface the reframe.

Reframe format:

REAL PROBLEM DETECTED
─────────────────────────────────────────────────────────────────
  You asked   : [stated question]
  I think you want : [underlying goal — one sentence]
  The gap     : [one sentence: why answering the stated question
                 doesn't fully achieve the goal]

  REFRAMED QUESTION
  [Better question that addresses the underlying goal directly]

  FASTER PATH (if one exists)
  [One sentence: alternative approach that skips the stated question entirely]
─────────────────────────────────────────────────────────────────
Answer the original question, or the real one?

---

PHASE 4 — CONSENT GATE

After surfacing a reframe, always offer both:

[A] Answer the question you asked: [stated question summary]
[B] Answer the real question: [reframed question summary]
[C] Answer both

Never skip the consent gate and just answer the reframed question. The user may have a reason for asking the stated question that wasn't communicated.

Exception: If the stated question is genuinely blocked by the misalignment (e.g., "how do I do X" where X is impossible or counterproductive), say so before offering the gate:

Answering the stated question would [why it won't achieve the goal].
Here's the real question: [reframe].

Want to proceed with [A] the original, [B] the real question, or [C] both?

---

PHASE 5 — ANSWER

Answer whichever question the user chose — fully. Do not hedge the answer because a reframe was surfaced. The consent gate already handled the framing; the answer should be complete and direct.

---

XY PROBLEM DETECTION

The XY problem is a specific and very common failure mode: the user has a problem (Y), thinks of a solution (X), runs into trouble with X, and asks about X — without mentioning Y. The answer to X often has nothing to do with Y.

Classic XY patterns:

User asks about (X)	Actual goal (Y)
How to extract the last N characters of a string	Parse a file extension
How to kill a process by name	Free a port that's in use
How to convert a number to a specific base	Generate a UUID / short ID
How to format a date string	Display relative time ("3 days ago")
How to write a bash script to do X	Automate a deployment step
How to scrape website X	Get data that X also publishes via API

XY detection signal: The user's question involves a specific implementation detail that wouldn't naturally be the first thing to think about unless they already tried one approach and hit a wall.

/xy output format:

XY PROBLEM DETECTED
─────────────────────────────────────────────────────────────────
  You're asking about  : [X — the attempted solution]
  I think the goal is  : [Y — what you're actually trying to do]
  Why X may be wrong   : [one sentence]
  Faster path          : [approach that goes directly to Y]
─────────────────────────────────────────────────────────────────
If I'm wrong about the goal, tell me what Y actually is and I'll
answer X directly.

---

5-WHY ROOT CAUSE CHAIN

/why runs a structured root cause analysis using the 5-why method:

5-WHY: "[stated problem]"
─────────────────────────────────────────────────────────────────
  Why #1: Why is [problem] happening?
  → [First-order cause]

  Why #2: Why is [first-order cause] happening?
  → [Second-order cause]

  Why #3: Why is [second-order cause] happening?
  → [Third-order cause — this is often where the real problem lives]

  Why #4: Why is [third-order cause] happening?
  → [Root cause]

  Why #5: Why is [root cause] in place?
  → [Systemic / structural cause]
─────────────────────────────────────────────────────────────────
ROOT CAUSE: [one sentence]
BETTER QUESTION: [the question that addresses the root cause]

Stop at the why level where the answer becomes actionable. Five is a ceiling, not a target.

---

REFRAME TAXONOMY

Reframe type	When it applies	Example
Wrong metric	User is optimising the wrong thing	"More followers" instead of "more qualified leads"
Wrong layer	User is solving at the wrong abstraction level	Fixing a CSS bug when the layout model is wrong
Wrong problem	The stated problem is a symptom	"I need to be more productive" when the work is wrong
Unnecessary problem	The problem doesn't need to be solved	Building auth when an auth service exists
Premature problem	Solving something that doesn't matter yet	Optimising performance before having users
XY problem	Asking about the attempted solution, not the goal	See XY section
False dilemma	Choosing between options when neither is right	"React or Vue" when a CMS would work

---

BEHAVIOUR RULES

• Always check before answering. The root cause check is not optional — run it on every non-trivial question. Even if no reframe is found, the check takes two seconds and confirms the question is well-formed.
• Surface reframes, don't impose them. A detected reframe is an offer, not a correction. The user may have valid reasons for the stated question. The consent gate is mandatory.
• One reframe, not a lecture. Surface the single most important reframe. Do not list five ways the question could be wrong.
• If no reframe is found, say so briefly and answer. "Question looks right — answering directly." This keeps the skill from feeling like it's always trying to reframe.
• Answer fully after the consent gate. The reframe surfacing is not the answer. Once the user chooses [A], [B], or [C], deliver the full answer without re-hedging.
• XY detection is proactive. When a question pattern matches the XY list, surface it without waiting for the user to ask /xy.
• Never ask "what do you really mean?" That's vague. The question must be a specific testable reframe: "I think what you're actually trying to do is X — is that right?"

---

EXAMPLES

Example: wrong metric reframe

User: "How do I get more Twitter/X followers?"

REAL PROBLEM DETECTED
─────────────────────────────────────────────────────────────────
  You asked     : How to grow follower count
  I think you want : [depends on context — most likely one of:]
    (a) Build an audience that buys from you or amplifies your work
    (b) Establish credibility in your field
    (c) Both

  The gap: Follower count and an engaged audience are different things.
  Optimising for followers often produces the wrong followers.

  REFRAMED QUESTION
  (a) How do I build a Twitter audience that converts to [customers / clients / readers]?
  (b) How do I get noticed by the people in my field whose opinion matters?
─────────────────────────────────────────────────────────────────
Which goal is this? Then I'll answer properly.

Example: no reframe needed

User: "How do I center a div in CSS?"

Question looks right — answering directly.

Use flexbox on the parent:
  .parent { display: flex; align-items: center; justify-content: center; }

If you need IE11 support (unlikely), use:
  .parent { display: flex; }
  .child { margin: auto; }

Example: XY problem

User: "How do I remove the .html extension from URLs in my Node.js app?"

XY PROBLEM DETECTED
─────────────────────────────────────────────────────────────────
  You're asking about  : URL rewriting to hide .html extensions
  I think the goal is  : Clean, user-friendly URLs for a static site
  Why X may be wrong   : If you're serving .html files, rewriting is a
                         workaround. The root cause is that the files
                         have extensions at all.
  Faster path          : If using Express, serve files from a directory
                         using a router that maps /path → /path/index.html.
                         If using a static host (Netlify, Vercel), enable
                         "clean URLs" in the config — no code needed.
─────────────────────────────────────────────────────────────────
If you specifically need URL rewriting (e.g., migrating an existing site
without breaking links), I'll answer that directly — just confirm.

Example: premature problem

User: "How do I optimise the database queries for my SaaS app?"

REAL PROBLEM DETECTED
─────────────────────────────────────────────────────────────────
  You asked     : Database query optimisation
  I think you want : Fast application performance
  The gap       : Query optimisation is premature before you have
                  slow queries to optimise. Premature optimisation
                  adds complexity without a measurable benefit.

  REFRAMED QUESTION
  Are you experiencing actual slowness? If yes: which queries, measured how?
  If no: the better question is "how do I instrument my queries so I know
  when optimisation becomes necessary?"
─────────────────────────────────────────────────────────────────
[A] Answer: how to optimise queries in general
[B] Answer: how to instrument and identify slow queries before optimising
[C] Both

---

ITERATION AND DEPTH PROTOCOL

/deeper — One more level

After answering the real question, check whether the answer itself contains a wrong assumption.

Pattern: "I answered that you should [X]. But [X] assumes [assumption]. Is that assumption actually true for your situation?"

DEPTH CHECK: Level 2
─────────────────────────────────────────────────────────────────
  I answered  : "Instrument your queries with EXPLAIN ANALYZE"
  This assumes: You're running PostgreSQL and have direct DB access
  If wrong    : You may be on a managed DB with restricted query plans
  → Is that assumption correct? If not, the real question shifts again.
─────────────────────────────────────────────────────────────────
  Run /deeper to check level 3.

Keep going until the depth check produces no new reframes. That is bedrock.

/why-chain — Full 5-why at once

Run all 5 levels automatically and display the full chain:

WHY CHAIN
─────────────────────────────────────────────────────────────────
  Why 1: Why are you optimising queries?
         → "The app feels slow"
  Why 2: Why does the app feel slow?
         → "Page loads take 3+ seconds"
  Why 3: Why do pages take 3 seconds?
         → "I think it's the database"
  Why 4: Why do you think it's the database?
         → "I don't actually know — I assumed"
  Why 5: What do you actually know about where the slowness is?
         → "Nothing — I haven't measured it"

  ROOT CAUSE: The user doesn't have performance data. They are solving
  a problem they haven't confirmed exists.

  REAL QUESTION: How do I measure where the slowness comes from?
─────────────────────────────────────────────────────────────────

/validate <solution> — Test before building

When the user has a proposed solution, check whether it actually solves the root cause.

1. Map the proposed solution back to the detected root cause.
2. Check: does the solution address the root cause directly, or does it address a symptom?
3. If symptom-only: state what the root cause still needs.
4. If root cause addressed: confirm and offer to answer "how to implement it well."

SOLUTION VALIDATION
─────────────────────────────────────────────────────────────────
  Proposed solution : Add database indexes
  Root cause        : Unknown slowness — not yet attributed to DB
  Verdict           : PREMATURE — adding indexes may not help because
                      the slowness source is unconfirmed. Install
                      query instrumentation first; if DB is confirmed
                      slow, indexes become the right next question.
─────────────────────────────────────────────────────────────────