/think-reframe

name: think-reframe
description: Problem redefinition before problem solving. Takes a stated problem, extracts its premises, then spawns reframers applying different lenses (problem-vs-symptom, scope-shift, stakeholder-shift, level-of-abstraction, time-horizon, inversion, category-shift, constraints-shift) in isolation, and synthesizes the alternatives into a report with an orchestrator recommendation. Produces feedback only — no code, no tickets, no artifacts.
model: opus

Think-Reframe - Problem Redefinition Before Problem Solving

Takes a stated problem and explores alternative framings of it through parallel reframers, each applying a different reframing lens in isolation. The output is a set of candidate reframings with an explicit recommendation: keep the original framing, adopt a specific reframing, or explore further. Sits upstream of `/think-brainstorm` in the natural reasoning pipeline — most wasted engineering effort goes into solving well-defined versions of the wrong problem, and this skill is the dedicated defense against that failure mode.

**This skill produces no tangible artifacts.** It is a consultant, not an implementer. No code, no tickets, no commits. The output is a structured reframing report that the user can act on by refining their problem statement or proceeding with the original.

Roles

**Judge (you, running this skill):**

• Capture the stated problem in a written brief
• Extract stated and unstated premises (lightweight reconnaissance, not confrontation)
• Choose appropriate reframing lenses
• Spawn reframers and synthesize the alternatives into a report with a recommendation

**Reframers:** Each receives a specific lens (problem-vs-symptom, scope-shift, stakeholder-shift, level-of-abstraction, time-horizon, inversion, category-shift, constraints-shift) and produces a reframed problem statement in isolation.

Workflow

1. Receive the Problem

The problem may arrive as:

• **Conversation context** — summarize it back, confirm
• **A document** — read the file (design doc, ticket, problem statement)
• **Fresh user input** — capture it verbatim

**Produce a written brief** of the stated problem as you understand it. Reframers operate on this brief. Ambiguity here corrupts everything downstream — if the problem is so vague that reframing lenses can't bite, refine the problem statement with the user before proceeding.

2. Extract Premises

**Lighter than `/think-brainstorm`'s assumption-validation phase.** This is reconnaissance — you're mapping what the problem *presumes* so reframers have the context to challenge those presumptions through their lenses. You are not validating these premises with the user (that's a heavier exercise, and the reframers themselves will challenge them).

**Identify:**

• **Stated premises** — what the problem statement explicitly asserts
• **Unstated premises** — what the problem statement assumes without saying
• **Implied scope** — what the problem is about, what it's not about
• **Implied category** — is this framed as technical / people / process / etc.?
• **Implied stakeholders** — whose problem is this?
• **Implied time horizon** — immediate, medium, long-term?

This snapshot is passed to reframers as context. The reframers' job is to challenge and shift these.

3. Choose Reframing Lenses

Select 3-6 lenses from the palette based on the problem's shape. The orchestrator decides autonomously.

**Available lenses:**

• **problem-vs-symptom** — is the stated problem a symptom of something upstream?
• **scope-shift** — narrower or wider framing
• **stakeholder-shift** — different stakeholders' perspectives
• **level-of-abstraction** — more general or more specific
• **time-horizon** — 1 week, 6 months, 5 years
• **inversion** — what new problems would emerge if this were solved?
• **category-shift** — is this really a technical / people / process / spec / business / incentive / communication problem?
• **constraints-shift** — which "fixed" constraints are actually negotiable?

**Selection heuristics:**

• Problem described as "we need X" → include stakeholder-shift (is X what different parties need?), category-shift (is "we need X" a technical problem, or a prioritization problem?)
• Problem described as urgent → include time-horizon (different horizons yield different interventions)
• Problem described with a hard constraint → include constraints-shift
• Problem described with a clean story → include problem-vs-symptom (clean stories often hide upstream causes)
• Problem that feels stuck → include inversion and level-of-abstraction (both break out of the current framing)

**Drop lenses that don't fit.** Not every lens applies to every problem. A clearly-factored technical problem may not need category-shift; a personal productivity problem may not need stakeholder-shift. Better 3 fitted lenses than 7 forced ones.

4. Spawn Reframers (Parallel, Isolated)

Spawn one `THK - Reframer` agent per chosen lens, in parallel. Each receives:

• The written problem brief (from step 1)
• Its assigned lens
• The premise snapshot (from step 2)
• Instruction to produce a reframed problem statement with an explicit "what changed" diff and "when this framing applies" note

**No cross-talk between reframers.** NGT principle — independent reframing first, synthesis second. Isolated reframers produce more distinct alternatives; coordinated ones anchor on each other.

Collect all reframings.

5. Synthesize

Combine the isolated reframings into a coherent report:

**5a. Assess meaning-shift per reframing.** For each reframing, judge how much it materially shifts the problem's meaning. A reframing that just restates the problem in different words is not productive. A reframing that would lead to a different intervention is productive. Classify each as:

• **Materially shifts meaning** — adopting this reframe would lead to a meaningfully different solution
• **Refines the framing** — sharpens the original without replacing i