Define The Problem

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:

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:

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:

## 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.

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.

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.