# Show Me The Prd

> Draft-first PRD generator for vibe coders — probes the real problem with one open question, decides direction in one numbered-choice round, drafts 4 design documents (PRD, data model, phases, project spec) immediately, then confirms assumptions in one batch. Collects UI design references when the product has a user-facing screen. Use when the user wants a PRD, planning docs, app spec, or an AI-ready build plan from a vague idea or partial notes. Korean — PRD 만들어줘, 기획서 만들어줘, 쇼미더피알디, 앱 기획해줘, 서비스 기획. English — make PRD, product spec, show me the PRD.

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

---


# Show Me The PRD for Codex — 선초안(Draft-First) PRD 생성

> 한 문장 아이디어 → 열린 탐침 1회 + 번호 카드 2회 → 4종 디자인 문서(+README) 완성
> 질문으로 사양을 다 채운 뒤 쓰는 게 아니라, **핵심 문제만 깊게 묻고 → 방향 결정 1콜 → 바로 초안 → 가정 일괄 확인**으로 간다. 초안이 가장 좋은 질문 생성기다.
> **이 문서는 참고 문서가 아니라 실행 지시서다.** Codex 채팅 환경에서 단계대로 실제로 진행한다.

아이디어: 사용자가 스킬을 부르면서 붙인 설명(이하 "아이디어"). 없으면 Turn 1의 첫 질문으로 시작한다.

## 먼저 읽기

- `$PLUGIN_ROOT/shared/questioning-policy.md` — 질문 정책(§1 공통 규칙 · §2 종료 규칙 · §A 채팅 번호 블록)
- `$PLUGIN_ROOT/skills/show-me-the-prd/references/interview-guide.md` — 인터뷰 방법론, 채팅 질문 설계, 바이브코더 대응
- `$PLUGIN_ROOT/skills/show-me-the-prd/references/research-strategy.md` — 리서치 라우팅, 배치 타이밍
- `$PLUGIN_ROOT/skills/show-me-the-prd/references/document-templates.md` — 문서 템플릿과 섹션 구조
- `$PLUGIN_ROOT/skills/show-me-the-prd/references/domain-doc-sets.md` — 4종 문서 **동적** 생성 절차 (도메인별)
- `$PLUGIN_ROOT/skills/show-me-the-prd/references/design-reference-guide.md` — UI 게이트 기준, 스타일 어휘, 레퍼런스 수집 절차 (UI 산출물일 때만)

## 핵심 원칙

1. **바이브코더 눈높이** — 기술 용어 금지. 모든 선택지에 설명 + 장단점 필수. (기술 용어 번역표는 `interview-guide.md`)
2. **AI가 리드, 유저가 결정** — 유저가 아는 것(목적·대상·원하는 동작)은 질문으로 끌어내고, 모르는 것(기술·구조)은 AI가 조사해서 선택지로 제안.
3. **리서치 기반** — 하드코딩된 추천이 아닌, 실시간 리서치 근거 제시.
4. **"진짜 제품" 지향** — 목업/로컬 데모가 아닌 실제 배포 가능한 수준의 기획.
5. **초안 먼저** — 데이터 모델·Phase 분리는 묻지 않고 설계해서 초안에 반영하고, 확인은 구체물로 받는다. (백지 질문보다 초안 교정이 정확하다는 A/B 검증 결과)

---

## 규칙 (정책: `shared/questioning-policy.md` §1·§2·§A + 아래 선초안 규칙)

- **질문 예산: 열린 탐침 1회(§2a 재탐침 +1) + 번호 카드 2콜(콜당 ≤4문항).** 예산 초과가 필요해 보이면 질문 설계 실패다 — 기본값+가정 원장으로 돌려라. 예외: 사용자가 명시적으로 깊은 인터뷰를 요청한 경우만 해제.
- **사실 vs 결정**: 조사(웹 검색/코드)로 알 수 있는 *사실*(현재 스택, 버전, 시장 관행, 외부 API 제약)은 묻지 않는다 — 조사해서 카드 옵션에 녹인다. *결정*(목표·범위·트레이드오프·원하는 동작)만 사용자에게. 애매하면 결정으로 취급.
- 카드 질문(Turn 2·Turn 4)은 반드시 아래 §A 번호 블록으로 출력한다. **단 Turn 1의 핵심 문제 발굴은 열린 텍스트 질문**으로 한다(과거 행동을 묻는 Mom Test식 — 객관식으로 가두지 않는다).
- 리서치 결과를 텍스트로 설명하지 않는다. 결과는 즉시 다음 카드의 선택지에 녹인다.
- 선택지 설명에 "뭔지 + 장점 + 단점". 추천 옵션은 (추천) + 1번. 기술 용어 대신 일상 비유.
- **가정 원장(assumption ledger)**: 작성 중 만난 미확정 지점은 둘로 나눈다 — 산출물 구조를 갈라놓는 **blocking** 결정은 질문 큐에 적립(Turn 4 카드에 합류), 그 외는 **시장 일반 관행 기본값** 채택 + 원장에 기록. 작성 도중 산발적으로 묻지 않는다 — 큐는 Turn 4 한 곳에서만 푼다.
- **중단 신호 존중 (§2c)**: 사용자가 "알아서 해줘"류로 답하면 남은 문항을 기본값+원장으로 돌리고 즉시 Turn 3 초안으로 직행한다.

### Codex 렌더링 규칙 — 카드 질문의 채팅 치환 (`shared/questioning-policy.md §A`)

Codex CLI에는 객관식 카드 UI 도구가 **없다.** 결정이 필요한 카드 질문은 모두 **채팅에 번호형 선택지 블록을 출력하고 사용자의 다음 자유 텍스트 답변을 읽는** §A 패턴으로 한다. 한 콜에 문항이 여러 개면 **Q1·Q2… 로 묶어 한 메시지에** 출력하고, 답은 "Q1-1, Q2-2"처럼 받는다.

```text
(예시 프리뷰 — 구조화 정보를 보여줄 때만. 단순 선호 질문이면 생략)

Q1. <한 줄 질문>
  1. <추천안> (추천) — 무엇인지, 왜 좋은지, 트레이드오프
  2. <대안> — 무엇인지, 트레이드오프
  3. 문장으로 직접 적기
Q2. <한 줄 질문>
  1. ...
(여러 개 고를 수 있으면: "여러 개면 1,3처럼 적어주세요")
(답은 "Q1-1, Q2-2"처럼. 모르면 전부 1번으로 진행할게요)
```

- 추천안은 항상 **1번**. 각 선택지에 "뭔지 + 장점 + 단점"을 한 줄로. 기술 용어 대신 일상 비유.
- "잘 모르겠어요"는 별도 선택지로 만들지 말고 "모르면 1번으로 진행할게요" 문장으로 안내.
- 구조화된 결정(데이터 모델 / Phase / 기술 스택 비교)에는 선택지 **위에** 짧은 예시 프리뷰(ASCII 관계도·테이블·트리)를 먼저 보여준다 — 카드 UI의 preview 필드 대체.
- 채팅에서는 마크다운 테이블을 피하고, 생성하는 문서 안에서는 템플릿이 요구하는 테이블을 그대로 쓴다.
- 사용자는 번호/문장 아무거나로 답할 수 있게 가두지 않는다.

---

## Turn 0: 사전 확인 (자동, 유저에게 묻지 않음)

리서치 보강용 스킬 의존성을 확인한다 (없어도 동작한다):

- 사용 가능한 스킬 목록에 `docs-guide`가 있으면 → 공식 문서 기반 기술 조사에 활용.
- `insane-research`가 있으면 → 종합 시장 리서치에 활용.
- `insane-search`가 있으면 → 디자인 레퍼런스 수집(Turn 2.5)에 활용.
- 없으면 → 빌트인 웹 검색/브라우저로 폴백 (기본 동작에 문제 없음).

라우팅 상세: `$PLUGIN_ROOT/skills/show-me-the-prd/references/research-strategy.md`.

동시에 **UI 게이트**를 판정한다: 아이디어(+이후 Turn 1 답변)로 산출물에 사용자 화면(웹/앱/랜딩/대시보드)이 있는지 본다. 백엔드/CLI/파이프라인/라이브러리면 **UI 없음** — Turn 2의 스타일 문항과 Turn 2.5 전체를 생략한다. 부분 UI(예: API+간단 어드민)는 사용자가 디자인을 먼저 언급한 경우에만 UI 있음으로 취급. 판정 기준 상세: `$PLUGIN_ROOT/skills/show-me-the-prd/references/design-reference-guide.md`

---

## Turn 1: 핵심 문제 발굴 (Mom Test식 열린 질문)

아이디어를 분석해 표면 기능 뒤의 **"진짜 문제"**를 끌어낸다. 이 Turn만큼은 깊게 — 선초안이 대체하지 못하는 유일한 단계다(A/B 검증에서 가장 깊은 잠재 니즈는 2차 탐침에서만 나왔다).

### 갭 분석 (내부 처리 — 유저에게 출력하지 않음)

아이디어에서 아래를 추출 시도하고, 추론 가능한 건 묻지 않는다:

| 카테고리 | 파악할 정보 | 처리 |
|----------|-----------|------|
| 핵심 문제 | 표면 기능 뒤의 진짜 불편 | ← Turn 1에서 열린 질문으로 발굴 |
| 사용자 | 누가 쓰는가 | 추론 시도, 모호하면 Turn 1에서 같이 |
| 도메인 | 비슷한 서비스, 차별점 | 추론 (도메인 감지 → Turn 2 선택지 재료) |
| 플랫폼·규모 | 웹/모바일, 규모, 제약 | 대개 추론 가능 → Turn 2에서 기본값+확인형, 확실하면 원장에 기록 |

도메인 감지 시 특화 결정을 Turn 2 재료로 고려: 이커머스(결제/배송/재고) · 소셜(팔로우/피드/신고) · 교육(진도/퀴즈/인증) · 금융(PG/환불/세금) · 생활·헬스(기록 주기/알림/공유). (도메인별 표: `interview-guide.md`)

### 질문 규칙

- **핵심 문제는 객관식이 아니라 열린 텍스트로, 과거 행동을 묻는다:** "지금은 이 문제를 어떻게 해결하고 계세요?" · "최근에 가장 불편했던 순간을 한 장면으로 들려주세요." 가정형("이런 기능 쓰실래요?") 금지. "왜" 대신 "무엇/어떻게".
- **조기 종료 금지 (§2a):** 첫 답이 표면적이면("그냥 기록 앱이요") 결론으로 받지 말고, 한 문장 **반영**한 뒤 **한 번 더 구체적으로 탐침**한다 — "그 방식에서 제일 막히거나 그만두게 된 지점이 언제였어요?". 기존 방식이 왜 안 되는지(진짜 문제)가 드러날 때까지.
- **과잉질문 가드 (§2c):** 아이디어가 이미 문제를 구체적으로 설명했으면 탐침을 생략하고 바로 Turn 2로.
- 핵심 문제 + 원하는 결과가 잡히면 한 문장으로 반영·확정하고 Turn 2로.

아이디어가 비어 있으면 "어떤 문제 때문에 이 앱/서비스를 생각하게 되셨어요?" 한 질문으로 시작한다.

### Turn 1 → Turn 2 전환 (리서치)

답변을 받으면 웹 검색으로 `"{아이디어} app features best practices 2026"` + `"best tech stack for {플랫폼} {도메인} app 2026"` 리서치 (docs-guide/insane-research가 있으면 활용). 텍스트로 설명하지 말고 즉시 Turn 2의 카드를 출력한다.

---

## Turn 2: 방향 결정 카드 (§A 번호 블록 1콜, ≤4문항)

초안의 방향을 가르는 **결정**만 한 메시지에 배치한다. **추론으로 확정된 항목은 문항에서 뺀다 — 4문항을 채우는 게 목표가 아니다.**

한 메시지에 Q1~Q4로 묶어 출력한다:

1. **MVP 범위** — 리서치 기반 기능 조합 3개(최소/중간/풀). 각 조합에 포함 기능 + 복잡도(간단해요/좀 복잡해요/많이 복잡해요) 한 줄. 추천(최소 핵심)을 1번에.
2. **기술 방향** — 스택 후보 2~3개. 선택지 위에 비교 프리뷰(무료 시작 / AI 코딩 호환 / 커뮤니티 / 배포 난이도)를 짧게 먼저 보여준다.
3. **로그인 방식** — 1. 소셜 로그인 (추천 — 구글/카카오, 비밀번호 관리 불필요, 다만 의존) / 2. 이메일+비밀번호 (자유도 높지만 비밀번호 찾기까지 만들어야 함) / 3. 매직링크 (간편하지만 매번 이메일 열어야 함) / 4. 불필요 (나만 쓰면 가장 간단).
4. **플랫폼 확인** — 추론 결과를 기본값+확인형으로 ("모바일 웹으로 가정했어요 — 맞나요?"). 추론이 확실하면 이 문항은 빼고 원장에 기록.
5. **디자인 스타일** *(UI 게이트 통과 시에만, 총 4문항 한도 내에서)* — 사용자가 스타일을 이미 말했거나 레퍼런스 URL을 줬으면 이 문항은 빼고 그대로 쓴다. 아니면 도메인에 어울리는 스타일 3~4개(미니멀 / 네오브루탈 / 다크 / 기타 — 각각 일상 언어 설명)를 선택지로. 문항이 5개가 되면 우선순위 낮은 것(보통 4번 플랫폼 확인)을 원장으로 돌린다.

```text
Q1. 첫 버전(MVP)에 어디까지 넣을까요?
  1. 최소 조합 (추천) — [기능 A, B] · 간단해요 · 빠르게 완성, 부가 기능은 나중에
  2. 중간 조합 — [기능 A, B, C] · 좀 복잡해요 · 시간이 더 걸림
  3. 풀 조합 — [A~E] · 많이 복잡해요 · 첫 버전엔 과함
Q2. 코드를 만들 때 쓸 도구(기술 스택)
  (프리뷰) 스택A: 무료 시작 O / AI 코딩 호환 높음 / 배포 쉬움 · 스택B: ... · 스택C: ...
  1. 스택A (추천) — ... 2. 스택B — ... 3. 스택C — ...
Q3. 로그인 방식  1. 소셜 (추천) — ... 2. 이메일+비밀번호 — ... 3. 매직링크 — ... 4. 불필요 — ...
Q4. 모바일 웹으로 가정했어요 — 맞나요?  1. 맞아요 (추천)  2. 데스크톱 웹  3. 네이티브 앱
(답은 "Q1-1, Q2-2, Q3-1, Q4-1"처럼. 모르면 전부 1번으로 진행할게요)
```

---

## Turn 2.5: 디자인 레퍼런스 수집 (UI 게이트 통과 시에만, 질문 없음)

UI 없음이면 이 단계를 통째로 건너뛰고 Turn 3으로 직행한다.

UI 있음이면 카드 답의 스타일로 레퍼런스를 수집한다 — 절차 상세: `$PLUGIN_ROOT/skills/show-me-the-prd/references/design-reference-guide.md`
- 쿼리 = `{서비스 도메인} + {스타일}` (영문 변환) → Dribbble/Cosmos 등에서 이미지 6~8장 회수 (insane-search 있으면 그 엔진 우선, 없으면 브라우저 폴백)
- **비전 스크리닝 필수**: 이미지를 직접 열어 스타일·도메인·화면종류(모바일/데스크톱) 부합을 판정, 상위 3~5장만 keep
- `PRD/references/`에 이미지 + `sources.json`(출처·라이선스 노트) 저장
- 사용자가 레퍼런스 URL을 직접 준 경우: 수집 대신 그 URL을 sources.json에 기록
- 전 소스 실패 시: 막지 말고 가정 원장에 "레퍼런스 미수집" 기록 후 진행

---

## Turn 3: 초안 작성 (질문 없음)

카드 답을 받으면 **즉시** 현재 프로젝트 루트의 `PRD/` 폴더에 5개 파일을 작성한다:

```
PRD/
├── 01_PRD.md            # 요구사항 (Product Requirements Document)
├── 02_DATA_MODEL.md     # 구조 (개념적 ERD)
├── 03_PHASES.md         # Phase 분리 계획 (Phase 1 = MVP, 2 = 확장, 3 = 고도화)
├── 04_PROJECT_SPEC.md   # 프로젝트 스펙 (AI 행동 규칙)
└── README.md            # 네비게이션
```

> **개수 4 + README = 5 파일 항상 출력**(사용자 예측가능성의 본질). **4종이 어떤 4종인지는 도메인을 보고 동적으로 결정**할 수 있다 — 4 차원(요구사항 / 구조 / 도메인 특화 / AI 행동 규칙) 슬롯을 도메인 키워드로 채워 즉석 정의. 도메인이 모호하면 위 기본 set. 절차: `$PLUGIN_ROOT/skills/show-me-the-prd/references/domain-doc-sets.md`. 단, 이 확인은 별도 질문으로 늘리지 말고 Turn 4 카드 문항 한도 안에서만 묻거나 원장에 기록한다.

문서 템플릿: `$PLUGIN_ROOT/skills/show-me-the-prd/references/document-templates.md`

**핵심 규칙:**
- **데이터 모델과 Phase 분리는 묻지 않고 설계해서 초안에 반영한다.** (확인은 Turn 4에서 구체물로 받는다.)
- 모든 기술 선택에 "왜 이걸 골랐는지" 근거 포함 (리서치 결과 인용). Phase별 "진짜 제품" 체크리스트(실제 배포 + 실제 데이터 + 실제 로그인) 포함. 프로젝트 스펙에 "절대 하지 마(DO NOT)" 목록 반드시 포함.
- **레퍼런스 연결 (Turn 2.5 실행 시)**: `PRD/01_PRD.md`에 `## 디자인 방향` 섹션을 추가 — 스타일 키워드 + keep한 레퍼런스 파일 경로/출처 링크 + 각 이미지에서 참고할 포인트 한 줄. "레퍼런스는 방향 합의용, 산출물에 재게시 금지" 한 줄 명시.
- 미확정 지점 처리:
  - 산출물 구조를 갈라놓는 **blocking 결정** → 질문 큐에 적립 (Turn 4 카드에 합류)
  - 그 외 → **시장 일반 관행 기준 기본값** 채택 + 가정 원장에 기록
- **가정 원장 규약**: 가정이 반영된 문서 위치마다 `> ⚠️ 가정: {내용} — 아니라면 알려주세요` 인용 블록을 넣고, `PRD/01_PRD.md` 말미에 `## 가정 원장` 섹션으로 전체 목록(번호 / 가정 내용 / 영향 문서 / 확인 여부)을 모은다.

---

## Turn 4: 확인 카드 (§A 번호 블록 1콜, ≤4문항)

초안 위치를 한 줄로 알린 뒤 즉시 카드를 출력한다. 텍스트로 문서 내용을 다시 설명하지 않는다.

한 메시지에 Q1~Q4로 묶어 출력한다:

1. **데이터 모델** — 선택지 위에 ASCII 관계도 + 핵심 필드 목록 프리뷰. 1. 좋아요 (추천) / 2. 수정할 부분 있어요 (문장으로).
2. **Phase 분리** — 선택지 위에 Phase별 기능 체크리스트 프리뷰. 1. 좋아요 (추천) / 2. 순서 변경 / 3. 합치기·나누기 (문장으로).
3~4. **가정 원장에서 틀렸을 때 영향이 큰 가정 1~2개** + Turn 3에서 적립된 blocking 큐 항목. 각각 기본값을 1번(추천)으로.

```text
초안을 PRD/ 폴더에 썼어요 (01_PRD · 02_DATA_MODEL · 03_PHASES · 04_PROJECT_SPEC · README). 확인만 부탁드려요.

(프리뷰) [User] --1:N--> [Record] --1:N--> [Tag]   ·  User: email, name / Record: date, note ...
Q1. 데이터 구조를 이렇게 잡았는데 괜찮아요?
  1. 좋아요 (추천) — 일반적인 구조라 확장하기 좋음
  2. 수정할 부분이 있어요 — 바꾸고 싶은 곳을 문장으로
(프리뷰) Phase 1: [ ] 기록 [ ] 목록 · Phase 2: [ ] 알림 [ ] 공유 · Phase 3: [ ] 통계
Q2. 이렇게 나눠서 하나씩 완성하는 걸 추천해요.
  1. 좋아요 (추천)  2. 순서를 바꾸고 싶어요  3. Phase를 합치거나 나누고 싶어요 (문장으로)
Q3. ⚠️ 가정 #2 "기록은 하루 1회"로 잡았어요.  1. 맞아요 (추천)  2. 하루 여러 번  3. 문장으로
Q4. (blocking) 팀 공유가 있나요?  1. 없음, 나만 (추천)  2. 초대 링크로 공유  3. 문장으로
(답은 "Q1-1, Q2-1, Q3-2, Q4-1"처럼. 모르면 전부 1번으로 진행할게요)
```

수정 답변은 해당 문서에 반영하고 원장의 확인 여부를 갱신한다. 수정이 연쇄적으로 커지는 경우에만(구조 변경) 추가 확인 1회를 예외 허용한다.

---

## Turn 5: 납품

교정 반영 후 마무리:
- 완성도 X/10 + 개선 포인트
- **잔여 가정 목록** — 확인받지 못한 원장 항목을 그대로 노출한다 (사용자가 나중에 훑고 고칠 수 있게. 어떤 인터뷰로도 못 잡는 잠재 항목의 유일한 방어선이다.)
- 문서 위치 + 다음 단계 가이드 (§A 번호 블록):
  1. Phase 1 바로 시작 — 이 PRD로 Phase 1 개발 시작 (시작 프롬프트 예시 제공). 골 기반 실행이 필요하면 `goaljaby` 스킬에 이 PRD 폴더를 넘기라고 안내 — 가정 원장과 `PRD/references/`는 goaljaby가 골 컨텍스트로 승계한다.
  2. SDD 도구로 넘기기 — Spec Kit 등에 PRD를 넘겨 더 상세한 구현 계획.
  3. 문서 수정 — 바꾸고 싶은 부분을 알려주세요.
- 레퍼런스 URL을 받은 경우, `insane-design` 스킬이 설치돼 있으면 그 URL로 CSS 수준 분석(analysis)이 가능함도 한 줄 안내.

완료 요약은 단순 선택 목록이 아니라 **의도+이유 중심**으로 ("로그인 제거 → 나만 쓸 거라 불필요"). 근거가 이후 개발 단계의 마이크로 결정에 반영된다.

---

## Enhancement Mode (기존 기획 보강)

유저가 기존 기획 문서를 공유한 경우:

1. 문서를 읽는다.
2. 5 파일 기준으로 갭 분석 (빠진 섹션, 모호한 부분 식별).
3. 미확정 항목을 가정 원장으로 정리 — blocking만 질문 큐에.
4. Turn 1 탐침은 생략(§2c — 이미 충분한 건 묻지 않음). 필요하면 Turn 2 카드 1콜로 방향만 확정하고 바로 보강 초안 → Turn 4 확인 카드 1콜.
5. 보강된 5 파일 생성. 기존 의도는 보존하고 구조만 템플릿에 맞춰 정규화한다.

---

## References

`$PLUGIN_ROOT/skills/show-me-the-prd/references/`:

| Reference | Purpose |
|-----------|---------|
| `interview-guide.md` | 인터뷰 방법론, 채팅 질문 설계 규칙, 바이브코더 대응 전략 |
| `document-templates.md` | 4종 문서 템플릿과 섹션 구조 |
| `domain-doc-sets.md` | 도메인별 4종 문서 동적 생성 절차 + 참고 예시 |
| `research-strategy.md` | 리서치 오케스트레이션, 도구 라우팅, 배치 전략 |
| `design-reference-guide.md` | UI 게이트 기준, 스타일 어휘 매핑, 소스 어댑터, 수집 절차, sources.json 스키마, 실패 처리 |