| name | prd |
| description | 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 재분류). |
| argument-hint | [product or agent name] | --mode design-shotgun | --mode roadmap [generate|rice|prioritize] |
| allowed-tools | ["Read","Write"] |
| model | inherit |
| hooks | {"Stop":[{"type":"command","command":"bash scripts/validate-prd.sh . 2>/dev/null || true"}]} |
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
Unified PRD 15-section 구조
상단 = 사람·문제·결정 (Section 16) → 비즈니스가 읽음
중단 = 에이전트·실행 사양 (Section 711) → 엔지니어가 읽음
하단 = 지표·가설·실패 (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 ≈ 250350 tokens, 코드 1KB ≈ 200300 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에 수동 역할 추가 필요" |
## §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이 읽음)
{
"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 로드 및 섹션 추출
ls docs/PRD.md 2>/dev/null || echo "PRD_MISSING"
PRD_MISSING 시:
❌ 에러: docs/PRD.md 없음.
/prd [제품명] 먼저 실행하세요.
즉시 종료.
§11 섹션 존재 결정론 확인 (LLM 호출 전):
grep -in "^#\+.*\(section 11\|§11\|11 —\|11\.\)" docs/PRD.md | head -3
§1도 동일하게 grep으로 확인:
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 — 출력 디렉터리 준비
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 마크업 (더미 텍스트 OK, 구조는 §11 반영)
- 색상: 회색 팔레트 (설계 결정이 아니라 레이아웃 집중)
Step 4 — comparison.md 생성
harness/design-variants/comparison.md:
# 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)
Examples (--mode design-shotgun)
Good Example
입력: --mode design-shotgun (docs/PRD.md 존재, §1·§11 있음)
기대 동작:
- PRD §1 ICP + §11 Output Spec 추출
- 4개 HTML 변형 생성 (harness/design-variants/)
- comparison.md 작성 (ICP 적합도 평가 포함)
- 완료 통계 출력
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
harness/PRD.md 또는 docs/PRD.md §6 읽기 → Now/Next/Later 항목 파싱 (결정론 grep). §6 부재 → fail loud.- 각 항목의 예상 기간을 PRD 또는 backlog에서 읽기
- Mermaid gantt 다이어그램 생성 (LLM):
- Now = 현재~4주
- Next = 4~12주
- Later = 12주+
- docs/ROADMAP.md 저장 (기존 파일 있으면 diff 기반 업데이트 제안)
sub-mode: rice
- 백로그 항목 파싱 (harness/backlog.md 또는 $ARGUMENTS)
- 각 항목에 대해 Reach/Impact/Confidence/Effort를 PM에게 물어봄 (AskUserQuestion)
- RICE 점수 공식으로 계산 (결정론 — LLM 조정 0)
- docs/rice-scores.md 저장
sub-mode: prioritize
- docs/rice-scores.md 로드 → RICE 점수 기준 정렬 (결정론)
- 임계치 기준 분류 (결정론 lookup):
- RICE > 50: Now 후보
- RICE 20-50: Next 후보
- RICE < 20: Later 후보
- 현재 PRD §6 Now/Next/Later와 비교 → 불일치 항목 표시
- PRD §6 갱신 제안 (확인 게이트 후 반영)
Quality Gate (--mode roadmap)
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 ""
