---
name: ideal
description: 방향은 합의됐는데 "다 되면 어떤 모습인지"가 아직 추상적일 때, 이상적 결과를 구체적 산출물(코드·표·다이어그램·저니맵)로 시뮬레이션한다. "이상적으로는...", "결과물이 어떤 모습이어야", "다 되면 어떻게 생겼을까", "API가 어떻게 보여야", "사용자 경험이 어떨지", "/ideal" 등을 말할 때 사용. 추상적 합의("좋은 걸 만들자")를 "이게 맞나?"를 판단할 수 있는 구체 산출물로 바꾸는 것이 목적이다.
---

## 역할

"다 되면 어떤 모습인가?"에 대한 답이 추상적일 때, 도메인에 맞는 시뮬레이션을 함께 만들어서 구체화한다.

추상적 합의는 위험하다. "좋은 API를 만들자"에 모두가 동의하지만, "좋은"의 의미가 각자 다르다. 이 스킬은 구체적 산출물을 먼저 만들어서 "이게 맞나?"를 판단할 수 있게 한다. README-driven development, consumer-first API design, journey mapping 등의 기법을 상황에 맞게 적용한다.

## Step 1: 도메인 감지

사용자의 맥락에서 도메인을 판별한다:

| 도메인 | 시그널 | 시뮬레이션 도구 |
|--------|--------|----------------|
| **개발** | hook, API, SDK, 컴포넌트, 함수 | Code Usage 시뮬레이션 |
| **경험** | 사용자 흐름, 온보딩, 워크플로우 | 저니맵 |
| **설계** | 아키텍처, 모듈, 레이어, 의존성 | Mermaid 다이어그램 |
| **데이터** | 스키마, 타입, 필드, 모델 | 스키마 네이밍 + 샘플 데이터 |

도메인이 겹치면 (예: "SDK의 사용자 경험") 주 도메인 하나를 선택하고, 나머지는 보조로 활용한다. 판단이 모호하면 사용자에게 확인한다.

## Step 2: 시뮬레이션 실행

### 개발: Code Usage 시뮬레이션

**핵심 원칙: 구현이 아니라 소비를 먼저 쓴다.**

사용자가 만들려는 것을 "쓰는 쪽"의 코드를 먼저 작성한다. 내부 구현이 아니라, 완성된 후 소비자가 작성할 코드의 모습을 상상한다.

```
1. 가장 흔한 사용 시나리오의 코드를 작성한다
2. "이 코드가 자연스러운가?" 판단한다
3. 엣지 케이스 시나리오 1~2개를 추가한다
4. 시나리오들에서 API 시그니처를 역추출한다
```

**예시:**
```typescript
// ❌ 구현부터 생각하기
function useTreeView(options: TreeViewOptions) { ... }

// ✅ 사용부터 생각하기
// 시나리오 1: 파일 탐색기
const tree = useTreeView(fileData)
return <nav {...tree.containerProps}>
  {tree.items.map(item => <div {...item.props}>{item.label}</div>)}
</nav>

// 시나리오 2: 설정 메뉴 (깊이 제한)
const menu = useTreeView(settingsData, { maxDepth: 2 })

// → 역추출된 API: useTreeView(data, options?) → { containerProps, items }
```

작성한 usage 코드를 사용자에게 보여주고 "이 코드를 쓰고 싶은가?" 확인한다. 자연스럽지 않은 부분이 있으면 그게 곧 설계의 갭이다.

### 경험: 저니맵

사용자의 경험을 시간 순서대로 시뮬레이션한다.

```markdown
| 단계 | 행동 | 생각/감정 | 터치포인트 | 문제점 |
|------|------|----------|-----------|--------|
| 1. 진입 | ... | ... | ... | ... |
| 2. 탐색 | ... | ... | ... | ... |
| 3. 핵심 행동 | ... | ... | ... | ... |
| 4. 완료 | ... | ... | ... | ... |
```

빈 표를 먼저 만들고, 단계를 사용자와 함께 채운다. "이 단계에서 사용자가 뭘 느끼는가?"가 핵심 질문이다.

### 설계: Mermaid 다이어그램

모듈 관계를 시각화한다.

```
1. 핵심 모듈 3~5개를 식별한다
2. 모듈 간 의존성/데이터 흐름을 Mermaid로 그린다
3. "이 화살표가 맞는가?" 확인한다
4. 빠진 모듈이나 잘못된 의존성을 발견한다
```

다이어그램은 **현재 상태**가 아니라 **이상적 상태**를 그린다. 현재 상태와의 차이가 곧 할 일 목록이 된다.

### 데이터: 스키마 네이밍 + 샘플 데이터

타입/스키마의 필드명과 구조를 구체화한다. 네이밍이 곧 설계이므로, 이름을 먼저 정하면 구조가 따라온다.

```
1. 핵심 타입의 필드를 나열한다 (이름 + 타입)
2. 샘플 데이터 2~3행을 채운다
3. "이 필드명이 자연스러운가?" 판단한다
4. 필드명에서 누락된 개념이나 중복을 발견한다
```

**예시:**
```typescript
// 필드명 초안
type Section = {
  id: string
  title: string
  items: Item[]
  layout: 'grid' | 'list'  // ← 이 필드명이 맞나?
}

// 샘플 데이터로 검증
const sample: Section = {
  id: 'hero',
  title: '메인 배너',
  items: [{ ... }],
  layout: 'grid'  // ← "grid"가 레이아웃인가 표시 방식인가?
}
// → "layout"보다 "display"? "variant"? 네이밍 논의 시작점
```

샘플 데이터를 채우면 추상적이던 스키마에서 어색한 이름, 빠진 필드, 불필요한 필드가 드러난다.

## Step 3: 갭 발견

시뮬레이션 결과에서 자연스럽게 갭이 드러난다:

- **개발**: "이 usage가 되려면 내부에 X가 필요한데, 지금은 없다"
- **경험**: "3단계에서 사용자가 막히는데, 안내가 없다"
- **설계**: "A→B 화살표가 있는데, 실제로는 C를 거쳐야 한다"
- **데이터**: "이 필드명이 어색하다" 또는 "이 타입에 X 필드가 빠졌다"

발견된 갭을 정리하여 사용자에게 보여준다.

## Step 4: 완료 판정

다음 조건을 모두 만족하면 완료:

1. **구체적 산출물이 존재한다** — 코드, 표, 다이어그램 중 하나 이상
2. **사용자가 "이거다" 또는 "이 방향이다"라고 확인했다**
3. **갭이 식별되었다** — 이상과 현실의 차이가 명시적

완료되면 산출물과 발견된 갭을 요약하여 제시한다. 결과는 이후 설계·명세·구현 단계의 입력으로 쓰일 수 있다.

## 매 턴 출력 형식

```markdown
## 시뮬레이션: [도메인]

[산출물 — 코드/표/다이어그램]

### 발견된 갭
- 갭 1: ...
- 갭 2: ...

### 질문
제 판단: [판단]. 이유: [근거].
[구체화 질문]
```

## 산출물 활용

- **구체 산출물(코드·표·다이어그램·저니맵)** — "이게 맞나?" 판정 기준
- **발견된 갭** — 이후 설계 과제 또는 제약 조건으로 이어짐

## 호출 경로

- **단독 호출** — `/ideal` 또는 "이상적으로는…", "다 되면 어떤 모습" 같은 신호로 바로 진입
- **`/discuss` 드릴다운** — 상위 논의에서 "이상적 결과" 요소가 막힐 때(이해도 낮음) 이 스킬로 드릴다운하여 구체 산출물을 만들고, 결과·갭을 상위 논의의 해당 요소에 반영하여 복귀