인터뷰·기능 요청을 "사람들이 해결하려는 job(과업)" 으로 재구성한다. 기능·솔루션 언어를 상황(when)·동기(want)·기대 결과(so I can) 의 job statement 로 환원하고, 근거 없는 job 은 가설로만 표기한다. 출처는 Clayton Christensen / Anthony Ulwick.

2026-06-0253

opportunity-solution-tree

kimsanguine/AI_PM

하나의 outcome 에서 출발해 opportunity → solution → experiment 로 내려가는 트리를 만든다. opportunity 는 발견된 사용자 니즈/페인(솔루션 아님)으로만 적고, solution 은 opportunity 에 매달리며, 각 solution 은 검증 실험으로 닫는다. 출처는 Teresa Torres (Continuous Discovery Habits).

2026-06-0253

working-backwards

kimsanguine/AI_PM

제품을 출시 시점의 보도자료(PR)와 FAQ 로 먼저 써서, 만들기 전에 고객 가치와 위험을 검증한다. PR 은 과장 없는 고객 언어로, FAQ 는 가장 불편한 질문부터 정직하게 답한다. 출처는 Amazon 의 Working Backwards / PR-FAQ.

2026-06-0253

competitor-battlecard

kimsanguine/AI_PM

경쟁사 3–5곳을 동일 축으로 비교한 표 + 배틀카드를 생성한다. 정량/공개 자료만 근거로 사용하고, 추측이나 미확인 정보는 한계 절에 분리한다.

2026-06-0253

discovery-synthesizer

kimsanguine/AI_PM

인터뷰 트랜스크립트·설문·사용 로그를 받아 PM 이 의사결정할 수 있는 인사이트 표로 합성한다. 빈도가 낮은 신호는 "약한 신호" 로만 표기하고 인사이트로 승격하지 않는다.

2026-06-0253

experiment-analyzer

kimsanguine/AI_PM

A/B 테스트·실험 결과 CSV/표를 받아 PM 보고용 결과 절 + ship/iterate/kill 권고를 출력한다. 가드레일 위반·표본 편향·novelty 효과를 항상 점검한다.

2026-06-0253

name	prd-generator
description	소크라틱 질문 기반 PRD 생성 — PM의 가정을 도전하고, 복수 옵션을 제시하며, 견고한 PRD를 만드는 AI PM 스킬
trigger	PRD 작성, PRD 생성, 기능 정의, 제품 요구사항, 기능 기획, feature spec
version	1
created	"2026-02-25T00:00:00.000Z"
author	Sanguine Kim (kimsanguine@gmail.com)
changelog	["2026-02-25: v1.0 초기 버전. 소크라틱 6단계 프로세스, HITL 설계, Rules 정의"]

PRD Generator Skill

"좋은 PRD는 좋은 답이 아니라, 좋은 질문에서 시작된다."

PM이 PRD를 작성할 때, AI를 '작성 도구'가 아닌 '소크라틱 질문 파트너'로 활용하여 가정을 검증하고, 복수의 솔루션 옵션을 비교하고, 견고한 PRD를 완성하는 스킬입니다.

Step 0: 맥락 수집 (Context Loading)

반드시 이 단계를 먼저 수행합니다. 스킵 금지.

다음 파일/정보를 수집합니다:

CLAUDE.md 확인 — 제품 정보, 팀 구성, 경쟁 환경, 작업 규칙
기존 PRD 히스토리 — prd/ 폴더의 이전 PRD가 있으면 스타일/깊이 참고
관련 데이터 — 유저 리서치, 실험 결과, 지표 대시보드 등 참조 가능 파일
good-examples/ — 이 폴더에 승인된 PRD 예시가 있으면 반드시 참고

사용자에게 질문:
"PRD와 관련된 유저 리서치, 실험 데이터, 또는 참고할 기존 문서가 있나요?
 있다면 @파일명으로 추가해주세요. 없으면 '없음'이라고 해주세요."

Step 1: 플랫폼/목적 확인

사용자에게 PRD의 맥락을 확인합니다.

[체크박스 — 복수 선택 가능]

이 PRD의 성격은 무엇인가요?

□ 신규 기능 (New Feature)
□ 기존 기능 개선 (Enhancement)
□ 기술 부채 해결 (Tech Debt)
□ 실험/가설 검증 (Experiment)
□ 플랫폼/인프라 (Platform)

이 PRD의 주요 독자는?

□ 엔지니어링 팀
□ 경영진/이사회
□ 디자인 팀
□ 크로스펑셔널 전체

→ 선택에 따라 PRD의 깊이와 톤을 조정합니다:

엔지니어링: 기술 고려사항 섹션 강화
경영진: Executive Summary 추가, 비즈니스 임팩트 강조
실험: 가설-검증 구조로 변환

Step 2: 소크라틱 질문 라운드 (핵심)

PRD를 바로 작성하지 않습니다. 먼저 PM의 가정을 드러내는 질문 7~10개를 던집니다.

6가지 소크라틱 질문 유형을 모두 포함합니다:

유형	질문 예시
명확화	"이 기능에서 '성공'의 정의가 정확히 무엇인가요?"
가정 탐색	"이 기능이 문제를 해결할 거라는 전제, 어떤 근거에 기반하나요?"
근거	"사용자가 이걸 원한다는 데이터는 무엇인가요?"
관점 전환	"엔지니어/디자이너/CS팀은 이것을 어떻게 볼까요?"
결과 탐색	"이 기능을 출시하면 어떤 2차 효과가 예상되나요?"
메타	"이 PRD에서 가장 중요한 판단은 무엇이고, 왜 그런가요?"

[오픈 필드]

사용자에게 각 질문에 대해 자유롭게 답변을 요청합니다.
답변이 짧거나 모호하면 추가 반론 질문 2~3개를 더 던집니다.

→ "이제 작성해줘"라고 할 때까지 질문 단계를 유지합니다.
→ PM이 "모르겠다"고 하는 부분은 PRD의 [열린 질문] 섹션에 기록합니다.

Step 3: 솔루션 옵션 제시 (반드시 3개 이상)

단일 솔루션을 바로 제시하지 않습니다. 반드시 3~5개 옵션을 제안합니다.

각 옵션에 포함할 내용:

### 옵션 A: [이름]
- **접근 방식**: 1~2문장 요약
- **장점**:
- **단점/리스크**:
- **예상 일정**:
- **임팩트 예측**: [지표] 기준 예상 개선폭
- **적합한 상황**: 이 옵션이 최선인 조건

### 옵션 B: [이름]
...

### 옵션 C: [이름]
...

옵션 비교 매트릭스도 함께 제공합니다:

| 기준        | 옵션 A | 옵션 B | 옵션 C |
|-------------|--------|--------|--------|
| 임팩트      |        |        |        |
| 구현 난이도 |        |        |        |
| 리스크      |        |        |        |
| 시간        |        |        |        |
| 추천 상황   |        |        |        |

[싱글 셀렉트]

"어떤 옵션으로 진행할까요? 또는 옵션을 조합하고 싶으시면 말씀해주세요."

Step 4: PRD 생성

선택된 옵션을 기반으로 PRD를 작성합니다.

PRD 구조:

---
type: prd
created: [날짜]
author: [PM 이름]
status: draft
priority: [p0/p1/p2]
tags: [관련 태그]
---

# [기능명] PRD

## Executive Summary
(3문장 이내: 무엇을 / 왜 / 예상 임팩트)

## 1. 문제 정의
### 사용자 문제
### 비즈니스 문제
### 현재 상태 (As-Is)
### 데이터 근거

## 2. 목표 & 성공 지표
### 핵심 지표 (OMTM)
### 보조 지표
### 가드레일 지표 (악화 방지)

## 3. 솔루션
### 선택한 솔루션
### 고려한 대안 (Step 3의 다른 옵션 요약)
### 선택 근거

## 4. 스코프
### In Scope (v1)
### Out of Scope (v2+)
### 의존성

## 5. 사용자 스토리 & 플로우
### 핵심 유저 스토리
### 핵심 플로우 (Mermaid 다이어그램)
### 엣지 케이스

## 6. 기술 고려사항
### 아키텍처 영향
### 성능 요구사항
### 보안 고려

## 7. 타임라인 & 마일스톤

## 8. 리스크 & 완화 방안

## 9. 열린 질문
(Step 2에서 PM이 "모르겠다"고 한 항목들)

## 10. 소크라틱 대화 로그
(Step 2의 질문-답변 핵심 요약 — 의사결정 맥락 보존)

Step 5: 멀티 관점 리뷰

생성된 PRD를 3가지 관점에서 자동 리뷰합니다:

🔧 엔지니어 관점: 기술 실현 가능성, 숨겨진 복잡성, 의존성 리스크
📊 경영진 관점: 비즈니스 임팩트, ROI, 전략 정합성
🔬 리서처 관점: 가정의 데이터 근거, 추가 검증 필요 항목

각 관점에서 발견한 이슈를 정리합니다:

### 리뷰 요약
| 관점 | 주요 이슈 | 심각도 | 제안 |
| --- | --- | --- | --- |
| 엔지니어 | ... | 🔴/🟡/🟢 | ... |
| 경영진 | ... | 🔴/🟡/🟢 | ... |
| 리서처 | ... | 🔴/🟡/🟢 | ... |

PM이 리뷰 결과를 반영하여 수정을 요청하면, PRD를 업데이트합니다.

Step 6: 저장 & 피드백 루프

저장

완성된 PRD를 prd/[project-name]-prd-v1.md로 저장합니다.

PM 승인 확인

[싱글 셀렉트]

이 PRD의 품질에 만족하시나요?

○ 승인 — good-example로 저장
○ 부분 수정 필요 — 수정 후 재검토
○ 방향 재설정 필요 — Step 2부터 다시

자동 아카이브

승인 시: good-examples/ 폴더에 사본 저장 (날짜_프로젝트명.md)
거부 시: bad-examples/ 폴더에 사본 + 거부 사유 저장

Rules

필수 규칙

Step 0을 절대 스킵하지 않는다 — 맥락 없는 PRD는 쓰레기다
Step 2의 질문을 생략하지 않는다 — 바로 PRD를 쓰면 안 된다
솔루션은 반드시 3개 이상 제시한다 — 단일 옵션은 판단이 아니라 수용이다
good-examples 폴더에 예시가 있으면 반드시 참고한다 — 승인된 스타일을 학습
PM이 "모르겠다"고 한 항목은 숨기지 않고 [열린 질문]에 기록한다
소크라틱 대화 로그를 PRD에 포함한다 — 의사결정의 맥락을 보존

품질 규칙

모든 주장에는 [근거] 태그를 붙인다 (데이터/리서치/가정 구분)
신뢰도 표시: 🟢 높음(데이터 기반) / 🟡 중간(유추) / 🔴 낮음(가정)
한국어로 작성하되, 기술 용어는 영문 병기
YAML front matter는 반드시 포함

자기개선 규칙

PM이 승인한 PRD는 good-examples에 자동 저장한다
PM이 거부한 PRD는 bad-examples에 거부 사유와 함께 저장한다
반복적으로 수정되는 패턴이 발견되면, 이 Rules 섹션에 새 룰을 추가한다
- 추가 시 날짜와 이유를 changelog에 기록

참고 자료

context/prd-framework.md — PRD 작성 프레임워크 상세
context/socratic-questions.md — 소크라틱 질문 유형별 가이드
5.1-definition-write-prd.md — 전체 PRD 워크스루 가이드
templates/commands/prd.md — 간단 버전 슬래시 커맨드

© 2026 김생근 (Sanguine Kim) | AI Agent Lead & AI Tutor CC BY-NC 4.0 | 교육·학술 목적 자유 이용 가능