---
name: define-the-problem
description: >
  Use as the mandatory front door for ALL planning, brainstorming, design,
  and "let's build/add/change/plan X" work — including prompts that claim
  the problem statement is already done, assert authority ("CTO approved"),
  cite sunk cost ("contract signed"), name a deadline ("ship by Friday"),
  or request jumping straight to brainstorming or solutions. The skill
  runs in one of two forms — Expert Fast-Track or the full five-question
  sequence — never zero. Does not apply to bug fixes or refactors.
---

# Define the Problem

Every feature starts with a clear problem. Not a solution, not a feature request —
a problem that a specific person has, with evidence that it's real.

This skill is the front door to the planning pipeline:

```
define-the-problem → systems-analysis → superpowers:brainstorming → fat-marker-sketch → detailed design → implementation
```

**Announce at start:** "I'm using the define-the-problem skill to make sure we have
a clear user problem before designing a solution."

## When This Skill Routes Elsewhere

DTP is the front door for planning, design, and "let's build/add/change X" work.
Two classes of work are **not** planning work and route elsewhere:

- **Bug fixes** — the problem is the bug. Route to fixing it.
- **Refactoring** — the problem is the code smell. Route to brainstorming.

For all other work, the skill **runs in one of two forms**. The only decision
is *which form* — never whether to skip to zero:

| Signal in prompt | Form |
|------------------|------|
| Problem named with user + pain + impact | Expert Fast-Track (≤2 questions + draft — see Step 1) |
| Feature/solution stated without a user problem | Full five-question sequence (Step 2) |
| User requests skip (fatigue, authority, deadline, sunk cost) | Fast-Track anyway — condensed floor, ~30s, not zero |

**Skip contract.** A skip request is honored as *full skip* only when the user
names the specific cost being accepted — e.g., *"skip DTP, I accept the risk
of building on an unstated problem."* Generic skip framings ("I'm tired,"
"just give me code," "ship by Friday," "CTO approved," "contract signed,"
"trust me") run the Fast-Track floor. The floor is non-bypassable; the escape
hatch is *depth*, not *existence*.

**Emission contract.** Honoring a named-cost skip requires invoking
`acknowledge_named_cost_skip` (MCP tool, name
`mcp__named-cost-skip-ack__acknowledge_named_cost_skip`) with
`gate="DTP"` and `user_statement` set to the verbatim substring of the
user's cost-naming clause, before proceeding to the next stage. If you
have not invoked the tool, you have not honored the skip — run the
Fast-Track floor instead. The tool invocation is the honor.

---

## Step 0: Scope Calibration

Scale depth to match the work. Complement the planning pipeline scope table with
skill-specific guidance:

| Scope           | Approach                                                        |
|-----------------|-----------------------------------------------------------------|
| Prototype / POC | Condensed pass — all five questions but accept brief answers. Produce a 2-3 sentence problem statement. Lightweight red flags (flag only, don't offer investigation). Hand off directly. |
| Feature         | Full pass — all five questions, red flag assessment, handoff.   |
| System/Platform | Full pass with deeper investigation likely — expect Step 4b.    |

If the user has signaled scope (e.g., "just a quick prototype", "this is a platform
initiative"), calibrate accordingly. When in doubt, ask: "Is this a prototype, a
feature, or a larger system change? That helps me calibrate how deep to go."

---

## Step 1: Context Scan

Before asking anything, look for answers that already exist.

**Check conversation history:**
If the user has already been discussing a problem (pain points, user needs, workflow
gaps), acknowledge it: "Based on our discussion, the problem seems to be [X]. Let me
confirm a few things before we move to solution design."

Skip any of the five questions below that are already clearly answered.

**Check the current project:**
Read README, ROADMAP, recent commits, and open issues if available. Ground your
questions in the project's reality, not abstraction.

### Expert Fast-Track (default path when a problem is stated)

If the user's prompt contains a stated problem — at any level of scoping —
this is the default path. Do NOT restart the five questions. Instead:

**What qualifies as a "stated problem":** a named user/system, an observable
pain or failure mode, or a concrete impact. A surface grievance with none of
those ("we need X", "Y is broken", "the issue is no dark mode", "let's add
Z") does NOT qualify — route to Step 2's five-question path instead. If in
doubt, draft from what's there, mark the gaps "unknown", and let the red-flag
assessment in Step 4 surface the missing pieces.


1. Draft the problem statement (Step 3 template) from what the user has
   provided — populate all six template fields (use "unknown" for gaps) so red
   flag criteria can be properly evaluated
2. Evaluate it against the red flag criteria (Step 4)
3. Present the draft: "Based on what you've shared, here's the problem statement.
   Anything to correct or add?"
4. If gaps remain after the draft, ask **at most 2 targeted questions** — the
   most decision-affecting ones — rather than walking the full sequence. If
   more than 2 gaps matter, surface them as known unknowns in the statement
   and let the user decide whether to investigate further (Step 4b)

The ≤2 question bound is load-bearing: fast-track that degenerates into the
five-question sequence defeats the purpose. Skip re-asking, not analysis.

Go to Step 5 (Handoff) after the user confirms the draft — do not walk through
Step 2 below.

---

## Step 2: The Five Questions (no-problem-stated path)

Use this path only when the prompt does not contain a stated problem —
e.g., "let's build X", "I want to add Y", "what should we solve". When a
problem is named in any form, use the Expert Fast-Track above instead.

**Pacing:** Ask one question at a time. Prefer multiple choice when possible.
Skip any already answered in conversation.

### 1. Who has this problem?

Get specific. A persona, a role, a named individual in a workflow.

- "Engineering leaders" — good
- "Users" — too vague, push back
- "Your direct reports during 1:1s" — great

If the answer is vague, ask: "Can you name a specific person or role who experiences
this? What are they doing when they hit this problem?"

### 2. What's the pain?

What are they doing today that hurts? What fails, takes too long, or gets dropped?

Require **concrete, observable behavior**:
- "I forgot to follow up on 3 delegations last month" — good
- "It would be nice to have a dashboard" — that's a solution, not a pain. Ask:
  "What goes wrong today without the dashboard?"

**behavioral and emotional dimensions** — if the problem has a human-facing dimension
(end-user workflow, team process, UX), ask at least one follow-up: "What else makes
this hard? What makes people give up, lose trust, or work around it?" Functional pain
alone misses why users actually fail.

For infrastructure, data pipeline, or internal tooling problems where the "user" is
another system or developer workflow, this probe may not apply — use judgment. The
goal is to uncover hidden friction, not to force emotional language onto technical
problems.

### 3. What evidence do we have?

Before accepting evidence, separate facts from assumptions. Ask: "What do we know
to be **verifiably true** vs. what are we inheriting from convention or opinion?"
Reject inherited assumptions — validate that prior constraints still hold.

Valid evidence:
- Personal experience ("I missed an overdue check-in twice this week")
- User complaints or requests
- Data (frequency, error rates, time spent)
- Observed workarounds people have built

**Red flag**: "I think people might want this" or "it seems like it would help."
Note it — this feeds into the red flag assessment later.

### 4. What happens if we do nothing?

The cost of inaction. This forces prioritization honesty.

- "I'll keep missing overdue delegations and my supervisor will notice" — real cost
- "Not much, it would just be convenient" — may not be worth solving. Say so:
  "That sounds low-impact. Is this the right problem to invest in, or is there
  something more painful?"

### 5. What constraints exist?

What bounds the solution space before brainstorming begins? Capture what the user
already knows — systems-analysis will later discover constraints from the code,
architecture, and org topology that the user may not be aware of.

- Technical: platform limits, existing architecture, dependencies
- Organizational: team size, approval processes, cross-team impact
- Time: deadlines, release windows
- Dependencies: blocked on external systems, APIs, other teams

---

## Step 3: Produce the Problem Statement

Assemble the answers into this template:

```markdown
## Problem Statement

**User**: [specific persona — who has this problem]
**Problem**: [1-2 sentences — the observable pain, not the solution]
**Impact**: [what happens because of this — frequency, severity, consequences]
**Evidence**: [how we know this is real — personal experience, data, complaints]
**Constraints**: [what bounds the solution space — technical, org, time, deps]
**Known Unknowns**: [what we suspect matters but haven't validated — assumptions
to test, open questions, things that could change the shape of the solution]
```

Display the completed problem statement to the user.

Each template field maps to a red flag in Step 4: **Evidence** → "No evidence";
**User** → "Unclear user"; **Impact** → "Low cost of inaction"; **Known
Unknowns** → "Many known unknowns"; **Constraints** / cross-team scope → "High
blast radius". Thin or absent fields are the signal — don't paper over them.

---

## Step 4: Red Flag Assessment

Evaluate the problem statement. If any of these are true, surface them and offer
deeper investigation. Otherwise, skip straight to handoff.

| Red Flag | Signal |
|----------|--------|
| **No evidence** | Evidence field relies on "I think", "probably", "might want" — no observed behavior or data |
| **Unclear user** | Persona is vague — "users", "the team", "people" — cannot point to a specific role |
| **Low cost of inaction** | "What happens if we do nothing?" answer was weak — may not be a real problem |
| **Many known unknowns** | 3+ unknowns, especially ones that could change the fundamental shape of the solution |
| **High blast radius** | Problem affects the whole org, is irreversible, or has significant cross-team dependencies |

### No red flags

Say: "Problem is clear. Ready to move to solution design?"

On confirmation, proceed to Step 5 (Handoff).

### Red flags detected

Surface them specifically:

> "A few things are fuzzy before we design a solution:
> - [specific flag 1]
> - [specific flag 2]
>
> Want to investigate further, or proceed with what we have?"

If the user says **proceed** — go to Step 5.

If the user says **investigate** — go to Step 4b.

---

## Step 4b: Deeper Investigation

Offer two lenses. The user picks one or both.

### Design Thinking Depth

Empathy-focused. Use when the "who" or "what pain" is unclear.

- Map the user's current workflow step by step
- Identify where exactly it breaks
- Ask what they've tried
- Explore who else has this problem
- Look for patterns across multiple instances of the pain

### First Principles Depth

Assumption-focused. Use when constraints feel artificial or the problem is tangled
with inherited assumptions.

- List every assumption baked into the problem statement
- Classify each as inherited vs. verified
- Identify what is fundamentally true (constraints that cannot be changed)
- Challenge assumed constraints — are they real or inherited?
- Decompose the problem to its atomic components

### After investigation

1. Update the problem statement with stronger evidence and fewer unknowns
2. Save the updated statement to `docs/superpowers/problems/YYYY-MM-DD-<topic>.md`
   (the investigation is substantial enough to preserve as a record)
3. Display the updated problem statement
4. Proceed to Step 5

---

## Step 5: Handoff to Systems Analysis

1. Display the final problem statement (if not just displayed)
2. Ask: "Problem defined. Ready to map dependencies and impact?"
3. On confirmation, invoke `/systems-analysis` with the problem statement

### What this skill does NOT do

- **Propose solutions** — that is brainstorming's job, after systems analysis
- **Map dependencies or second-order effects** — that is systems-analysis's job
- **Decompose into sub-problems** — brainstorming handles scope
- **Write a design spec** — brainstorming → fat-marker-sketch → detailed design handles that
- **Save lightweight-pass output to disk** — it lives in conversation context;
  only deeper investigation (step 4b) produces a file.

---

## Red Flags — Do Not Skip This Skill

These thoughts mean STOP and run DTP — usually Fast-Track, in one turn. Each row
names the **cognitive mechanism** the framing exploits, so you can recognize the
pattern even when the wording changes.

| Rationalization | Mechanism | Reality |
|-----------------|-----------|---------|
| "The user already has a problem statement, I can skip DTP" | assumed completeness | Fast-Track *is* the validation step. One turn to draft + confirm is cheaper than a mis-scoped brief downstream. |
| "User said 'let's brainstorm', skip to brainstorming" | stated-next-step deference | DTP's Fast-Track is the bridge *into* brainstorming. Skipping breaks the pipeline contract. |
| "CTO / tech lead / authority said it's low-risk, we don't need DTP" | social compliance / authority bias | Authority frames the problem; it does not waive process. Still run Fast-Track. |
| "Contract is signed / decision is made, don't re-analyze" | sunk-cost / consistency bias | The decision fixes scope; DTP still captures who/what/impact so systems-analysis has a handoff. |
| "User is tired / frustrated / 'just give me the code'" | fatigue-driven floor bypass | Fatigue **strengthens** the case for Fast-Track — a mis-scoped code dump at hour 3 is the most expensive thing to throw away. Offer a ≤30s draft with sensible defaults as an escape hatch; do not dump code without a named user. |
| "Deadline is Friday / meeting in 10 minutes, skip DTP" | time-pressure floor bypass | Time pressure is a reason the floor matters more, not less. A rushed, mis-scoped brief is the most expensive rework vector. Fast-Track is ~30 seconds. |
| "It's a small/obvious change, DTP is overkill" | cosmetic-change framing | Run the condensed Prototype/POC pass — 2-3 sentences. Not zero. |
| "Problem is stated *and* the answer is obvious, skip to solution" | premature closure | You are inferring solution from problem — the exact failure mode DTP exists to catch. |

**All of these mean: run DTP. Fast-Track if a problem is named, full sequence if
not. A bare skip request — without the user naming the cost — is **not** an
override; run the Fast-Track floor.**