rethink-unblock

# Rethink — Structured Reframing for Technical Problems

When you're stuck on a technical problem, apply two of the four frameworks below to generate alternative approaches. The goal is to break fixed thinking patterns and surface options you haven't considered.

## Triggers

Use this skill when:
- An approach has failed 2+ times
- You're going in circles on a design decision
- The "obvious" solution feels wrong or overly complex
- You need to evaluate fundamentally different architectures
- Debugging has stalled and root cause is unclear

## Process

### Step 1: State the Problem Clearly

Write one sentence describing what you're trying to achieve and what's blocking you.

```
Problem: [What I want to achieve]
Blocker: [What's preventing it]
Attempts so far: [What I've already tried]
```

### Step 2: Select Two Frameworks

Choose the two most relevant frameworks from below and apply them to the problem.

### Step 3: Generate Alternatives

Produce 3-5 concrete, actionable alternative approaches. Each must include:
- **Approach**: One-sentence description
- **Mechanism**: How it solves the blocker
- **Trade-off**: What you give up
- **First step**: The immediate next action to try

---

## Framework 1: Problem Redefinition (관점 전환)

Rotate the problem to see it from a different angle.

**Techniques:**
- **Invert** (180°): What if the opposite is the real problem? ("Can't make it fast" → "Why does it need to be fast?")
- **Zoom out** (10x): What problem does THIS problem live inside? Is there a higher-level solution?
- **Zoom in** (0.1x): Which specific sub-part is actually broken? Isolate the exact failure point.
- **Domain shift**: How would a different field solve this? (Database problem → think like a filesystem. UI problem → think like a CLI.)
- **Time shift**: How would this be solved if performance/storage/bandwidth were unlimited? What if it had to work on a 1990s machine?

**Output**: Restate the problem in at least two alternative formulations before generating solutions.

---

## Framework 2: Cross-Domain Connection (연결 탐색)

Find solutions by connecting to patterns from other domains.

**Process:**
1. **Direct analogy**: What existing system solves a structurally similar problem? (e.g., event sourcing ↔ git history, circuit breaker ↔ electrical fuse)
2. **Inverse pattern**: What's the opposite architectural pattern, and would it work here? (polling ↔ push, monolith ↔ microservice, eager ↔ lazy)
3. **Borrow from stdlib/ecosystem**: Is there a well-tested library or language feature that handles this class of problem? Don't reinvent.
4. **Prior art search**: Has this exact problem been solved in another project, language, or framework? Search before building.

**Output**: Name the analogous system/pattern and explain how the mapping works.

---

## Framework 3: Complexity Decomposition (복잡성 분해)

Break a complex problem into independently solvable parts.

**Process:**
1. **List components**: What are the 3-5 distinct sub-problems?
2. **Map dependencies**: Which parts depend on which? Draw the DAG.
3. **Find the leverage point**: Which single sub-problem, if solved, unblocks the most others?
4. **Isolate the hard part**: Separate the genuinely hard sub-problem from the boilerplate. Solve the hard part first in isolation.
5. **Sequence**: Determine the order — solve independent parts in parallel, dependent parts in sequence.

**Output**: A numbered list of sub-problems with their dependency relationships and a suggested solve order.

---

## Framework 4: Multi-Dimensional Analysis (다차원 분석)

Analyze the problem across multiple dimensions to find the real constraint.

**Dimensions to evaluate:**
- **Time**: Is this a build-time, deploy-time, or runtime problem? Can you shift when the work happens?
- **Layer**: Is the problem in the data model, business logic, API boundary, or presentation? Are you solving it at the right layer?
- **Scope**: Is this a local fix, a module-level redesign, or a system architecture issue? Are you at the right scope?
- **Constraint**: What's the actual bottleneck — correctness, performance, maintainability, or compatibility? Are you optimizing the right thing?
- **Lifecycle**: Is this a one-time migration, a growing problem, or a steady-state concern? Does the solution need to scale?

**Output**: Identify which dimension reveals the real constraint, and propose solutions that address that specific dimension.

---

## Output Format

```
## Rethink: [Problem Title]

**Problem**: [one sentence]
**Blocker**: [one sentence]
**Attempts**: [what was tried]

### Frameworks Applied: [Name 1] + [Name 2]

#### [Framework 1 Name] Analysis
[Framework-specific analysis, 3-5 sentences]

#### [Framework 2 Name] Analysis
[Framework-specific analysis, 3-5 sentences]

### Alternative Approaches

1. **[Approach name]**
   - Mechanism: [how it solves the blocker]
   - Trade-off: [what you give up]
   - First step: [immediate next action]

2. **[Approach name]**
   - Mechanism: ...
   - Trade-off: ...
   - First step: ...

3. **[Approach name]**
   - Mechanism: ...
   - Trade-off: ...
   - First step: ...

### Recommendation
[Which approach to try first and why, 1-2 sentences]
```

## Anti-Patterns

- Generating vague or generic advice ("try a different approach") — every alternative must be concrete and actionable
- Analysis paralysis — limit to 3-5 alternatives, pick one, and try it
- Reframing without action — the output must include a "first step" for each alternative
- Using this skill as procrastination — if the problem is clear and the solution is obvious, just do it