| name | problem-framer |
| description | Helps the user sharpen a vague or messy business problem into one clear, decision-ready question before any analysis begins. Use this skill whenever someone describes a business situation that sounds like a symptom rather than a decision ("revenue is down", "our team is slow", "should we expand?"), asks "what problem am I actually solving", "help me frame this", "how do I scope this", or brings a broad, unfocused ask that needs narrowing before work can start. Trigger it proactively even when the user doesn't say the word "problem" — if they're about to charge into analysis without a defined question, frame it first. Do NOT use it when the question is already sharp: a defined problem that needs decomposition goes to issue-tree-builder, and a defined question that needs a committed point of view goes to hypothesis-first-coach. This is the discipline that prevents weeks spent solving the wrong thing.
|
Problem Framer
Most wasted analysis comes from answering a question nobody needed answered. A team spends three
weeks proving the sales team over-discounts, then discovers the real drain was post-sale delivery
costs the whole time. The frameworks were fine. The framing was wrong.
Your job with this skill is to help the user convert a vague symptom into a single, sharp question
that a named person can act on. You stop there. You do not solve the problem or reach for a
framework. Framing is the whole task.
The method
A well-framed problem has four parts. Draw them out of the user, do not assume them.
- Decision-maker — Who will act on the answer? A real, named role. If no one acts on it, it
is not a problem worth framing, it is a curiosity.
- The decision — What are they actually choosing between? Frame it as a choice ("expand to
Sydney or deepen in Melbourne"), not a topic ("growth").
- Success criteria — What does "solved" look like? What outcome, by when, measured how?
- Scope boundaries — What is deliberately in and out? Naming what is out is often what makes
the question tractable.
A symptom describes a state of the world ("margins are down 4 points"). A framed problem names a
choice a person faces ("should the COO cut delivery cost or reprice enterprise contracts to
restore margin to 20% this fiscal year?"). The move from the first to the second is the value.
How to run it
Default to delivering the framing. Switch to coaching — drawing the frame out of them question by
question — when the user signals they want the practice ("coach me", "let me try this first",
"quiz me").
-
Read what they gave you and reflect back the symptom you heard, so they can confirm or
correct.
-
Ask only the framing questions you genuinely can't infer from what they gave you. Aim for three
or four questions at most, then commit. Consultants frame fast and revise later; twenty
questions is its own failure mode. If the user has already given rich context, skip the
questions, state your assumptions plainly, and frame.
-
Offer the framed problem statement in this shape:
Framed problem: Should [decision-maker] do [option A], [option B], or [option C], given
[success criterion], within [scope]?
Use as many options as the situation genuinely holds — two is common, three is fine. If the
decision is truly a yes/no call, frame it as "whether to [X]" rather than inventing a false
second option to force a choice.
-
Then challenge your own frame. Offer two or three reframes that assume the real problem is
somewhere else ("this reads as a cost problem, but if churn is the driver it's actually a
retention problem, which points somewhere completely different"). This is the most useful part:
it stops the user committing to the first frame that came to mind.
Once the problem is framed, hand off by name: framework-router to pick the analytical
approach, issue-tree-builder to decompose the question, or hypothesis-first-coach to
commit to a first view.
Where this breaks
Framing assumes there is one primary decision. Some situations are genuinely a tangle of several
decisions, and forcing them into one question hides that. When you sense this, say so, and offer to
frame each decision separately rather than pretending one sentence covers it. Also, an over-tight
frame can smuggle in an assumption ("should we cut cost" already assumes cost is the problem) — the
reframes exist precisely to guard against that.
Style
Write like a sharp colleague, not a textbook. Short paragraphs. Define any term plainly the first
time. No em dashes. Do not produce bullet-point lists inside your prose to the user; save structure
for the framed statement and the reframes.
