---
name: idea-refine
description: 날것의 아이디어를 확산·수렴 사고로 다듬어 실행 가능한 one-pager로 만든다. 아이디어가 막연하거나 MVP 범위를 좁혀야 하거나 여러 방향 중 무엇을 추진할지 정해야 할 때 트리거한다 — 사용자가 "이거 괜찮을까?", "뭘 먼저 만들지?" 같은 신호를 보낼 때. 요구사항이 이미 구체적이라 바로 spec으로 갈 수 있거나, 버그 수정·한 줄 변경에는 쓰지 않는다. "/idea-refine", "아이디어 정리", "ideate"로도 호출한다.
argument-hint: "idea or feature name"
---

# Idea Refine

날것의 아이디어를 확산·수렴 사고로 다듬어 추진할 만한 one-pager로 만든다.

## Inputs / Outputs

| 입력 | 출력 |
|---|---|
| 사용자의 날것 아이디어 | `artifacts/<feature>/idea.md` |

## Workflow

### Step 1. 확산 (Understand & Expand)

1. **아이디어를 "How Might We" 형식의 명료한 문제 진술로 재진술한다** — 재진술은 틀 자체를 바꾼다. 사용자 말을 paraphrase하는 것이 아니다.

   **HMW 재진술 — 좋은 예 vs 나쁜 예**

   ```
   사용자 발화: "대시보드를 더 빠르게 만들고 싶다"

   좋음:
   HMW — 데이터가 다 적재된 뒤가 아니라, 로드되는 동안에도 사용자가
   의미 있는 답을 얻게 할 수 있을까?
   (틀 변경: 완성본을 빨리 그리는 문제 → 부분 정보를 쓸모 있게 만드는 문제)

   나쁨:
   HMW — 대시보드를 빠르게 만들 수 있을까?
   (문장만 재포장. 해결 방향이 하나도 열리지 않음)
   ```

2. **3-5개의 날카로운 질문을 `AskUserQuestion`으로 던진다** — 사용자가 한 번에 답할 수 있는 분량. 초점: 누구를 위한 것인가, 성공은 어떤 모습인가, 진짜 제약은 무엇인가, 이전에 시도된 것은 무엇인가, 왜 지금인가. 처음 요청에 이미 답이 나왔으면 확인만 한다.

3. **문제의 축을 바꾸는 변형을 만든다** — 솔루션을 다르게 표현하는 게 아니라 문제 자체를 다시 본다. 보통 5-8개.

   자주 쓰는 축 (예시):
   - **반전 (Inversion)**: 정반대로 한다면?
   - **제약 제거 (Constraint removal)**: 예산·시간·기술이 문제가 아니라면?
   - **대상 전환 (Audience shift)**: 다른 사용자를 위한 것이라면?
   - **결합 (Combination)**: 인접한 아이디어와 합친다면?
   - **단순화 (Simplification)**: 10배 단순한 버전이라면?
   - **10x 버전**: 엄청난 규모에서는 어떤 모습일까?
   - **전문가 렌즈 (Expert lens)**: 해당 분야 전문가라면 당연하다고 볼 것은?

   리스트에 없는 축이라도 "문제의 축을 바꾼다"는 기준이면 유효하다.

4. **코드베이스 안이라면** `Glob`·`Grep`·`Read`로 기존 아키텍처·패턴·제약을 훑는다 — 변형은 실제로 존재하는 것에 발을 붙여야 한다.

   선택적으로 참고할 프레임워크:
   - **SCAMPER** — 기존 제품 개선
   - **First Principles** — 점진적 사고에서 벗어날 때
   - **JTBD** — 진짜 문제 이해
   - **Pre-mortem** — Step 2 스트레스 테스트

### Step 2. 수렴 (Evaluate & Converge)

1. **공감된 아이디어를 진짜로 다른 방향들로 묶는다** — 표면적 차이가 아니라 가치·전략 축에서 다른 것끼리.

2. **각 방향을 세 축으로 스트레스 테스트한다:**
   - **User value**: Painkiller인가(급하고, 빈번하고, 사람들이 찾는다) Vitamin인가(있으면 좋지만 행동을 바꾸지 못한다)? 지금의 workaround는 무엇인가?
   - **Feasibility**: 기술적 비용, 필요한 자원, 가치 실현까지의 시간. 가장 어려운 부분은?
   - **Differentiation** (강함 → 약함): 새로운 역량 → 10배 개선 → 새로운 대상 → 새로운 맥락 → 더 나은 UX → 저렴함

3. **숨은 가정을 세 범주로 드러낸다:**
   - **Must Be True** — 틀리면 아이디어를 죽인다. 만들기 전에 검증한다
   - **Should Be True** — 성공에 큰 영향을 미친다. 틀리면 접근을 조정한다
   - **Might Be True** — 부차적. 핵심이 증명될 때까지 검증하지 않는다

   **분류 예시 — 협업 에디터 MVP 가정**:

   - Must Be True: "여러 사용자가 동시에 편집해도 충돌 없이 병합 가능하다" (틀리면 제품이 성립하지 않음)
   - Should Be True: "팀들이 Slack이 아닌 에디터 안에서 직접 대화하고 싶어한다" (틀리면 커뮤니케이션 기능을 축소할지 재고)
   - Might Be True: "모바일 앱이 있어야 채택률이 높다" (웹에서 핵심이 증명될 때까지 검증 미룸)

### Step 3. Sharpen & Ship

`references/idea-template.md` 형식으로 one-pager를 만든다. MVP는 **가장 위험한 가정을 먼저 검증**해야 한다.

사용자에게 `artifacts/<feature>/idea.md`에 저장할지 묻는다. 사용자가 확인했을 때만 저장한다.

저장 후 **다음 단계**는 `/write-spec <feature>`로 외부 관찰 가능한 동작을 spec.md에 확정하는 것이다.

## Principles

- **질문이 진단을 먼저 한다** — 각 질문은 이 문제가 어떤 유형인지 짚어낸다
- **스킬은 의견을 가진다** — 중립적 옵션 나열 대신 방향을 추천한다
- **Step 2는 정직하다** — 낮은 차별성이나 높은 복잡도를 그대로 지적한다. 맞장구치지 않는다.
- **출력은 행동 가능하다** — 생각할 것이 아니라 할 것을 담는다
- **"Not Doing" 리스트가 가장 가치 있다** — 집중은 좋은 아이디어에 No라고 말하는 것이다
- **톤은 직설적이고 사려 깊되 약간 도발적이다**