---
name: what
description: |
  구조화된 사고 프레임워크. Why-What-How-So What 4단계로 근본 목적을 역추적·정립.
  Use when "what 분석", "what 정리", "what 파악", "목적 정리", "왜 하는 건지 정리",
  "의도 분석", "기획 의도", or user prefixes request with "what" in structured thinking context.
  NOT for: "what is X?" simple knowledge questions, "what does X do?" explanations.
user_invocable: true
version: 1.0.0
---

# Why-What-How-So What 구조화된 사고 프레임워크

## Core Principle

사용자가 "A 해줘"라고 말했을 때, 단순히 A를 실행하는 것이 아니라 **"왜 A를 하려는 것인지"**를 역추적하여 진짜 필요한 것을 찾아내고, 그것을 기반으로 작업을 수행한다.

**Iron Law**: 사용자의 Yes 없이는 절대 다음 STEP으로 넘어가지 않는다.

## Announce Pattern

스킬 시작 시 반드시 다음을 출력한다:

> "구조화된 사고 프레임워크를 사용하여 요청의 근본 목적을 정립합니다. Why → What → How → So What 4단계로 진행하며, 각 단계마다 확인을 받겠습니다."

---

## Trigger Rules

### 트리거 (작동)

- `/what` (슬래시 커맨드 직접 호출)
- `"what"` + 동작 동사: "what 분석해줘", "what 정리", "what 파악해줘"
- 한국어 명시적 의도: "목적 정리해줘", "왜 하는 건지 정리", "의도 분석", "기획 의도 잡아줘"
- `"what"`이 요청 앞에 prefix로 붙는 경우: "what 경쟁사 분석 보고서 만들어줘"
- 사용자가 이 스킬을 직접 명시적으로 호출한 경우

### 비트리거 (작동 안 함)

- `"what is X"`, `"what does X do"` (영어 의문사 질문)
- `"what"` 단독 사용
- 코드 내 변수명/문자열에 포함된 `"what"`
- 단순 사전적 지식 질문
- `"what happened"`, `"what went wrong"` 등 상태 질문

---

## Information Pipeline

정보 수집은 환경에 종속되지 않는 우선순위 기반 파이프라인을 따른다.

### Priority 1: 현재 대화 컨텍스트
- 사용자의 현재 입력에서 단서 추출
- 이전 대화 기록이 있으면 관련 맥락 참조

### Priority 2: 프로젝트 내부 파일
- CLAUDE.md, README, package.json 등 프로젝트 메타 파일 탐색
- Glob/Grep으로 관련 코드/문서 검색
- 기존 계획서, 설계 문서, 이슈 목록 등 참조

### Priority 3: 사용 가능한 외부 도구 (있을 때만)
- Notion MCP 연결 시: 관련 문서 탐색
- Greptile 연결 시: 코드 컨텍스트 검색
- 웹 검색 가능 시: 도메인 정보 수집
- **외부 도구가 없어도 스킬은 정상 동작한다** — Priority 1~2로 충분하지 않을 때만 시도

### Priority 4: 사용자 질문
- 위 1~3으로 정보가 부족하면 AskUserQuestion으로 직접 질문
- **추측하지 않고 명시적으로 물어본다**
- 질문은 구체적 선택지 형태로 제시 (열린 질문 최소화)

---

## The Process

### 전체 흐름

```
[Announce] → [STEP 1: Why] → [STEP 2: What] → [STEP 3: How] → [STEP 4: So What] → [실행 방식 선택] → [작업 실행]
```

각 STEP은 **Confirmation Loop**를 반드시 거친다.
진행 중 이전 STEP의 오류를 발견하면 **Backtrack Protocol**을 따른다.

---

### STEP 1: Why (왜 하는가)

**목적**: 사용자의 요청 뒤에 숨은 근본 동기를 파악한다.

**추론 프로세스**:
1. Information Pipeline(Priority 1~4)으로 정보를 수집한다
2. 사용자의 요청에서 **표면적 목적**을 파악한다
3. "이것을 왜 하려는 것인가?"를 반복 질문하여 더 깊은 동기를 추론한다
4. 추론 결과를 **Progressive Table + 자연어 요약**으로 제시한다
5. **Confirmation Loop** 진입

**출력 형식** (STEP 1 완료 시):

| 프레임 | 내용 |
|--------|------|
| **Why** | [추론된 근본 동기] |

> 자연어 요약: "당신이 이 작업을 하려는 이유는 ~입니다."

→ "이 방향이 맞나요?" (Confirmation Loop)

---

### STEP 2: What (무엇을 하는가)

**목적**: 확정된 Why를 기반으로, 구체적으로 달성해야 할 핵심 목표를 정의한다.

**추론 프로세스**:
1. 확정된 Why를 기반으로 실제 산출물/달성 상태를 구체화한다
2. 가능하면 **측정 가능한 형태**로 정의한다
3. Progressive Table로 제시 → Confirmation Loop

**출력 형식** (STEP 2 완료 시):

| 프레임 | 내용 |
|--------|------|
| **Why** | [확정] |
| **What** | [구체적 핵심 목표] |

> 자연어 요약: "근본 이유는 ~이고, 구체적으로 달성할 목표는 ~입니다."

→ Confirmation Loop

---

### STEP 3: How (어떻게 하는가)

**목적**: What을 달성하기 위한 구체적 실행 방법/단계를 설계한다.

**추론 프로세스**:
1. What을 달성하기 위해 필요한 단계를 분해한다
2. 각 단계에서 사용할 도구, 데이터, 리소스를 식별한다
3. 실행 순서와 의존관계를 정리한다
4. Progressive Table로 제시 → Confirmation Loop

**출력 형식** (STEP 3 완료 시):

| 프레임 | 내용 |
|--------|------|
| **Why** | [확정] |
| **What** | [확정] |
| **How** | [실행 단계 요약] |

> 자연어 요약: "~한 이유로, ~을 달성하기 위해, ~한 방법으로 접근합니다."

→ Confirmation Loop

---

### STEP 4: So What (그래서 어떤 의미인가)

**목적**: 이 작업이 완료되었을 때의 기대 가치와 영향을 명확히 한다.

**추론 프로세스**:
1. 이 작업이 완료되면 사용자/조직/프로젝트에 어떤 변화가 생기는지 정의한다
2. **성공 기준**을 명확히 한다
3. Why와의 정합성을 검증한다 (Why의 동기가 So What으로 충족되는지)
4. Progressive Table 전체 완성 → Confirmation Loop

**출력 형식** (STEP 4 완료 시 — 최종):

| 프레임 | 내용 |
|--------|------|
| **Why** | [확정] |
| **What** | [확정] |
| **How** | [확정] |
| **So What** | [기대 가치 + 성공 기준] |

> 자연어 요약: "~한 이유로 ~을 ~한 방법으로 수행하면, ~한 가치를 얻을 수 있습니다."

→ Confirmation Loop

---

## Confirmation Loop

> **프로토콜 참조**: `_core/confirmation-loop.md`

**이 스킬의 훅 오버라이드:**

| 훅 | 값 |
|:--:|-----|
| `PRESENT_FORMAT` | Progressive Table + 자연어 요약 |
| `CONFIRM_OPTIONS` | ["맞습니다 (다음 단계로)", "수정이 필요합니다"] |
| `MODIFY_OPTIONS_BUILDER` | 현재 STEP의 추론 항목별 수정 선택지 |
| `STEP_LABEL` | "STEP N" |

---

## Backtrack Protocol

현재 STEP 진행 중 이전 STEP의 오류를 발견한 경우:

### 프로세스

1. **사용자에게 알림**:
   > "STEP [N]의 [구체적 부분]이 현재 분석과 맞지 않습니다. 수정이 필요합니다."

2. **사용자에게 선택지 제시** (AskUserQuestion):
   - "이전 단계로 돌아가서 수정" → 해당 STEP의 Confirmation Loop 재진입, 이후 STEP 무효화
   - "현재대로 진행" → 기존 확정 내용 유지하고 계속 진행

3. **돌아간 경우**:
   - 해당 STEP부터 순차적으로 재진행
   - 이미 확정된 이후 STEP의 내용은 리셋됨

### 트리거 조건
- How를 설계하다가 What의 범위가 비현실적임을 발견
- So What을 정의하다가 Why의 동기와 불일치 발견
- 사용자가 명시적으로 "이전 단계 수정" 요청

---

## "다시 제시" Keyword Handler

> `_core/confirmation-loop.md`의 "다시 제시" 핸들러를 따르며,
> 선택 후 결과는 Progressive Table 형식으로 재제시한다.

---

## Post-Confirmation Execution

4단계 모두 Yes를 받아 확정되면:

### 1. 최종 요약

전체 4행 표를 한 번 더 출력하고, 자연어 1~3문장으로 요약한다.

### 2. 실행 방식 선택

AskUserQuestion으로 실행 방식을 제시한다:

- **"TodoWrite로 단계별 추적하며 실행"** — How의 각 단계를 TodoWrite 항목으로 변환하여 진행 상황을 추적하며 순차 실행
- **"바로 실행"** — How 계획에 따라 즉시 작업 수행 (빠른 진행)

### 3. 작업 수행

선택에 따라 실행하고, 작업 완료 후:

- So What에서 정의한 **기대 가치**와 실제 결과를 대조한다
- **갭이 있으면**: 구체적으로 무엇이 부족한지 보고하고 추가 작업 여부를 묻는다
- **갭이 없으면**: 완료를 선언하고 성공 기준 충족을 확인한다

---

## When to Stop

**즉시 중단하고 사용자에게 확인하는 상황:**

- 사용자의 요청이 너무 모호하여 Why조차 추론할 수 없을 때
- 정보가 극도로 부족하여 추측에 의존해야 할 때
- 이전 STEP으로 2회 이상 backtrack이 발생했을 때 (근본적 방향 재설정 필요)
- 사용자가 "중단", "스킵", "그냥 해줘" 등을 명시적으로 요청했을 때

**사용자가 프레임워크 중단을 요청한 경우:**
- 즉시 프레임워크를 중단한다
- 그 시점까지 확정된 내용을 간단히 요약한다
- 사용자의 원래 요청을 직접 수행한다

---

## Red Flags

**Never:**
- 사용자의 Yes 없이 다음 STEP으로 넘어가지 않는다
- 정보가 부족할 때 추측으로 STEP을 채우지 않는다
- 4단계를 축약하거나 병합하지 않는다 (경량 모드 없음)
- 사용자의 "수정이 필요합니다" 피드백을 무시하지 않는다

**Don't:**
- Confirmation Loop에서 같은 내용을 단순 반복하지 않는다 (피드백 반영 필수)
- 외부 도구가 없다고 스킬 실행을 거부하지 않는다 (Priority 1~2로 충분)
- Progressive Table에 아직 도달하지 않은 STEP을 "—"으로 채워 넣지 않는다 (해당 STEP까지만 표시)

---

## 복합 시나리오 대응 가이드

### 시나리오 1: 다중 이해관계자 요청

사용자가 "경쟁사 분석 보고서 만들어줘"라고 요청했을 때, 보고서의 최종 소비자가 누구인지에 따라 Why가 달라진다:

- **경영진 보고** → Why: 전략적 의사결정을 위한 시장 포지셔닝 파악
- **영업팀 제공** → Why: 영업 현장에서 차별화 포인트 활용
- **투자자 IR** → Why: 경쟁 우위 입증을 통한 투자 유치

STEP 1에서 소비자를 명확히 확인한 후 각 시나리오에 맞는 What/How를 설계한다.

### 시나리오 2: 기술적 요청에 숨겨진 비즈니스 목적

"API 응답 속도를 50ms 이내로 줄여줘"라는 요청의 Why를 역추적하면:

- 표면: 성능 최적화
- 1단계 역추적: 사용자 경험 개선
- 2단계 역추적: 이탈률 감소 → 매출 증가
- 근본 Why: 서비스 경쟁력 확보를 통한 사업 성장

이 경우 단순 성능 튜닝이 아니라, 사용자 경험 전반의 병목을 찾는 것이 진정한 What이 될 수 있다.

### 시나리오 3: 모호한 요청의 구조화

"좀 더 좋게 만들어줘"처럼 극도로 모호한 요청은:

1. STEP 1에서 "좋다"의 기준을 탐색 (성능? 가독성? 사용성? 매출?)
2. AskUserQuestion으로 구체적 선택지 제시
3. 선택된 기준을 Why로 확정한 후 측정 가능한 What으로 변환

---

## 분석 깊이 조절

### Why 역추적 깊이 기준

Why의 역추적 깊이는 요청의 복잡도에 따라 조절한다:

| 복잡도 | 역추적 단계 | 예시 |
|--------|:----------:|------|
| **단순** | 1단계 | "버그 수정해줘" → Why: 기능 정상화 |
| **보통** | 2단계 | "대시보드 만들어줘" → Why: 데이터 기반 의사결정 지원 |
| **복잡** | 3단계+ | "시스템 리팩토링" → Why: 확장 가능한 아키텍처로 사업 성장 지원 |

### How 상세도 기준

How의 상세도는 실행 범위에 따라 조절한다:

- **실행까지 맡긴 경우**: 구체적 단계 + 도구 + 예상 시간 포함
- **방향만 잡는 경우**: 핵심 접근법 + 대안 비교 수준
- **브레인스토밍 용도**: 다양한 방법론 나열 + 장단점 비교

### 출력 형식 변형

상황에 따라 Progressive Table 외에 다른 형식을 병행할 수 있다:

- **마인드맵 형태**: 복잡한 의존관계가 있는 프로젝트에서 Why-What-How 간 연결 시각화
- **비교표 형태**: 여러 대안을 검토할 때 각 대안별 Why-What-How-So What 비교
- **타임라인 형태**: 단계적 실행이 필요한 장기 프로젝트에서 시간축 기반 How 제시