---
name: ouroboros
version: 1.0.0
description: >-
  꼬리를 무는 심층 문서 생산 스킬. 모호한 아이디어를 3단계(요구사항→설계→검증)로 처리하며
  각 단계에서 메트릭 기반 품질 게이트(모호성 ≤ 20%)를 통과할 때까지 반복 심화한다.
  Trigger on "ouroboros", "우로보로스", "꼬리를 물고", "심층 문서", "deep spec",
  "깊이있는 스펙", "요구사항부터 검증까지", "3단계 문서", "품질 게이트 문서".
  PRD만 필요하면 clarify/vague, 설계+검증까지 메트릭 기반으로 필요하면 ouroboros.
allowed-tools:
  - AskUserQuestion
  - Read
  - Glob
  - Grep
  - Write
  - Agent
---

# Ouroboros: 꼬리를 무는 심층 문서 생산

모호한 아이디어를 입력받아 **3단계 파이프라인**으로 처리한다. 각 단계에서 **메트릭 기반 품질 게이트**를 통과할 때까지 반복 심화하여, 깊이 있는 문서 세트를 생산한다.

```
Phase 1: 요구사항 심화          Phase 2: 설계 심화              Phase 3: 검증 심화
┌─────────────────────┐    ┌───────────────────────────┐    ┌──────────────────────┐
│ 질문 → 답변 → 점수  │    │ 질문 → 답변 → 점수        │    │ 질문 → 답변 → 점수   │
│ 모호성 ≤ 20%까지    │───→│ 모호성 ≤ 20%까지          │───→│ 모호성 ≤ 20%까지     │
│ 반복                │    │ 반복                      │    │ 반복                 │
│ Gate: 품질 게이트   │    │ Gate: 품질 게이트         │    │ Gate: 품질 게이트    │
└─────────────────────┘    └───────────────────────────┘    └──────────────────────┘
Output: 01-requirements.md  Output: 02-design.md            Output: 03-verification.md
```

> **핵심 철학**: "어떻게 만들 것인가"와 "왜 이렇게 만드는가"를 **저수준까지** 깊이 있게 다룬다. 모호성을 수치로 추적하고, 문턱값 이하가 될 때까지 반복한다.

---

## 사용 경계

Ouroboros는 깊은 계획이 실제 실패 비용을 줄일 때만 사용한다. 아래에 해당하면 이 스킬로 들어가지 말고 직접 구현, `/vague`, `/tdd`, 또는 기존 계획 보강으로 라우팅한다.

| 사용하지 않을 때 | 대안 |
|------------------|------|
| 단일 파일 또는 단일 문구 수정 | 직접 수정 후 집중 검증 |
| 원인과 수정 범위가 이미 확정된 버그 | `/tdd` 또는 바로 회귀 테스트 + 수정 |
| 30분 안에 끝날 작은 UI 조정 | 직접 구현, 필요 시 짧은 가정 1줄 |
| 사용자가 "바로 고쳐"처럼 즉시 실행을 명시한 운영 이슈 | 진단 후 즉시 수정 |
| 산출물이 구현이나 검증으로 이어지지 않을 문서 작업 | 일반 문서 정리 |

권장 사용처는 권한, 인증, DB/마이그레이션, cross-service sync, 삭제 정책, 대규모 리팩터링처럼 요구사항·설계·검증이 분리되지 않으면 회귀가 큰 작업이다.

---

## 절대 원칙

1. **한 번에 한 질문만.** 모든 질문은 호스트가 제공하는 사용자 질문 도구로, 가설 기반 옵션을 제시한다. 열린 질문 금지.
2. **코드베이스 팩트는 먼저 탐색.** 호스트의 탐색 도구, sub-agent, 또는 직접 `rg`/파일 읽기로 사실을 파악한 후 질문한다. 사용자에게 코드가 이미 알려주는 것을 묻지 않는다.
3. **매 라운드 후 점수 보고.** 차원별 점수와 모호성 %를 투명하게 표시한다.
4. **문턱값 통과 전 다음 Phase 금지.** 모호성이 20% 이하가 되어야만 다음 Phase로 진행한다.
5. **각 Phase 완료 시 즉시 중간 저장.** `docs/ouroboros/{date}-{slug}/`에 저장하여 세션 중단에 대비한다.
6. **아리까리한 결정은 그 자리에서 결론.** "나중에"로 넘기지 않는다.

---

## 호스트 도구 어댑터

이 스킬은 Claude Code, Codex 등 여러 호스트에서 실행될 수 있다. 아래 매핑을 적용하되, 항상 현재 호스트의 상위 도구 정책을 우선한다.

| 의도 | Claude Code | Codex/기타 호스트 |
|------|-------------|-------------------|
| 사용자 선택 질문 | `AskUserQuestion` | `request_user_input`이 가능하면 사용. 불가능하면 답하기 쉬운 단일 선택 질문을 일반 메시지로 제시 |
| 코드베이스 탐색 | `Agent(explore)` 또는 `Grep`/`Read` | sub-agent 사용이 허용될 때만 explorer 사용. 아니면 `rg`, `rg --files`, 파일 읽기로 직접 탐색 |
| 모델 지정 | `sonnet`/`opus`를 힌트로 사용 가능 | 특정 모델명을 강제하지 않는다. 현재 호스트의 기본 모델과 reasoning 설정을 따른다 |
| 파일 저장 | `Write` | 가능하면 작은 diff 또는 기존 파일 수정 도구를 사용하고, 저장 위치는 동일하게 유지 |

질문 옵션 형식:
- 추천 옵션을 첫 번째로 둔다.
- 2-4개 선택지만 제시한다.
- 각 선택지는 선택 시 tradeoff를 한 문장으로 설명한다.
- 자유 입력이 필요하면 마지막에 "직접 지정"을 허용하되, 먼저 안전한 기본 선택지를 제안한다.

---

## 진입 판단

### 1. Greenfield vs Brownfield 감지

호스트의 탐색 도구 또는 직접 `rg`/파일 읽기로 cwd를 탐색하여 판단:
- 소스코드 존재 + 사용자 아이디어가 기존 코드 수정/확장 참조 → **brownfield**
- 그 외 → **greenfield**

Brownfield인 경우 관련 코드 영역을 미리 파악하여 `codebase_context`로 보관한다.

### 2. 기존 문서 감지

프로젝트 전체에서 기존 문서를 탐색한다:
1. Glob으로 프로젝트 내 `**/*.md` 파일을 스캔
2. PRD, 요구사항, 설계 문서 등 관련 문서를 식별 (`docs/prd/`, `docs/`, 프로젝트 루트 등 경로 무관)
3. 발견된 문서를 Read로 읽어 내용을 분석

- **관련 문서 발견**: 사용자 질문 도구로 "기존 문서를 발견했습니다: {파일 목록}. 이 문서를 기반으로 Phase 1을 건너뛰거나 보강할까요?" 제안
- **관련 문서 없음**: Phase 1부터 시작

### 3. Phase 재진입

`docs/ouroboros/{date}-{slug}/` 에 중간 저장 파일이 있으면:
- `01-requirements.md` 존재 → Phase 2부터 재개
- `01-requirements.md` + `02-design.md` 존재 → Phase 3부터 재개
- 사용자 질문 도구로 재개 여부 확인

### 4. 시작 안내

```
Ouroboros를 시작합니다. 모호한 아이디어를 3단계로 심화하여 깊이 있는 문서를 생산합니다.

**아이디어:** "{입력}"
**프로젝트 유형:** {greenfield|brownfield}
**시작 Phase:** {1|2|3}
**문턱값:** 모호성 ≤ 20%

각 단계에서 질문 후 점수를 보여드리고, 통과하면 다음 단계로 넘어갑니다.
```

---

## 품질 게이트 공식 (모든 Phase 공통)

### 모호성 계산

```
Ambiguity = 1 - Σ(score_i × weight_i)
```

- `score_i`: 각 차원 0.0~1.0 (에이전트 자기평가, 6단계 이산화 권장: 0.0/0.3/0.5/0.7/0.9/1.0)
- `weight_i`: Phase별 가중치 (아래 각 Phase에서 정의)
- **게이트 통과**: Ambiguity ≤ 0.20 (20%)
- **게이트 실패**: 최저 점수 차원 식별 → 해당 차원에 타겟된 질문 생성

점수 평가 시 `references/scoring-dimensions.md`의 점수대별 기준을 참조하여 일관성을 유지한다.

### 라운드 보고 형식

매 라운드 후 반드시 아래 형식으로 보고:

```
Round {n} | 타겟: {약한 차원} | 모호성: {X}%

| 차원 | 점수 | 가중치 | 가중점수 | 갭 |
|------|------|--------|----------|-----|
| {차원1} | {s} | {w} | {s×w} | {갭 또는 "Clear"} |
| {차원2} | {s} | {w} | {s×w} | {갭 또는 "Clear"} |
| ... | ... | ... | ... | ... |
| **모호성** | | | **{X}%** | |

{X ≤ 20 ? "품질 게이트 통과! 다음 Phase로 진행합니다." : "다음 질문 타겟: {최약 차원}"}
```

### 라운드 프리셋과 반복 제한

사용자가 명시하지 않으면 **standard**를 기본값으로 사용한다. 기존 PRD/설계 문서가 충분하거나 범위가 작은 경우에는 lite를 제안하고, 보안/권한/DB/아키텍처처럼 리스크가 큰 작업에는 deep을 제안한다.

| 프리셋 | 용도 | Phase당 최소 | Phase당 최대 | 경고 시점 |
|--------|------|--------------|--------------|-----------|
| lite | 기존 문서 보강, 작은 기능, 단일 화면/API | 1라운드 | 6라운드 | 5라운드 |
| standard | 기본 심화 문서 | 2라운드 | 12라운드 | 9라운드 |
| deep | 고위험 정책, 권한, DB, 아키텍처 변경 | 3라운드 | 30라운드 | 20라운드 |

- **최소 라운드 필수** — 모든 차원 0.9+이더라도 선택한 프리셋의 최소 라운드는 진행하여 숨겨진 가정을 검증한다.
- **경고 시점**: 사용자 질문 도구로 "현재 {n}라운드 도달. 모호성: {X}%. 계속/진행 선택"을 제시한다.
- **최대 라운드**: 프리셋 상한 도달 시 현재 점수로 강제 진행하고 미해결 갭을 명시한다.
- **조기 종료**: 최소 라운드 이후 사용자가 "enough"/"다음"/"넘어가자"라고 하면 허용한다. 현재 점수 + 미해결 갭을 경고로 표시한다.
- **모든 차원 0.9+**: 최소 라운드 경과 후 즉시 게이트 통과.

### Challenge Agent 모드

특정 조건에서 질문 관점을 전환하여 돌파구를 찾는다. 각 모드는 **Phase당 최대 3회** 사용 가능. sub-agent 사용이 허용되는 호스트에서는 별도 에이전트를 스폰하고, 그렇지 않으면 현재 에이전트가 해당 관점을 명시적으로 전환한다.

| 모드 | 활성 조건 | 목적 | 질문 프롬프트 |
|------|-----------|------|--------------|
| Contrarian | Phase 내 4라운드+ | 핵심 가정 도전 | "지금까지의 가정 중 반대가 참이라면? 이 제약이 실제로는 존재하지 않는다면?" |
| Simplifier | Phase 내 6라운드+ | 복잡도 제거 | "가장 단순한 버전은? 이 제약들 중 실제로 필요한 것과 가정일 뿐인 것은?" |
| Ontologist | Phase 내 8라운드+ AND 모호성 > 30% | 본질 재발견 | "이것은 정말 무엇인가? 핵심 개념은 어떤 것이고 부수적인 것은?" |

**자동 활성화 트리거**: 3라운드 연속 모호성 변동 ±5% 이내(정체)이면 다음 미사용 Challenge 모드를 자동 활성화.

---

## Phase 1: 요구사항 심화

### 목적
모호한 아이디어에서 명확한 요구사항을 추출한다. "무엇을 만드는가?"를 수정처럼 맑게 한다.

### 프로젝트 고유 인테이크 반영

프로젝트의 `AGENTS.md`, `CLAUDE.md`, `docs/` 지침에 요구사항 인테이크 슬롯, cold review, 보안/권한 체크리스트 같은 고유 규칙이 있으면 Phase 1 산출물에 그대로 통합한다.

- 사용자에게 묻기 전에 저장소 지침에서 이미 요구하는 슬롯을 확인한다.
- 슬롯이 비어 있으면 추측으로 채우지 않고 `TBD` 또는 `미확인`으로 남기고 질문한다.
- 영구 문서화 직전에는 "사용자 첫 요청의 주체·범위·제외 조건과 일치하는가"를 점검하는 좁은 cold review를 1회 수행한다.

### 평가 차원

**Greenfield:**

| 차원 | 가중치 | 설명 |
|------|--------|------|
| Goal Clarity | 40% | 목표가 한 문장으로 명확한가. 핵심 엔티티와 행동을 모호함 없이 진술 가능한가 |
| Constraint Clarity | 30% | 경계, 제한, 비목표가 명확한가. "하지 않을 것"이 정의되었는가 |
| Success Criteria | 30% | 테스트 가능한 완료 기준이 있는가. 자동화 가능한 수용 기준인가 |

**Brownfield (Context Clarity 추가):**

| 차원 | 가중치 | 설명 |
|------|--------|------|
| Goal Clarity | 35% | (위와 동일) |
| Constraint Clarity | 25% | (위와 동일) |
| Success Criteria | 25% | (위와 동일) |
| Context Clarity | 15% | 기존 시스템의 관련 모듈, 패턴, 의존성을 충분히 이해하고 있는가 |

### 프로토콜

1. 사용자의 아이디어를 그대로 기록
2. 가장 낮은 점수의 차원을 타겟으로 질문 생성
3. 사용자 질문 도구로 가설 기반 옵션 제시 (2-4개 옵션)
4. 답변 수신 후 모든 차원 점수 재평가
5. 라운드 보고 출력
6. 게이트 통과까지 반복

### 산출물

`docs/ouroboros/{date}-{slug}/01-requirements.md` 에 저장. 템플릿은 `references/document-templates.md` 참조.

포함 섹션:
- 목표 (Goal)
- 제약조건 (Constraints)
- 비목표 (Non-Goals)
- 수용 기준 (Acceptance Criteria)
- 노출된 가정과 해결 (Assumptions)
- 핵심 엔티티 (Ontology)
- 명확도 추이 (라운드별 점수 기록)

---

## Phase 2: 설계 심화

### 목적
Phase 1 요구사항을 기반으로 "어떻게 만들 것인가"와 "왜 이렇게 만드는가"를 **저수준까지** 구체화한다.

### 입력
Phase 1 요구사항 문서, 기존 PRD 문서(`docs/prd/`), 또는 프로젝트 내 관련 md 문서들. 진입 판단에서 감지된 모든 관련 문서를 입력으로 활용한다.

### Brownfield 코드베이스 탐색
Phase 2 시작 시 호스트의 탐색 도구 또는 직접 `rg`/파일 읽기로 관련 코드 영역을 깊이 있게 탐색:
- 기존 프로젝트 구조와 디렉토리 컨벤션
- 유사 기능의 기존 구현 패턴
- 재사용 가능한 모듈/함수
- Config 구조, 타입 정의 패턴

탐색 결과를 Phase 2 질문에 반영한다. 사용자에게 코드가 이미 알려주는 것을 묻지 않는다.

### 평가 차원

| 차원 | 가중치 | 설명 |
|------|--------|------|
| Architecture Clarity | 30% | 시스템 구조와 컴포넌트 관계가 명확한가. 다이어그램 수준으로 표현 가능한가 |
| Decision Rationale | 35% | **가장 중요.** "왜 이렇게 만드는가"가 충분히 설명되었는가. 모든 기술 결정에 대안 비교와 선택 근거가 있는가 |
| Implementation Detail | 20% | "어떻게 만들 것인가"가 파일/함수 수준까지 구체적인가 |
| Risk Coverage | 15% | 엣지케이스, 보안, 실패 시나리오가 식별되었는가 |

### 프로토콜

1. Phase 1 요구사항 문서를 읽고 설계 방향 초안 구성
2. (Brownfield) 코드베이스 탐색 실행
3. 가장 낮은 점수의 차원을 타겟으로 질문 생성
4. 사용자 질문 도구로 가설 기반 옵션 제시
5. 답변 수신 후 모든 차원 점수 재평가
6. 라운드 보고 출력
7. 게이트 통과까지 반복

### 시각화

설계 문서의 시스템 다이어그램이 필요할 때 02-design.md 안에 Mermaid 또는 ASCII 다이어그램으로 직접 작성한다. 별도 HTML 파일을 생성하지 않는다.

### 산출물

`docs/ouroboros/{date}-{slug}/02-design.md` 에 저장.

포함 섹션:
- ADR (Architecture Decision Records) — 기술 선택과 그 이유
- 기술 스펙 (API/DB/컴포넌트 스펙)
- 시스템 다이어그램 (Mermaid 또는 ASCII, md 안에 인라인)
- 파일별 구현 계획 (생성/수정 파일, 각 파일의 역할, 주요 함수)
- 엣지케이스 목록
- 보안 고려사항
- 명확도 추이

---

## Phase 3: 검증 심화

### 목적
Phase 1 요구사항과 Phase 2 설계를 기반으로 "이게 제대로 동작하는지 어떻게 확인하는가"를 구체화한다. 

### 입력
Phase 1 요구사항 + Phase 2 설계 문서

### 평가 차원

| 차원 | 가중치 | 설명 |
|------|--------|------|
| Scenario Coverage | 35% | 주요 사용자 시나리오(해피패스+대안경로)가 모두 커버되는가 |
| Edge Case Coverage | 30% | 경계값, 에러, 동시성, 보안 엣지케이스가 충분히 테스트되는가 |
| Criteria Specificity | 35% | 성공/실패 판정 기준이 구체적이고 자동화 가능한가. 모호한 기준 없는가 |

### 프로토콜

1. Phase 1 요구사항 + Phase 2 설계 문서를 읽고 검증 계획 초안 구성
2. 가장 낮은 점수의 차원을 타겟으로 질문 생성
3. 사용자 질문 도구로 가설 기반 옵션 제시
4. 답변 수신 후 모든 차원 점수 재평가
5. 라운드 보고 출력
6. 게이트 통과까지 반복

### 프로토콜 상세

Phase 3의 핵심은 **"사람이 손대지 않고 자동으로 검증할 수 있는 수준"**의 문서를 만드는 것이다. 모든 시나리오는 입력→행동→기대결과가 명확하여, 구현 실행 스킬(ouroboros-run)이나 검증 도구(live-verify)가 문서만 보고 자율적으로 실행할 수 있어야 한다.

1. Phase 1 요구사항 + Phase 2 설계 문서를 읽고 **모든 사용자 시나리오를 식별**
2. 각 시나리오를 **스텝 바이 스텝으로 분해** — 매 스텝마다:
   - **전제 조건**: 시스템/사용자 상태
   - **행동**: 사용자가 무엇을 하는가 (클릭, 입력, API 호출 등)
   - **기대 결과**: 시스템이 어떻게 반응해야 하는가 (구체적 값, 상태 변화, UI 변화)
   - **검증 방법**: 어떤 도구로 확인하는가 (Playwright selector, curl 응답 코드, DB 쿼리 등)
3. **예외/에러 경로를 시나리오 단위로 작성** — "정상 동작"만이 아니라:
   - 네트워크 끊김 시 동작
   - 잘못된 입력 시 에러 메시지
   - 권한 없는 접근 시 거부 동작
   - 동시 접근 시 충돌 처리
   - 타임아웃 발생 시 복구 동작
4. **보안 공격 시나리오를 구체적으로 작성**:
   - SQL 인젝션, XSS 시도 → 기대: 입력이 이스케이프되거나 차단
   - 권한 우회 시도 (다른 사용자 리소스 접근) → 기대: 403/401 반환
   - 대량 요청 (rate limiting) → 기대: 429 반환 또는 큐잉
5. **성능 기준을 수치로 정의**:
   - 응답 시간: "p99 < {N}ms"
   - 처리량: "{N} requests/sec"
   - 메모리: "peak < {N}MB"
6. **자동화 가능성 검증** — 모든 시나리오에 대해:
   - 이 시나리오를 Playwright/curl/Bash로 자동 실행할 수 있는가?
   - 성공/실패를 프로그래밍적으로 판별할 수 있는가?
   - "사람이 눈으로 확인해야 하는" 기준이 있다면 → 자동화 가능한 기준으로 변환

### 질문 전략

Phase 3에서는 특히 다음을 집중적으로 질문한다:

- **"이 시나리오의 성공을 어떻게 자동으로 판별하나요?"** — 모호한 기준("잘 동작한다")을 구체적 기준("200 OK + body에 {key} 포함")으로 변환
- **"이 상황에서 시스템은 정확히 어떻게 반응해야 하나요?"** — 에러 메시지 텍스트, HTTP 상태 코드, UI 상태까지 구체화
- **"이 기능을 악용할 수 있는 방법은?"** — 보안 시나리오 도출
- **"이 시나리오를 코드로 테스트한다면 어떤 assert를 쓰나요?"** — 검증 기준의 자동화 가능성 확보

### 산출물

`docs/ouroboros/{date}-{slug}/03-verification.md` 에 저장.

포함 섹션:

#### 1. E2E 시나리오 (사용자 여정별)
각 시나리오에 반드시 포함:
- 시나리오 이름과 설명
- 전제 조건 (시스템 상태, 사용자 상태, 데이터 상태)
- 스텝 바이 스텝 (행동 → 기대 결과, 매 스텝)
- 성공 판정 기준 (자동화 가능, 구체적 값)
- 검증 도구 (Playwright/curl/Bash)

#### 2. 예외/에러 시나리오
각 정상 시나리오에 대응하는 예외 경로:
- 입력 오류 시나리오 (빈 값, 초과 길이, 특수문자, 타입 불일치)
- 네트워크/인프라 오류 시나리오 (타임아웃, 연결 끊김, 서버 다운)
- 상태 충돌 시나리오 (동시 수정, 이미 삭제된 리소스 접근, 세션 만료)
- 각 시나리오의 기대 동작 (에러 메시지, 상태 코드, 복구 행동)

#### 3. 보안 검증 시나리오
- 인젝션 공격 (SQL, XSS, Command) + 기대 방어
- 인증/인가 우회 시도 + 기대 거부
- 데이터 노출 시도 (다른 사용자 데이터) + 기대 차단
- 남용 시나리오 (대량 요청, 스팸) + 기대 제한

#### 4. 성능 기준
- 응답 시간 목표 (p50, p99)
- 처리량 목표 (requests/sec)
- 리소스 제한 (메모리, CPU, 디스크)
- 부하 테스트 시나리오 (동시 사용자 수, 데이터 크기)

#### 5. 자동화 실행 계획
- 각 시나리오를 어떤 도구로 자동 실행할지
- 검증 스크립트의 입력/출력 포맷
- CI/CD 통합 방안 (해당 시)
- live-verify 스킬과의 연계 방법

#### 6. 성공/실패 판정 매트릭스
| 카테고리 | 전체 통과 | 부분 통과 | 실패 |
|---------|-----------|-----------|------|
| E2E | 모든 시나리오 pass | 핵심 pass, 부가 fail | 핵심 1개+ fail |
| 예외처리 | 모든 에러 정상 처리 | 80%+ 정상 처리 | 핵심 에러 미처리 |
| 보안 | 모든 공격 방어 | — | 1개+ 취약점 |
| 성능 | 모든 기준 충족 | p50 충족, p99 미달 | p50 미달 |

#### 7. 명확도 추이
라운드별 점수 기록

---

## 최종 산출물

3개 문서 세트:
1. `docs/ouroboros/{date}-{slug}/01-requirements.md`
2. `docs/ouroboros/{date}-{slug}/02-design.md`
3. `docs/ouroboros/{date}-{slug}/03-verification.md`

완료 후 안내:

> **"Ouroboros 문서 세트가 완성되었습니다.**
>
> - 요구사항: `docs/ouroboros/{date}-{slug}/01-requirements.md`
> - 설계: `docs/ouroboros/{date}-{slug}/02-design.md`
> - 검증: `docs/ouroboros/{date}-{slug}/03-verification.md`
>
> **이제 `/ouroboros-run`을 실행하여 구현을 시작할 수 있습니다.** 위 문서 디렉토리를 함께 전달하세요."

---

## 다른 스킬 연계

Ouroboros 진행 중 아래 상황이 발생하면 해당 스킬을 안내한다:

| 상황 | 안내할 스킬 | 안내 문구 |
|------|-----------|-----------|
| A/B 의사결정이 어려움 | `/agent-arena` | "여러 관점에서 찬반 토론을 통해 결론을 내릴 수 있습니다." |
| 숨겨진 가정/사각지대 의심 | `/clarify unknown` | "Known/Unknown 4분면 분석으로 사각지대를 점검할 수 있습니다." |
| 접근 방식 자체를 재고 | `/clarify metamedium` | "Content vs Form 관점에서 더 높은 레버리지를 찾을 수 있습니다." |
| 목표가 너무 보수적 | `/moonshot` | "목표를 상향 조정하고 싶다면 moonshot 프레임워크를 활용해보세요." |
| 기술 스택 결정 필요 | `/tech-decision` | "기술 의사결정이 필요하면 체계적 분석을 진행할 수 있습니다." |
| 문서 리뷰 필요 | `/expert-review` | "문서를 다른 관점에서 리뷰받고 싶다면 전문가 리뷰를 활용해보세요." |
| 요구사항만 간단히 정리 | `/clarify vague` | "설계/검증까지 필요 없이 요구사항만 구체화하고 싶다면 vague 모드가 더 적합합니다." |

---

## Anti-Patterns

| 하지 말 것 | 왜 |
|-----------|-----|
| 품질 게이트 없이 Phase 전환 | 모호함이 다음 단계로 전파됨 |
| 열린 질문 ("어떻게 하고 싶어?") | 인지 부하. 가설 기반 옵션을 제시하라 |
| Phase 2 전에 구현 세부사항 논의 | Phase 1은 "무엇"에 집중. "어떻게"는 Phase 2에서 |
| 한 번에 여러 질문 | 얕은 답변 유발, 정확한 점수 불가 |
| 점수 보고 생략 | 투명성이 메트릭 기반의 핵심 |
| "나중에 결정하자"로 넘기기 | 모호함이 축적되어 품질 게이트를 통과할 수 없게 됨 |
| 질문 상한을 임의로 낮춤 | 모호함이 남으면 의미 없음 (30라운드 하드캡은 존재) |
| 코드베이스 사실을 사용자에게 묻기 | 호스트 탐색 도구 또는 직접 `rg`/파일 읽기로 먼저 파악하라 |
| Phase 1 산출물 없이 Phase 2 시작 | 요구사항 문서가 Phase 2의 입력. 건너뛰려면 기존 PRD 필요 |