reframe-reframe-the-problem

name	reframe - Reframe the Problem
description	Systematically reframe a problem by changing the level of abstraction, stakeholder perspective, time horizon, success criteria, or constraint set. Generate genuinely different framings, not word substitutions.
output	{"format":"prose"}

Reframe the Problem

Input: $ARGUMENTS

---

Interpretations

Before executing, identify which interpretation matches the user's input:

Interpretation 1 — Stuck on a problem: The user has been working on a problem and is stuck. The current framing may be the obstacle — a different framing could reveal solutions invisible from the current angle. Interpretation 2 — Challenge a default framing: The user (or someone else) has framed a situation in a particular way, and the user suspects the framing itself is wrong, limiting, or biased — and wants to see alternatives. Interpretation 3 — Generate multiple framings for strategic choice: The user wants to deliberately see the same situation through several lenses before choosing which framing to adopt — not because the current one is wrong, but because the choice of frame determines the solution space.

If ambiguous, ask: "I can help with reframing a problem you are stuck on, challenging a framing you suspect is wrong, or generating multiple framings for strategic comparison — which fits?" If clear from context, proceed with the matching interpretation.

---

Core Principles

1. The frame is not the problem. How you describe a problem determines what solutions you can see. "We need to hire more engineers" and "We need to ship faster" and "We are building the wrong thing" can all describe the same situation — but each frame leads to completely different actions.

2. Reframing is not rewording. Replacing "challenge" with "opportunity" is not reframing. A genuine reframe changes what counts as the problem, who owns it, what success looks like, or which constraints are real. If the same solutions are viable before and after, you have not actually reframed.

3. Every frame includes and excludes. A frame makes some things visible and others invisible. The question is not "is this frame true?" but "what does this frame make visible, and what does it hide?" Every reframe should reveal something the original frame concealed.

4. Constraints are hypotheses. Most constraints are assumed, not verified. "We cannot change the deadline" — says who? Under what conditions? Reframing often works by questioning which constraints are real (physics, law) versus assumed (habit, convention, fear).

5. The presenting problem is rarely the real problem. People frame problems in terms of the solution they already have in mind. "We need a better CRM" is a solution frame. The problem frame might be "we are losing customers" or "we do not understand our customers" or "sales and support cannot coordinate." Work backward from the stated problem to find the problem behind the problem.

6. Abstraction level changes everything. The same situation framed at different levels of abstraction yields different problems: too concrete and you are solving symptoms; too abstract and you are solving philosophy. The right level is where you have both agency and impact.

---

Phase 1: CAPTURE — Understand the Current Frame

Step 1: Articulate the Current Frame

CURRENT FRAME:

[F1] Problem as stated: [how the user or situation describes the problem]
[F2] Implied cause: [what the current framing assumes is causing the problem]
[F3] Implied solution direction: [what kinds of solutions this framing points toward]
[F4] Success criteria: [what "solved" looks like in this frame]
[F5] Who owns it: [who is responsible for solving it in this frame]
[F6] Constraints assumed: [what is treated as fixed/unchangeable]
[F7] Time horizon: [how far out the frame looks]
[F8] What this frame makes INVISIBLE: [what cannot be seen or discussed from this angle]

Step 2: Diagnose Frame Limitations

FRAME DIAGNOSIS:

[F9] Is this a SOLUTION frame disguised as a problem?
  [Yes/No — if yes, what is the underlying problem?]

[F10] Is this framed at the right level of abstraction?
  Too concrete: [what symptom-level detail is being treated as the problem]
  Too abstract: [what philosophical-level framing is preventing action]

[F11] Whose perspective dominates this frame?
  [Who framed it, and what does their position make them see/miss?]

[F12] What constraint is doing the most work in this frame?
  [Which assumption, if removed, would most change the solution space?]

---

Phase 2: GENERATE — Create Genuinely Different Frames

Step 3: Apply Reframing Lenses

Apply each lens to generate a new frame. A genuine reframe changes the solution space — if the same actions make sense before and after, it is not a real reframe.

Lens 1: Change the Level of Abstraction

[F13] ONE LEVEL UP (more abstract):
  Problem becomes: [restatement at higher level]
  Now the solution space includes: [what new options appear]
  But loses: [what specificity or actionability is sacrificed]

[F14] ONE LEVEL DOWN (more concrete):
  Problem becomes: [restatement at lower level]
  Now the solution space includes: [what specific actions become visible]
  But loses: [what systemic view is sacrificed]

Lens 2: Change the Stakeholder Perspective

[F15] From [different stakeholder]'s perspective:
  Problem becomes: [how they would frame it]
  What they see that the original frame misses: [insight]
  What they miss that the original frame sees: [blind spot]

[F16] From [the person most affected but least consulted]:
  Problem becomes: [how they would frame it]
  What they see: [insight]
  What they miss: [blind spot]

Lens 3: Change the Time Horizon

[F18] SHORT-TERM frame (this week/month):
  Problem becomes: [urgent version]
  Solutions available: [what can be done now]
  Risk: [what long-term issue does this ignore?]

[F19] LONG-TERM frame (1-5 years):
  Problem becomes: [strategic version]
  Solutions available: [what structural changes become worth doing]
  Risk: [what immediate pain does this ignore?]

[F20] RETROSPECTIVE frame (looking back from success):
  "What was the real problem?" becomes: [how future-you would describe it]
  Key insight: [what is obvious in hindsight that is not obvious now]

Lens 4: Change the Constraint Set

[F21] Remove the biggest constraint:
  If [constraint] were not fixed, the problem becomes: [reframe]
  Is this constraint actually real? [physics/law vs. habit/convention/fear]
  What would it take to remove it? [practical assessment]

[F22] Add a constraint:
  If you also had to [new constraint], the problem becomes: [reframe]
  Does the added constraint force a more creative solution? [assessment]

[F23] Invert a constraint:
  What if [constraint] were actually a resource? [reframe]
  Example: "We have too little time" → "Time pressure forces us to cut scope to the essential"

Lens 5: Change the Success Criteria

[F24] Different metric:
  If success were measured by [alternative metric] instead of [current metric]:
  Problem becomes: [reframe]
  Different actions suggested: [what changes]

[F25] Different beneficiary:
  If we were solving this for [different group]:
  Problem becomes: [reframe]
  What insight does this yield for the original problem? [transfer]

---

Phase 3: SELECT — Choose the Most Useful Frame

Step 4: Compare Frames

FRAME COMPARISON:

| Frame | Problem Statement | Solution Space | Actionability | What It Reveals | What It Hides |
|-------|------------------|----------------|---------------|-----------------|---------------|
| Original [F1] | [summary] | [options] | [High/Med/Low] | [insight] | [blind spot] |
| Abstraction up [F13] | [summary] | [options] | [High/Med/Low] | [insight] | [blind spot] |
| Abstraction down [F14] | [summary] | [options] | [High/Med/Low] | [insight] | [blind spot] |
| Stakeholder [F15] | [summary] | [options] | [High/Med/Low] | [insight] | [blind spot] |
| Time shift [F19/20] | [summary] | [options] | [High/Med/Low] | [insight] | [blind spot] |
| Constraint shift [F21] | [summary] | [options] | [High/Med/Low] | [insight] | [blind spot] |
| Success shift [F24] | [summary] | [options] | [High/Med/Low] | [insight] | [blind spot] |

STATE THE REAL PROBLEM: After comparing all frames, commit to one sentence: "The real problem is ____." If you cannot write this sentence, you are cataloguing frames, not reframing.

Step 5: Evaluate and Recommend

REFRAME EVALUATION:

[F26] MOST PRODUCTIVE REFRAME: [which frame and why]
  This frame is best because: [it reveals X, enables Y, without losing Z]

[F27] COMPLEMENTARY FRAMES: [which frames work together]
  Use [frame A] for [strategic decisions] and [frame B] for [tactical execution]

[F28] DANGEROUS FRAMES: [which frames to avoid and why]
  [Frame X] is seductive because [reason] but would lead to [bad outcome]

[F29] KEY INSIGHT FROM REFRAMING:
  The original frame assumed [assumption]. By shifting to [new frame], we can see that
  the real problem is [restatement] — which opens up [specific new options].

---

Failure Modes

Failure	Signal	Fix
Rewording, not reframing	Same solutions work in "new" frame	Check: does this frame change what actions make sense? If not, it is cosmetic
Positive spin	"Challenge" becomes "opportunity" with no structural change	A reframe must change what is visible, not just the emotional valence
Frame shopping	Trying frames until you find one that supports a pre-existing preference	Generate all frames first, then evaluate. Do not stop at the first convenient one
Abstraction escape	Going so abstract the problem becomes unfalsifiable ("we need better culture")	Test: can you take a specific action this week from this frame? If not, go down one level
Constraint worship	Accepting all constraints as given and only reframing within them	Explicitly question each constraint: is this physics or policy? Verified or assumed?
Single-lens reframe	Only changing one dimension (e.g., only stakeholder perspective)	Apply at least three different reframing lenses to ensure genuine diversity of frames

---

Depth Scaling

Default: 2x. Parse depth from $ARGUMENTS if specified (e.g., "/reframe 4x [input]").

Depth	Min Reframing Lenses	Min Alternative Frames	Min Constraints Questioned	Min Stakeholder Perspectives
1x	2	3	1	1
2x	3	5	2	2
4x	5	7	3	3
8x	5	10	5	5

These are floors. Go deeper where insight is dense. Compress where it is not.

---

Pre-Completion Checklist

• Current frame fully articulated — including what it makes invisible
• Frame diagnosed for solution-masquerading-as-problem
• At least three different reframing lenses applied
• Each reframe changes the solution space (not just the wording)
• At least one constraint questioned for whether it is real or assumed
• Frames compared on what they reveal AND what they hide
• Most productive reframe identified with reasoning
• Dangerous frames flagged with explanation
• Key insight stated: what the original frame was hiding

---

Integration

• Use from: /rca (when root cause analysis keeps finding symptoms — reframe the problem), /collab (when parties disagree because they hold different frames), /dcp (when decision feels stuck — the frame may be wrong)
• Routes to: /aex (extract assumptions in the new frame), /systhink (if reframe reveals a systems problem), /collab (if reframe reveals a multi-stakeholder problem)
• Differs from: /aex extracts assumptions within a frame; /reframe changes the frame itself. /cda imports analogies from other domains; /reframe shifts dimensions within the same domain.
• Complementary: /aex (test assumptions in each frame), /collab (when stakeholders hold different frames), /systhink (reframe from event-level to system-level)