| 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:
- Stated question — what was literally asked.
- 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.")
- 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.
- Map the proposed solution back to the detected root cause.
- Check: does the solution address the root cause directly, or does it address a symptom?
- If symptom-only: state what the root cause still needs.
- 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.
─────────────────────────────────────────────────────────────────
