# Prd

> Write a complete unified PRD covering user/JTBD/decisions/scope/agent-spec/metrics/hypotheses in 15 sections. Single source of truth for both customer-facing products and the LLM agents inside them. Replaces the older 7-section agent-only template. prd is the canonical owner of §6 Now/Next/Later. --mode design-shotgun reads §1+§11 from existing PRD and generates harness/design-variants/ (4 HTML variants + comparison.md). --mode roadmap is the §6 sub-mode: generate(Mermaid gantt + ROADMAP.md), rice(deterministic RICE scoring), prioritize(Now/Next/Later 재분류).

- Skill: `kimsanguine/prd` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add kimsanguine/prd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kimsanguine/prd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: kimsanguine (https://skillmd.com/u/kimsanguine)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kimsanguine/prd

---


## Project Context (auto-injected)

**프로젝트 메모리:**
!`cat .claude/MEMORY.md 2>/dev/null || echo "프로젝트 메모리 없음."`

**현재 이슈 (Linear/GitHub):**
!`linear issue list --mine --status "In Progress" --limit 5 2>/dev/null || gh issue list --limit 5 --json number,title --jq '.[] | "#\(.number) \(.title)"' 2>/dev/null || echo "이슈 트래커 연결 없음."`

---

## Unified PRD Template — 15 Sections

## Core Goal

- 고객(인간) 대상 제품과 그 안의 LLM 에이전트 사양을 **단일 PRD 15-section**으로 통합
- "사람·문제·결정"이 상단 (1-6), "에이전트·실행 사양"이 중단 (7-11), "지표·가설·실패"가 하단 (12-14)
- 1인 빌더 60일 사이클 + 5명 사랑 검증 + Live URL 도착까지 같은 PRD를 매번 갱신

---

## Trigger Gate

### Use This Skill When

- 새 SaaS·버티컬 앱·1인 빌더 제품의 정식 사양 문서화 (PRD v0.1)
- 5명 사랑 검증 직전 PRD v0.2~v0.3 갱신
- 도메인 특화 제품 (법률·교육·의료) — 사용자 페르소나·JTBD가 핵심
- 내부용 LLM 에이전트 spec — Section 1·3에 페르소나 = 내부 사용자, Section 7-11에 에이전트 상세
- 투자자·파트너·외부 엔지니어에게 제품 사양 공식 전달
- PRD §11 Output Spec 작성 후 UI 변형 4개를 비교해 설계 방향을 결정할 때 → `--mode design-shotgun`
- §6 Now/Next/Later를 시각적 로드맵으로 변환하거나 백로그를 RICE로 우선순위화할 때 → `--mode roadmap [generate|rice|prioritize]`

### Route to Other Skills When

- **배포 전 QA 라운드** → `deliver/qa-checklist --mode adversarial` (PRD §15 QA Pool + PERSONA_SPECS 기반 동적 에이전트 구성)
- **ICP·beachhead 정의** → `discover/customer-reach`로 라우팅 후 Section 1에 주입
- **JTBD·Switch Interview** → `discover/customer-reach`로 라우팅 후 Section 2에 주입
- **결정 옵션 매트릭스** → `discover/assumptions --mode build-or-buy` (6축) + `architect/orchestration` (4패턴) + `discover/hitl` (5레벨) → Section 4
- **제외사항 자동 인용** → `hplan/exclusions` 레지스트리 fuzzy match → Section 5
- **MVP 비용 시뮬레이션** → `discover/cost-sim` (lognormal p50/p90) → Section 6
- **Instruction 7요소 상세 설계** → `deliver/agent-setup` → Section 7 보강
- **OKR 정의** → `operate/metrics-design --step okr` (dual-axis) → Section 12
- **가설 분해** → `discover/assumptions` (4축) → Section 13
- **신뢰성·SLO** → `operate/reliability` → Section 14
- **Multi-ecosystem export** → `hplan/handoff` (Spec-Kit / Kiro / GStack / Claude Code)
- **사용자 인터페이스가 있는 LLM 에이전트 (UI/UX 강제)** → `deliver/respect --mode brief` (RESPECT.md 디자인 시그니처) → Section 11 출력 사양 보강
- design-shotgun 변형 선택 후 TC 자동 생성 → `deliver/qa-checklist`

### Boundary Checks

- PRD 15-section은 "무엇을 하는가"를 명시하지만, "어떻게 기술적으로 구현하는가"는 별도 구현 문서
- 각 섹션은 "5명 사랑 인터뷰에 그대로 쓸 수 있는가? + 엔지니어가 이것만으로 구현 가능한가?" 두 기준으로 검증
- 제외사항(Section 5)이 최소 5개 이상 — "의식적으로 안 만드는 것" 명시
- Section 7-11 (에이전트 사양)은 1인 빌더가 LLM 에이전트를 포함하지 않으면 "N/A — 일반 SaaS"로 간단 표기 가능
- `--mode design-shotgun` 사용 시 `docs/PRD.md` 부재 → fail loud: "docs/PRD.md 없음. /prd [제품명] 먼저 실행하세요."
- `--mode design-shotgun` 사용 시 §11 섹션 부재 → fail loud: "PRD §11 Output Specification 섹션이 필요합니다."
- `--mode roadmap generate|prioritize` 사용 시 §6 Now/Next/Later 부재 → fail loud: "PRD §6 MVP 범위 섹션이 필요합니다."
- prd는 §6 Now/Next/Later의 canonical 소유자다 — roadmap은 그 sub-mode로 §6을 시각화·우선순위화하며, 별도 스킬이 아니다.

---

## Failure Handling

| 실패 상황 | 감지 | 대응 |
|----------|------|------|
| ICP가 "20-50대 일반인" 같이 추상적 | Section 1 검토 시 beachhead 5-criteria 통과 못 함 | `discover/customer-reach` 라우팅으로 ICP 재정의 |
| JTBD가 솔루션 어조 ("편하게 X 할 수 있다") | Section 2가 Job이 아닌 Feature 설명 | Switch Interview 4 Forces (Push·Pull·Anxiety·Habit)로 재작성 |
| 결정 옵션 매트릭스가 옵션 1개만 | Section 4에 옵션 A/B/C 중 하나만 | 최소 2개 옵션 + 트레이드오프 강제. `discover/assumptions --mode build-or-buy` 호출 |
| 제외사항 비어 있음 | Section 5 빈 칸 | "절대 안 만드는 것 5개" 강제 입력. `hplan/exclusions` 자동 인용 |
| MVP·Full vision 분리 없음 | Section 6에 Now/Next/Later 구분 없음 | 3-tier 분할 + 각 tier에 cogs p50/p90 첨부 |
| Anti-Goals 없음 | Section 7에 "하면 안 되는 것" 없음 | 최소 3개 강제. 도메인 룰·hallucination 정책·법적 책임 영역 포함 |
| Tools 호출 제한 없음 | Section 8 일부 행에 "호출 제한" 컬럼 빈 칸 | `deliver/agent-setup` 라우팅으로 도구별 상세 조건 정의 |
| Trigger 모호 ("필요 시") | Section 10 트리거 유형 미지정 | Cron/Event/Manual/Pipeline 중 명시적 선택 |
| Output 예시 없음 | Section 11 출력 샘플 칸 빈 칸 | 실제 출력 1개 작성 강제 (Markdown / JSON / Plain text) |
| 성공 지표가 추정·동기 부재 | Section 12에 측정·기한 없음 | `operate/metrics-design --step okr` 라우팅으로 Dual-axis 재작성 |
| 검증 가능 가설 없음 | Section 13에 가설 0개 | `discover/assumptions`로 top-3 + 2-day experiment 강제 |
| HITL 트리거 모호 | Section 14에 "사용자 확인" 같이 추상 | 구체적 임계값·이벤트로 재정의 (예: 충실성 < 0.7) |
| `docs/PRD.md` 부재 (`--mode design-shotgun`) | `ls` 실패 | fail loud + "/prd 먼저" 후 종료 |
| §11 부재 (`--mode design-shotgun`) | 섹션 추출 없음 | fail loud + "PRD §11 필요" 후 종료 |
| §1 부재 (`--mode design-shotgun`) | 섹션 추출 없음 | WARN + ICP 적합도 평가 생략, 계속 진행 |

---

## Quality Gate

- [ ] Section 1: ICP 1줄 + 페르소나 2~3개 + 도달 채널 (Yes/No)
- [ ] Section 2: JTBD 1~3개 + Switch 4 Forces (Yes/No)
- [ ] Section 3: 핵심 문제 1~3개 + "10배 가치" 정량 (Yes/No)
- [ ] Section 4: 결정 옵션 매트릭스 (최소 2개 옵션·트레이드오프) (Yes/No)
- [ ] Section 5: 제외사항 5개 이상 (Yes/No)
- [ ] Section 6: Now/Next/Later + cogs p50/p90 (Yes/No)
- [ ] Section 7: Role + Primary Goal + Anti-Goals 3개 이상 (Yes/No)
- [ ] Section 8: Tools + 사용 조건 + 호출 제한 (Yes/No)
- [ ] Section 9: 3-tier 메모리 (Working / Long-term / Procedural) (Yes/No)
- [ ] Section 10: 트리거 유형 + 실행 흐름 Step-by-Step (Yes/No)
- [ ] Section 11: 채널/형식/길이/언어/톤 + 출력 샘플 (Yes/No)
- [ ] Section 12: OKR + North Star + Anti-Metric + Cost KR mandatory (Yes/No)
- [ ] Section 13: Top-3 가설 + 2-day experiment 링크 (Yes/No)
- [ ] Section 14: 실패 시나리오 (4개 이상) + HITL 트리거 (Yes/No)
- [ ] 디자인 시그니처 commit: UI/UX 있으면 `deliver/respect --mode brief` 호출 + RESPECT.md 참조, 없으면 "N/A — 백엔드만" 명시 (Yes/No/N/A)
- [ ] Section 15: QA Pool — 페르소나 소스 명시, 개발 역할 결정론 매핑 근거 포함, `harness/QA_POOL.json` 저장됨 (Yes/No)
- [ ] 전체 일관성: 섹션 간 충돌·누락 없음 (Yes/No)
- [ ] TK 인용: `operate/pm-engine` 쿼리로 관련 TK-NNN 3~5개 (Yes/No)
- [ ] `--mode design-shotgun`: docs/PRD.md 부재 시 즉시 종료
- [ ] `--mode design-shotgun`: §11 부재 시 즉시 종료
- [ ] `--mode design-shotgun`: 4개 HTML 변형 + comparison.md 생성됨
- [ ] `--mode design-shotgun`: 각 HTML 파일에 §11 해석 주석 포함

---

## Unified PRD 15-section 구조

> **상단** = 사람·문제·결정 (Section 1~6) → 비즈니스가 읽음
> **중단** = 에이전트·실행 사양 (Section 7~11) → 엔지니어가 읽음
> **하단** = 지표·가설·실패 (Section 12~14) → PM이 매주 갱신
> **부록** = QA Pool (Section 15) → `deliver/qa-checklist --mode adversarial` 전용

---

### Section 1 — 사용자 / ICP / 페르소나

```
ICP (Ideal Customer Profile):
[한 줄 정의 — beachhead 5-criteria 통과]

페르소나 (2~3개):

### 페르소나 A. [이름·역할]
- 하루 일과:
- 핵심 고통 (top 3):
- 현재 대안:
- 도달 채널 (verified):
```

> 자동 호출: `discover/customer-reach` beachhead 5-criteria 결과 inject (부재 시 ICP 1줄 + 페르소나 2~3개 직접 작성)

**이해관계자 영향도 매트릭스 (조직 도입 시 선택):**

에이전트가 조직 전체에 영향을 미치거나 여러 팀 합의가 필요한 경우, 페르소나 이후 아래 항목을 추가한다.

| 이해관계자 그룹 | Power (1-5) | Interest (1-5) | 전략 | 핵심 메시지 |
|---|---|---|---|---|
| 경영진 (C-Level) | | | Engage Actively | ROI + 리스크 대비책 |
| 직접 사용자 | | | Engage Actively | 반복 작업 해방 |
| 엔지니어링 | | | Manage Closely | 깔끔한 아키텍처 + 소유권 |
| 법무/컴플라이언스 | | | Keep Informed | HITL + 감사 로그 |
| 운영/CS | | | Keep Informed | 안정성 + 에스컬레이션 경로 |
| 재무 | | | Keep Informed | 비용 예측 가능성 + ROI |

주요 저항 유형: Job Threat("내 일 대체") → Co-pilot 포지셔닝 / Trust Deficit("AI 믿을 수 없다") → Shadow Mode 검증 / Control Loss("통제 못 함") → HITL 설계

---

### Section 2 — JTBD (Jobs To Be Done)

```
핵심 Job (1~3개):

### Job-1: [상황]에서 [목표]를 달성하고 싶다, 그래서 [성공 기준]
- Push (현 상태 불만):
- Pull (새 솔루션 매력):
- Anxiety (도입 불안):
- Habit (기존 습관 관성):
```

> 자동 호출: `discover/customer-reach` Switch Interview 산출물 (부재 시 Push/Pull/Anxiety/Habit 4 Forces로 1~3개 Job 직접 작성)

---

### Section 3 — 핵심 문제 + 해결할 가치

```
문제 (top 1~3 — 절실히 이해):
1. [페르소나]는 [상황]에서 [고통] — 매일 N시간 또는 ₩M 손실

해결 방식 (워크플로우, 솔루션 X):
[본 제품이 풀어주는 흐름 — 일하는 방식이 어떻게 바뀌는가]

10배 가치 (정량):
- 시간: [Before] N시간 → [After] N분 (M배)
- 돈: [Before] ₩M → [After] ₩K (M배)
- 또는: 새로 가능해지는 것
```

---

### Section 4 — 결정 옵션 매트릭스

```
| 결정 항목 | 옵션 A | 옵션 B | 옵션 C | 선택 | 트레이드오프 | 재검토 시점 |
|---------|--------|--------|--------|------|-------------|------------|
| RAG 인프라 | Supabase pgvector | ChromaDB | Pinecone | A | Cloud 한 스택 vs 로컬 자유도 | 100명 |
| 결제 | Paddle MoR | Stripe | Lemon Squeezy | A | 사업자 등록 vs 직접 통합 | 1,000명 |
| Orchestration | Sequential | Parallel | Router | A | 디버깅 vs 속도 | Wave 2 |
| HITL 레벨 | L2 (suggest) | L3 (approve) | L4 (autonomous) | L3 | 안전성 vs 속도 | 5명 사랑 후 |
```

> 자동 호출: `discover/assumptions --mode build-or-buy` + `architect/orchestration` + `discover/hitl`

---

### Section 5 — 제외사항 (Out-of-Scope)

```
의식적으로 안 만드는 것 (최소 5개):

1. ❌ [기능 X] — 이유: [왜 안 만드나, 한 줄]
2. ❌ [기능 Y] — 이유:
3. ❌ ...
4. ❌ ...
5. ❌ ...

재검토 신호:
- [언제 이 제외 결정을 다시 볼 것인가]
```

> 자동 호출: `hplan/exclusions` 레지스트리 fuzzy match top-10

---

### Section 6 — MVP 범위 / Full vision

```
### Now (Wave 1, Day 1~60) — 5명 사랑 도달
- 핵심 기능 3~5개 (이것 없이 5명 사랑 불가능)
- cogs (p50): $___ / 사용자 / 월
- cogs (p90): $___ / 사용자 / 월
- Live URL 도착: Day 60

### Next (Wave 2, Day 61~120) — 5명 → 30명
- 확장 기능 3~5개
- cogs (p50): $___ / 사용자 / 월

### Later (Wave 3, Day 121+) — 30명 → 100명+
- 확장 기능
- cogs (p50): $___ / 사용자 / 월
```

> 자동 호출: `discover/cost-sim` (p50/p90 lognormal)

---

### Section 7 — Role + Primary Goal + Anti-Goals

> 본 제품이 LLM 에이전트를 포함하면 작성. 일반 SaaS면 "N/A"

```
Role:
[에이전트의 역할 정의 — 1~3문장]

Primary Goal:
[단 하나의 핵심 목표]

Secondary Goals:
1.
2.

Anti-Goals (하면 안 되는 것, 최소 3개):
1. [도메인 룰 — 예: 변호사 책임 영역 hallucination 금지]
2. [데이터 정책 — 예: 사용자 데이터 외부 전송 금지]
3. [법적 책임 — 예: 의료 진단 대체 금지]
```

> 자동 호출: `deliver/agent-setup` 7요소 상세 설계 (부재 시 Anti-Goals 3개 직접 작성)

---

### Section 8 — Tools & Integrations

```
| 도구/API | 용도 | 사용 조건 | 호출 제한 |
|---------|------|---------|---------|
| OpenAI text-embedding-3-small | 벡터 임베딩 | 새 문서 ingest 시 | 1회/문서 |
| Supabase pgvector | 유사도 검색 | 사용자 쿼리 시 | 무제한 |
| Paddle API | 결제·세금 | 구독 가입·해지 | 이벤트 기반 |
| Channel Talk API | CS 응답 | 사용자 메시지 | 1회/메시지 |
```

최소 권한 원칙: 필요한 도구만 포함, 각 도구 사용 범위 명시

---

### Section 9 — Memory & Context Design

```
Working Memory (컨텍스트):
- 항상 로드: [시스템 프롬프트, 도메인 룰, 사용자 컨텍스트]
- 조건부 로드: [관련 문서 top-5 from RAG]
- 컨텍스트 예산: [최대 N tokens]

Long-term Memory (DB / 파일):
- 읽기: [사용자별 누적 데이터 위치]
- 쓰기: [언제 무엇을 저장]
- 저장 트리거: [세션 종료 / 사용자 액션]

Procedural Memory (Skills):
- [참조하는 도메인 SKILL.md 목록]
```

**컨텍스트 예산 가이드 (토큰 추정 기준):**

| 모델 | 최대 컨텍스트 | 실용적 한도 |
|---|---|---|
| Haiku | 200k tokens | 40k (비용 효율) |
| Sonnet | 200k tokens | 80k (균형) |
| Opus | 200k tokens | 100k (품질 우선) |

토큰 추정: 마크다운 1KB ≈ 250~350 tokens, 코드 1KB ≈ 200~300 tokens, JSON 1KB ≈ 150~250 tokens

임계값: 70% 미만 정상 / 70~85% 경고(새 파일 로드 최소화) / 85%+ 위험(조건부 항목 제외)

필수/조건부/제외 분류: 항상 로드(SOUL+USER+최근 메모리)·조건부 로드(MEMORY, 도메인 SKILL)·제외(오래된 파일·원문 전체)로 구분하고 총 예산의 40% 이상을 출력+추론용으로 확보한다.

---

### Section 10 — Trigger & Execution Flow

```
트리거 유형:
☐ Cron (주기적) — 스케줄:
☐ Event-Driven — 이벤트:
☐ Manual — 조건:
☐ Pipeline — 선행 에이전트:

실행 흐름:
Step 1: [입력 수집]
Step 2: [처리]
Step 3: [출력 생성]
Step 4: [전달/저장]

예상 실행 시간: [초/분]
타임아웃 설정: [초]
```

---

### Section 11 — Output Specification

```
출력 채널: [Web UI / Telegram / 이메일 / API]
출력 형식: [Markdown / Plain text / JSON / 구조화 텍스트]
출력 길이: [최대 N자 / N줄]
언어: [한국어 / 영어]
톤: [간결 / 상세 / 브리핑 / 대화형]

출력 예시:
---
[실제 출력 샘플 작성]
---
```

---

### Section 12 — 성공 지표 통합 (Dual-axis)

```
North Star Metric:
[단 하나 가장 중요한 지표 — 사용자 가치와 직결]

Business KRs (3~5개):
1. DAU / WAU / MAU
2. MRR / ARR
3. 리텐션 D7 / D30
4. NPS
5. Sean Ellis 40% — "더 이상 못 쓰면 매우 실망"

Operational KRs (3~5개, mandatory cost KR 포함):
1. TTV (Time To Value) ≤ 5분
2. 도메인 충실성 ≥ 0.85
3. 에이전트 응답 시간 p95 ≤ 3초
4. 월 cogs / 사용자 ≤ $___
5. 에러율 ≤ 1%

Anti-Metric (이 지표가 오르면 위험):
[예: 평균 세션 시간이 30분 넘으면 사용자가 길을 잃은 것]
```

> 자동 호출: `operate/metrics-design --step okr` (dual-axis)

---

### Section 13 — 검증 가능 가설 박스

```
Top-3 가설 (Value/Feasibility/Reliability/Ethics 4축):

### 가설 H-1 (Value)
- 가설: [if X then Y because Z]
- 측정: [어떻게 측정]
- 임계값: [통과 기준]
- 2-day experiment: [실험 설계]
- 결과: [통과 / 실패 / 진행 중]

### 가설 H-2 (Feasibility)
...

### 가설 H-3 (Reliability)
...
```

> 자동 호출: `discover/assumptions` (4축 분해 + 2-day experiment)

---

### Section 14 — 실패 모드 + Human-in-the-loop

```
실패 시나리오 매트릭스 (최소 4개):

| 시나리오 | 감지 | 대응 | 사용자 영향 |
|---------|------|-----|------------|
| 도메인 RAG 충실성 < 0.7 | Eval suite | Fallback to GPT + 경고 | 낮음 |
| 결제 API 실패 | HTTPError | 3회 재시도 → 대안 결제 안내 | 중간 |
| 한국어 판례명 잘못 인식 | 사용자 신고 | admin 알림 + roll back | 높음 |
| 데이터 유출 의심 | 비정상 access | 즉시 차단 + audit log | Critical |

Human-in-the-loop 트리거:
- 도메인 충실성 < 0.7 → 사용자 확인 요청
- 결제 분쟁 → admin escalation
- 법률·의료 등 high-stakes → 항상 사용자 확인
```

---

### Section 15 — QA Pool (배포 전 검수 에이전트 구성)

> 이 섹션은 PRD 작성 시 자동 생성. `qa-checklist --mode adversarial` 실행 전 필수.
> **결정론 원칙**: 역할 선택은 아래 매핑 테이블 기반 — LLM 임의 판단 금지.

> ⚠️ `interview_evidence_verified: false`인 QA_POOL.json으로 QA 라운드를 실행하면, 페르소나 기반 검증이 누락된 상태입니다. `interview-synthesis audit`을 먼저 완료하세요.

```
QA Pool 구성 규칙:

### 페르소나 에이전트 (harness/PERSONA_SPECS.json 에서 자동 연결)
- interview-synthesis 결과가 있으면 PERSONA_SPECS.json의 P01~P0N 전원 포함
- PERSONA_SPECS.json 부재 시 → `interview_evidence_verified: false` 로 저장 + "페르소나 없음 (인터뷰 완료 후 재실행 권장)" 명시
- PERSONA_SPECS.json 존재 시 → `interview_evidence_verified: true` 로 저장

### 개발 리뷰어 역할 (도메인·스택 기반 결정론 매핑)
```

**결정론 매핑 테이블**:

| PRD 조건 | 포함 역할 |
|----------|-----------|
| §1 ICP 도메인 = 법률 | `legal_domain` (법령 정확성 검증) |
| §1 ICP 도메인 = 의료 | `medical_domain` |
| §1 ICP 도메인 = 금융 | `finance_domain` |
| §8 스택에 Next.js / React / Vue / Flutter / Swift / Kotlin 포함 | `frontend` |
| §8 스택에 FastAPI / Django / Node / Go / Rails / Spring 포함 | `backend` |
| §8 스택에 GraphQL 포함 | `backend` |
| §8 스택에 DB (PostgreSQL / MySQL / Supabase / MongoDB) 포함 | `backend` |
| §8 스택에 LLM API 포함 | `ai_engineer` |
| §7 Anti-Goals에 보안·개인정보 포함 | `security` |
| §14 실패 시나리오 4개 이상 | `qa_engineer` |
| 기본 (항상 포함) | `qa_engineer` |
| §8 스택 키워드가 위 패턴에 미해당 | WARN 출력: "스택 미매핑 — dev_roles에 수동 역할 추가 필요" |

```markdown
## §15 QA Pool

생성일: YYYY-MM-DD | 소스: §1 ICP, §7 Anti-Goals, §8 스택, §14 실패 시나리오

### 페르소나 에이전트
- 소스: harness/PERSONA_SPECS.json
- [P01: 이름·역할] / [P02: 이름·역할] / ...

### 개발 리뷰어 역할
- [역할1]: [포함 근거 — 어떤 PRD 조건에 해당하는지]
- [역할2]: [포함 근거]
- ...

### 예상 라운드 수
- Critical 이슈 없을 때: 1~2 라운드
- Critical 이슈 발생 시: ralph loop 자동 수정 후 재검토
```

**저장**: `harness/QA_POOL.json` (qa-checklist --mode adversarial이 읽음)

```json
{
  "generated_at": "YYYY-MM-DD",
  "persona_source": "harness/PERSONA_SPECS.json",
  "interview_evidence_verified": false,
  "dev_roles": ["frontend", "backend", "qa_engineer", "legal_domain"],
  "role_rationale": {
    "frontend": "§8 스택 Next.js 포함",
    "legal_domain": "§1 ICP 법률 도메인"
  }
}
```

---

## `--mode design-shotgun` — §11 시각화 변형 생성

`docs/PRD.md`의 §1 ICP + §11 Output Specification을 파싱해
`harness/design-variants/` 에 HTML 변형 4개와 비교 문서를 생성한다.

---

### Rule 5 준수

| 판단 | 도구 | LLM |
|---|---|---|
| PRD 파일 존재 여부 | ls/Read | ❌ |
| §1·§11 섹션 존재 여부 확인 | grep 결정론 | ❌ |
| §1·§11 섹션 내용 추출 | 라인 번호 기반 파싱 후 LLM | ✅ (비정형 내용 해석) |
| 4개 HTML 변형 생성 | — | ✅ (자연어 생성) |
| comparison.md 적합도 평가 | — | ✅ (판단 설명) |
| 파일 저장 | Write | ❌ |

---

### Inputs

| 입력 | 출처 | 처리 |
|---|---|---|
| ICP 정의 + 핵심 고통 | `docs/PRD.md` §1 | 변형 적합도 판단 기준 |
| 출력 채널·형식·톤 | `docs/PRD.md` §11 | 4개 변형의 공통 기반 |

---

### Instructions (--mode design-shotgun)

**Step 1 — PRD 로드 및 섹션 추출**

```bash
ls docs/PRD.md 2>/dev/null || echo "PRD_MISSING"
```

PRD_MISSING 시:
```
❌ 에러: docs/PRD.md 없음.
/prd [제품명] 먼저 실행하세요.
```
즉시 종료.

**§11 섹션 존재 결정론 확인 (LLM 호출 전)**:

```bash
# 허용 heading 패턴: "Section 11", "§11", "11 —", "11." (대소문자 무관)
grep -in "^#\+.*\(section 11\|§11\|11 —\|11\.\)" docs/PRD.md | head -3
```

- 매칭 0건 → 즉시 종료:
  ```
  ❌ 에러: PRD §11 Output Specification 섹션이 필요합니다.
  (감지된 패턴: ## Section 11, ### §11, ## 11 — Output Specification 등)
  ```
- 매칭 2건 이상 → 경고 출력: "§11 heading이 여러 개 감지됨 — 첫 번째 매칭 사용"
- 매칭 1건 → ✅ 진행

§1도 동일하게 grep으로 확인:
```bash
grep -in "^#\+.*\(section 1\b\|§1\b\|1 —\|1\.\)" docs/PRD.md | head -3
```
§1 매칭 0건 → WARN (FAIL 아님): "§1 없이 ICP 적합도 평가 생략"

`docs/PRD.md` Read → §1 (ICP / 페르소나) + §11 (Output Specification) 추출.
§11 부재 시:
```
❌ 에러: PRD §11 Output Specification 섹션이 필요합니다.
```
즉시 종료.

**Step 2 — 출력 디렉터리 준비**
```bash
mkdir -p harness/design-variants
```

**Step 3 — 4개 HTML 변형 생성**

각 변형은 §11을 다르게 해석한 것이다. 변형 패턴:

| 변형 | §11 해석 전략 | ICP 적합 상황 |
|---|---|---|
| Variant A | 단계 명시 (스텝퍼/탭) — 순서와 진행 상태 강조 | 처음 사용하는 ICP, 학습 비용이 있는 플로우 |
| Variant B | 컨텍스트 보존 (모달/오버레이) — 현재 화면 유지 | 비교·참조가 필요한 ICP, 중단 후 재개 빈번 |
| Variant C | 단순 직선 (미니멀) — 핵심 입력/출력만 | 반복 사용 ICP, 숙련 사용자 |
| Variant D | 프로그레시브 공개 — 기본 옵션 → 고급 옵션 순차 노출 | 입문자+숙련자 혼재 ICP |

각 `harness/design-variants/variant-[A-D].html` 파일은:
- 순수 HTML + 인라인 CSS만 사용 (외부 CDN, JS 프레임워크 금지)
- 파일 상단 주석에 §11 해석 명시:
  ```html
  <!--
    Variant A — §11 해석: [어떤 §11 스펙 부분을 어떻게 해석했는가]
    ICP 적합 시나리오: [어떤 페르소나에 맞는가]
    TC 후보: [이 변형에서 테스트해야 할 시나리오 2개]
  -->
  ```
- 실제 제품 와이어프레임 수준의 HTML 마크업 (더미 텍스트 OK, 구조는 §11 반영)
- 색상: 회색 팔레트 (설계 결정이 아니라 레이아웃 집중)

**Step 4 — comparison.md 생성**

`harness/design-variants/comparison.md`:

```markdown
# Design Variants — [제품명]
생성: YYYY-MM-DD | 소스: docs/PRD.md §1 + §11

## §11 Output Spec 요약
[추출된 §11 핵심 내용 3-5줄]

## ICP 요약 (§1)
[추출된 ICP 핵심 1-2줄]

## 변형 비교

| 변형 | §11 해석 | ICP 적합도 | 주요 TC 후보 | 선택 시 주의점 |
|---|---|---|---|---|
| Variant A | ... | ★★★☆☆ | ... | ... |
| Variant B | ... | ★★☆☆☆ | ... | ... |
| Variant C | ... | ★★★★☆ | ... | ... |
| Variant D | ... | ★★★☆☆ | ... | ... |

## 권장 변형
[ICP 기준으로 가장 적합한 변형 + 이유 2-3줄]

## 다음 단계
1. 변형 선택 후 → `deliver/qa-checklist` 로 해당 변형 TC 생성
2. TC 생성 후 → `deliver/ui-validate --check tc-gate [URL]` 로 증거 수집
```

**Step 5 — 완료 출력**
```
✅ harness/design-variants/ 생성 완료
   Variant A: variant-A.html (스텝퍼/탭 방식)
   Variant B: variant-B.html (컨텍스트 보존 방식)
   Variant C: variant-C.html (미니멀 직선 방식)
   Variant D: variant-D.html (프로그레시브 공개 방식)
   비교: comparison.md

   → comparison.md를 검토하고 변형을 선택한 후 /qa-checklist 를 실행하세요.
```

---

### Failure Handling (--mode design-shotgun)

| 실패 상황 | 감지 | 대응 |
|---|---|---|
| `docs/PRD.md` 부재 | `ls` 실패 | fail loud + "/prd [제품명] 먼저" 후 종료 |
| §11 부재 | 섹션 추출 결과 없음 | fail loud + "PRD §11 필요" 후 종료 |
| §1 부재 | 섹션 추출 결과 없음 | WARN (FAIL 아님) + "§1 없이 ICP 적합도 평가 생략" 후 계속 |
| `harness/` 부재 | `ls` 실패 | `mkdir -p harness/design-variants/` 후 진행 |

---

### Quality Gate (--mode design-shotgun)

- [ ] PRD 부재 시 즉시 종료, 변형 생성 금지
- [ ] §11 부재 시 즉시 종료
- [ ] 4개 변형 파일 모두 생성됨 (variant-A~D.html)
- [ ] 각 HTML 파일에 §11 해석 주석 포함
- [ ] 외부 CDN / JS 프레임워크 없음 (순수 HTML+인라인 CSS)
- [ ] comparison.md에 권장 변형 명시됨
- [ ] comparison.md에 다음 단계(qa-checklist → tc-gate) 안내 포함

---

### Examples (--mode design-shotgun)

#### Good Example
**입력:** `--mode design-shotgun` (docs/PRD.md 존재, §1·§11 있음)

**기대 동작:**
1. PRD §1 ICP + §11 Output Spec 추출
2. 4개 HTML 변형 생성 (harness/design-variants/)
3. comparison.md 작성 (ICP 적합도 평가 포함)
4. 완료 통계 출력

#### Bad Example
**입력:** `--mode design-shotgun` (docs/PRD.md 없음)

**기대 동작:**
```
❌ 에러: docs/PRD.md 없음.
/prd [제품명] 먼저 실행하세요.
```
실행 중단.

---

## `--mode roadmap` — §6 로드맵 + RICE 우선순위화

prd는 §6 Now/Next/Later의 **canonical 소유자**다. roadmap은 별도 스킬이 아니라 §6을 시각적 로드맵과 우선순위 데이터로 변환하는 sub-mode다.

`$ARGUMENTS`로 sub-mode를 받는다: `generate`(Mermaid gantt) / `rice`(RICE 점수 계산) / `prioritize`(Now/Next/Later 재분류). 미지정 시 fail loud + sub-mode 목록.

| sub-mode | 입력 | 출력 |
|---|---|---|
| generate | PRD §6 | docs/ROADMAP.md (Mermaid gantt) |
| rice | 백로그 항목 | docs/rice-scores.md |
| prioritize | RICE 결과 | PRD §6 Now/Next/Later 갱신 제안 |

### Rule 5 준수 경계

| 작업 | LLM | 근거 |
|---|---|---|
| Mermaid gantt 코드 생성 | ✅ | 자연어 → 구조화 코드 변환 |
| RICE 수치 계산 | ❌ 결정론 | Reach × Impact × Confidence ÷ Effort 공식 |
| 우선순위 재분류 기준 | ❌ 결정론 | RICE 점수 임계치 lookup |

### RICE 공식 (결정론)

```
RICE = (Reach × Impact × Confidence) / Effort

Reach: 월간 영향받는 유저 수 (PM 입력)
Impact: 0.25(최소) / 0.5(낮음) / 1(중간) / 2(높음) / 3(대규모)
Confidence: 50%(낮음) / 80%(중간) / 100%(높음)
Effort: 사람-주(person-week) 단위
```

### Instructions (--mode roadmap)

#### sub-mode: generate
1. `harness/PRD.md` 또는 `docs/PRD.md` §6 읽기 → Now/Next/Later 항목 파싱 (결정론 grep). §6 부재 → fail loud.
2. 각 항목의 예상 기간을 PRD 또는 backlog에서 읽기
3. Mermaid gantt 다이어그램 생성 (LLM):
   - Now = 현재~4주
   - Next = 4~12주
   - Later = 12주+
4. docs/ROADMAP.md 저장 (기존 파일 있으면 diff 기반 업데이트 제안)

#### sub-mode: rice
1. 백로그 항목 파싱 (harness/backlog.md 또는 $ARGUMENTS)
2. 각 항목에 대해 Reach/Impact/Confidence/Effort를 PM에게 물어봄 (AskUserQuestion)
3. RICE 점수 공식으로 계산 (결정론 — LLM 조정 0)
4. docs/rice-scores.md 저장

#### sub-mode: prioritize
1. docs/rice-scores.md 로드 → RICE 점수 기준 정렬 (결정론)
2. 임계치 기준 분류 (결정론 lookup):
   - RICE > 50: Now 후보
   - RICE 20-50: Next 후보
   - RICE < 20: Later 후보
3. 현재 PRD §6 Now/Next/Later와 비교 → 불일치 항목 표시
4. PRD §6 갱신 제안 (확인 게이트 후 반영)

### Quality Gate (--mode roadmap)
- [ ] RICE 계산 = 공식 그대로 (LLM 조정 0)
- [ ] gantt에 날짜 추측 0 (PRD/backlog 인용 또는 PM 입력)
- [ ] 로드맵 갱신은 확인 게이트 후에만
- [ ] §6 부재 시 (generate/prioritize) fail loud

---

## Instructions

You are helping write a complete **Unified PRD** for: **$ARGUMENTS**

**Phase 1** — Section 1-3 (사람·문제·가치)
- Section 1: ICP·페르소나 — `discover/customer-reach` (beachhead 5-criteria; 부재 시 ICP 1줄 + 페르소나 2~3개 직접 작성)
- Section 2: JTBD·Switch 4 Forces — `discover/customer-reach` (부재 시 Push/Pull/Anxiety/Habit 4 Forces로 1~3개 Job 직접 작성)
- Section 3: 핵심 문제 + 10배 가치 (정량)

🔍 Checkpoint 1: User 검증 — "ICP·JTBD·문제가 5명 사랑 인터뷰에 그대로 쓸 수 있는가?"

**Phase 2** — Section 4-6 (결정·범위)
- Section 4: 결정 옵션 매트릭스 — `discover/assumptions --mode build-or-buy` + `architect/orchestration` + `discover/hitl` (부재 시 옵션 2개 × 5개 결정 항목 직접 작성)
- Section 5: 제외사항 — `hplan/exclusions` 자동 인용
- Section 6: Now/Next/Later — `discover/cost-sim` (cogs p50/p90)

🔍 Checkpoint 2: User 검증 — "MVP가 60일 안에 가능한가? cogs가 1인 빌더 감당 가능한가?"

**Phase 3** — Section 7-11 (에이전트·실행 사양)
- Section 7: Role + Anti-Goals — `deliver/agent-setup` (부재 시 Anti-Goals 3개 직접 작성)
- Section 8: Tools & Integrations + 호출 제한 mandatory
- Section 9: 3-tier Memory (Working / Long-term / Procedural)
- Section 10: Trigger & Execution Flow Step-by-Step
- Section 11: Output Specification + 실제 예시 1개
- Section 11 보강 (UI 있으면): `deliver/respect --mode brief` 호출 → RESPECT.md 디자인 시그니처 commit (3초 룰 / 다음 행동 / social proof)

> 일반 SaaS (LLM 에이전트 없음) 이면 Section 7-11에 "N/A — 일반 SaaS" 간단 표기 가능
> 사용자 인터페이스가 없는 백엔드 에이전트면 디자인 시그니처는 "N/A — 백엔드만" 명시

**Phase 4** — Section 12-14 (지표·가설·실패)
- Section 12: Dual-axis OKR — `operate/metrics-design --step okr` (cost KR mandatory)
- Section 13: Top-3 가설 — `discover/assumptions` + 2-day experiment
- Section 14: 실패 모드 (4개 이상) + HITL 트리거

**Phase 5** — PRD 통합 & TK 인용 & QA Pool 저장
- `operate/pm-engine` 쿼리로 관련 TK-NNN 3~5개 인용 (각 섹션 하단에 시드)
- §15 QA Pool 결정론 매핑 실행 → `harness/QA_POOL.json` 저장
  - `harness/PERSONA_SPECS.json` 존재 시 페르소나 소스 연결, 없으면 "페르소나 없음" 명시
- Quality Gate 19개 항목 (15 섹션 + 디자인 시그니처 + §15 QA Pool + 일관성 + TK 인용) 모두 통과 확인 (`references/test-cases.md`와 동일 산식)
- `docs/PRD.md`에 저장

---

## Further Reading
- Marty Cagan, *INSPIRED* — Discovery before delivery
- Bob Moesta, *Demand-Side Sales* — Switch Interview / JTBD
- Sean Ellis, *Hacking Growth* — 40% PMF Rule
- Marc Andreessen, *Pmarchive 2007* — "The Only Thing That Matters" PMF

## Contextual Knowledge (auto-loaded)

### Good Example
!`cat examples/good-01.md 2>/dev/null || echo ""`

### Bad Example
!`cat examples/bad-01.md 2>/dev/null || echo ""`

### Domain Context
!`cat context/domain.md 2>/dev/null || echo ""`

### Test Cases
!`cat references/test-cases.md 2>/dev/null || echo ""`

### Troubleshooting
!`cat references/troubleshooting.md 2>/dev/null || echo ""`