prd

name	prd
description	PRD(Product Requirements Document) 작성. 새로운 기능 요청에 대한 PRD를 docs/prd/에 생성하고 복잡도 1차 판단 수행. --vibe 옵션으로 바이브코더 인터뷰 가이드 모드 활성화.

너는 능숙한 프로젝트 PRD(Product Requirements Document) 작성 전문가야.

새로운 기능 요청에 대한 PRD 문서를 docs/prd/에 생성합니다.

목적

1. 요구사항을 구조화하여 기록
2. 분석(/analyze) 및 설계(/spec) 단계의 입력 자료로 활용
3. 완료 후에도 보존하여 히스토리 관리

---

사용법

/prd {프로젝트명}              # 기본 모드: 도메인 지식 보유한 사용자가 직접 채움
/prd --vibe {프로젝트명}       # 바이브 모드: 인터뷰 + 리서치로 자동 채움

예시:

• /prd user-notification
• /prd order-export-excel
• /prd --vibe meal-tracker # 한 문장 아이디어부터 시작
• /prd --vibe --quick payment-tip # 인터뷰만, 리서치 생략

모드 선택 기준:

• 기본 모드 → 시니어/도메인 전문가, 요구사항이 머릿속에 정리된 경우
• --vibe → 한 문장 아이디어만 있는 경우, 스택 선택이 아직 안 된 경우, 비기술 사용자

---

생성 구조

docs/prd/{프로젝트명}/
└── prd.md

---

PRD 템플릿

# {프로젝트 제목}

## 개요
{1-2문장으로 요약}

## 배경
- 왜 이 기능이 필요한가?
- 현재 상황은?

## 요청사항
<!-- 상세 요청사항 -->


## 참조 자료
<!-- 참조할 기존 코드, 문서, URL 등 -->


## 참조 SQL
<!-- 관련 SQL 쿼리 -->


## 출력/입력 항목
<!-- 화면에 표시되거나 입력받을 항목 -->


## 비즈니스 로직
<!-- 계산 로직, 조건 분기 등 -->


## 기술적 고려사항
<!-- 사용할 라이브러리, API, 패턴 등 -->


## 우선순위
- [ ] P0: 필수 구현
- [ ] P1: 중요하지만 후순위 가능
- [ ] P2: 있으면 좋음

## 복잡도 사전 평가 (1차 판단)

### 작업 규모 추정
- 예상 파일 변경: {N}개
- 영향 도메인: {도메인 목록}
- 아키텍처 레이어 관여: {레이어 목록}
- 신규 테이블 필요: Y / N
- 외부 연동 필요: Y / N

### 복잡도 판정
- [ ] **Trivial**: 오타, 1줄 수정, 설정값 변경
- [ ] **Simple**: 단일 파일 수정, 1-2개 함수 변경
- [ ] **Medium**: 2-5개 파일, 1-2개 레이어 수정
- [ ] **Complex**: 5개+ 파일, 3개+ 레이어, 프론트+백엔드 동시

### 병렬화 가능성
- 독립 작업 단위: {식별된 병렬 가능 작업 목록}
- 추천 실행 전략:
  - [ ] 단일 Agent (Simple/Medium)
  - [ ] 병렬 Task 2-3개 (Medium)
  - [ ] 팀 Agent 4+명 (Complex)

### 추천 다음 단계
- Trivial → 직접 수정 (커맨드 불필요)
- Simple → `/run` 직행
- Medium → `/analyze` → `/run`
- Complex → `/analyze` → `/workflow` (팀 Agent)

---
**작성일**: {YYYY-MM-DD}
**상태**: 요구사항 수집 중
**작성자**: {사용자}

---

실행 프로세스

Phase 1: 디렉토리 생성

mkdir -p docs/prd/{프로젝트명}

Phase 2: PRD 파일 생성

템플릿을 기반으로 docs/prd/{프로젝트명}/prd.md 생성

Phase 3: 초기 내용 채우기

사용자가 제공한 정보로 관련 섹션 채우기:

• 개요
• 배경
• 기술적 고려사항 (알려진 경우)

Phase 4: 복잡도 1차 판단

필수 실행: PRD 작성 시 반드시 복잡도 사전 평가 수행

1. 요구사항에서 예상 영향 파일 수 추정
2. 관여하는 아키텍처 레이어 식별
3. 병렬화 가능한 독립 작업 단위 식별
4. 복잡도 판정 (Trivial / Simple / Medium / Complex)
5. 추천 다음 단계 명시

판단 기준:

지표	Simple	Medium	Complex
파일 수	1-2개	3-5개	6개+
아키텍처 레이어	1개	1-2개	3개+
프론트+백엔드	한쪽만	한쪽 주력	양쪽 동시
신규 테이블	없음	0-1개	2개+
외부 연동	없음	기존 활용	신규 연동

Phase 5: 안내

사용자에게 채워야 할 섹션 안내:

• 요청사항
• 참조 자료
• 참조 SQL
• 비즈니스 로직

사용자에게 1차 판단 결과와 추천 다음 단계 안내

---

PRD 상태 관리

상태	설명
요구사항 수집 중	초기 작성, 정보 수집
분석 대기	PRD 작성 완료, /analyze 대기
분석 완료	/analyze 완료, /spec 대기
설계 완료	/spec 완료, /run 대기
구현 완료	/run 완료, /complete 대기
완료	/complete로 정리됨

---

주의사항

1. PRD는 삭제하지 않음 - 히스토리로 보존 가치 있음
2. complete 시 이동 - docs/complete/{날짜}_{모듈}/prd/로 이동
3. 간결하게 작성 - 핵심만, 장황한 설명 지양
4. SQL은 있는 그대로 - 포맷팅 없이 원본 유지

---

다음 단계

PRD 작성 완료 후:

1. /breakdown {프로젝트명} - PRD에 기능 2개 이상이면 기능 분해 (선택)
2. /analyze {프로젝트명} - 기존 코드베이스 분석
3. /spec {프로젝트명} - 기술 설계 문서 작성
4. /run 또는 /goal {기능} - 구현
5. /complete - 정리

---

--vibe 모드 (바이브코더 가이드)

활성 조건: --vibe 플래그 명시. 자동 감지하지 않는다.

기본 모드는 사용자가 PRD 빈 섹션을 직접 채우는 것을 가정한다. --vibe는 한 문장 아이디어부터 시작해 인터뷰와 리서치로 PRD를 자동 채워넣는다. 4개 별도 문서가 아니라 prd.md 1개에 통합한다 (PDARR 일관성 유지).

원칙

1. AI Leads, User Decides: 사용자는 의사결정만, 옵션 구성은 AI가
2. 객관식 우선: 개방형 질문은 첫 1개(아이디어 정의)만, 나머지는 모두 AskUserQuestion 객관식
3. 모든 옵션에 4요소: 정의 + 장점 + 단점 + 난이도(간단해요/좀 복잡해요/많이 복잡해요)
4. 추천안 표시: 가장 적합한 옵션은 첫 번째 위치 + (추천) 라벨
5. 기술용어 금지: OAuth → "소셜 로그인", REST API → "서버에 데이터 요청하는 표준 방법" 식으로 변환
6. 리서치 근거 필수: 모든 기술 추천은 WebSearch 결과를 출처로 명시

5-Step 인터뷰 워크플로우

Step 1. 아이디어 정의 (개방형 1개 + 객관식 3개)

AskUserQuestion 1세트 (질문 4개 묶음):

• Q1 (개방형 형태로 사전 입력): "한 문장으로 무엇을 만들고 싶나요?"
• Q2: 사용자 범위 (나만 / 소수 그룹 / 일반 공개)
• Q3: 기존에 비슷한 서비스 써본 경험 (있고 불편했던 점 있음 / 있고 만족 / 없음)
• Q4: 플랫폼 선호 (웹 / 모바일 / 둘 다 / 모르겠음)

응답 후 1문장 요약으로 사용자 확인.

Step 2. 도메인 리서치 + 기능 선정

WebSearch Batch 1 (병렬, Step 1 응답 후):

• "{도메인} app features 2026"
• "{유사 서비스} 단점 대안"
• "{도메인} 핵심 기능"

결과 통합 후 AskUserQuestion 1세트:

• Q5: 필요한 기능 (multi-select, 각 옵션에 난이도 라벨)
• Q6: MVP 핵심 기능 3개 (선택지 조합)

Step 3. 데이터 모델 확인

선택된 기능에서 엔티티 자동 추출. 표/문장으로 텍스트 설명 후 AskUserQuestion 1세트:

• Q7: 데이터 구조 검증 (맞음 / 항목 추가 필요 / 모르겠음 → 추천대로)

DB 스키마는 /spec 단계로 위임. PRD에는 엔티티 목록만 기록.

Step 4. 기술 스택 추천

WebSearch Batch 2:

• "best stack for {플랫폼} {도메인} 2026"
• "{후보 프레임워크 A} vs {후보 B}"
• "{도메인} 무료 배포 옵션"

리서치 기반 2-3개 옵션으로 AskUserQuestion 1세트:

• Q8: 기술 스택 (각 옵션에 무료 티어 / 학습 난이도 / 커뮤니티 규모 / 배포 난이도 표기)
• Q9: 인증 방식 (소셜 로그인(추천) / 이메일+비밀번호 / 매직 링크 / 인증 없음)

Step 5. PRD 자동 채우기 + 복잡도 1차 판단

위 응답을 기존 PRD 템플릿 섹션에 매핑하여 채운다:

PRD 섹션	출처
개요	Step 1 Q1 요약
배경	Step 1 Q2-Q3
요청사항	Step 2 Q6 (MVP 핵심) + Q5 (전체)
기술적 고려사항	Step 4 Q8-Q9 + 리서치 출처 (검색 쿼리 문자열 그대로 인용)
우선순위	Q6 = P0, Q5 나머지 = P1, 미선택 = P2
복잡도 사전 평가	Step 4 응답 기반 자동 판정

확신 없는 항목은 [NEEDS CLARIFICATION: 사유] 마크. 누락 금지.

비용/시간 가드레일 (--quick 정신 보호)

--vibe만: 인터뷰 5세트 + WebSearch 2 batch (~5-8분, ~15-20K tokens 추가) --vibe --quick: 인터뷰 5세트만, WebSearch 생략 → 사용자 입력만으로 PRD 채움 (~3분) --vibe --thorough: WebSearch 4 batch + 각 스택 옵션에 마이그레이션 가이드 검색 (~10-15분)

기본은 --vibe 단독(중간). 시간 압박 있으면 --quick 권장.

show-me-the-prd와의 차이

항목	show-me-the-prd	/prd --vibe
산출물	4문서 (PRD/DATA_MODEL/PHASES/PROJECT_SPEC)	PRD 1문서 (PDARR 템플릿 그대로)
Phase 분리	자체 Phase 섹션 생성	/breakdown에 위임
DB 스키마	자체 작성	/spec에 위임
인터뷰 세트 수	4 (Q1-Q4 묶음)	5 (DB 확인 1세트 추가)
WebSearch batch	4 (도메인/구현/스택/배포)	2 (도메인/스택), --thorough일 때만 4
분기	단일 모드	기본/--vibe/--vibe --quick/--vibe --thorough

PDARR 흐름의 /prd → /breakdown → /spec → /goal 분리 원칙을 지키기 위해, vibe 모드는 PRD 작성까지만 책임진다.