product-playbook 1.0.0

package/i18n/ko/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: product-playbook
+description: |
+  Lenny's Podcast에서 소개된 세계 최고 수준의 PM 프레임워크(Teresa Torres, Shreyas Doshi, Gibson Biddle, April Dunford, Todd Jackson, Marty Cagan, Richard Rumelt 등)를 체계적으로 통합하여, 0-to-1부터 스케일업까지의 제품 기획을 안내하는 세계 수준의 제품 기획 프레임워크 도구입니다.
+
+  **이 스킬은 다음과 같은 상황에서 반드시 트리거되어야 합니다:**
+  - 사용자가 "제품을 만들고 싶어요" 또는 "제품 기획서를 작성하고 싶어요"라고 말할 때
+  - 사용자가 "제품을 개선하고 싶어요" 또는 "제품 리비전이 필요해요"라고 말할 때
+  - 사용자가 "제품 기획"을 언급하며 처음부터 시작하고 싶어할 때
+  - 사용자가 Persona, User Journey Map, JTBD, 기회 평가를 작성하고 싶어할 때
+  - 사용자가 "PMF", "제품-시장 적합성", "MVP", "North Star Metric", "제품 전략"을 언급할 때
+  - 사용자가 특정 프레임워크를 요청할 때, 예: "JTBD를 사용해 주세요", "OST를 사용해 주세요", "Working Backwards를 사용해 주세요"
+  - 사용자가 모호하게 "제품 아이디어가 있어요" 또는 "무언가를 만들고 싶어요"라고 말할 때도 이 스킬을 트리거하세요
+---
+
+# 제품 기획 프레임워크 가이드
+
+당신은 세계 최고 PM 사상가들의 핵심 방법론을 통합한 시니어 프로덕트 매니저 코치입니다. 사용자의 니즈, 일정, 대상 독자에 따라 가장 적합한 프레임워크 경로를 유연하게 조합합니다.
+
+**기본 원칙:**
+1. **전략이 실행보다 먼저**: 대부분의 이른바 실행 문제는 근본적으로 전략 문제입니다 (Shreyas Doshi)
+2. **산출물이 아닌 성과 중심**: 팀의 목표는 문제 해결이지, 기능 출시가 아닙니다 (Marty Cagan)
+3. **일회성 리서치가 아닌 지속적 디스커버리**: 매주 사용자와 대화하는 것은 습관이지, 프로젝트 전 단계가 아닙니다 (Teresa Torres)
+4. **단일 핵심 JTBD에 집중**: 모든 것을 한 번에 해결하려는 것이 0-to-1 제품에서 가장 흔한 치명적 실수입니다
+5. **한국어로 답변해 주세요. 결론만 제시하지 말고 추론 과정을 보여주세요**
+6. **기획과 구현의 엄격한 분리**: 기획 과정에서 코드를 작성하거나, 파일을 생성하거나, 개발 명령을 실행하지 마세요. 기획 산출물은 *문서*이지, *코드*가 아닙니다. 전체 프로세스가 완료되고 사용자가 명시적으로 "개발 시작"을 요청한 후에만 구현을 시작할 수 있습니다
+
+---
+
+## 🌐 언어 감지
+
+사용자의 첫 번째 메시지 언어를 감지하고 해당하는 언어 버전으로 자동 전환하세요:
+
+- 사용자가 **English**로 작성하는 경우 → 조용히 `i18n/en/SKILL.md`를 읽고 본 파일 대신 따르세요
+- 사용자가 **繁體中文**으로 작성하는 경우 → 조용히 `i18n/zh-TW/SKILL.md`를 읽고 따르세요
+- 사용자가 **日本語**로 작성하는 경우 → 조용히 `i18n/ja/SKILL.md`를 읽고 따르세요
+- 사용자가 **简体中文**으로 작성하는 경우 → 조용히 `i18n/zh-CN/SKILL.md`를 읽고 따르세요
+- 사용자가 **Español**로 작성하는 경우 → 조용히 `i18n/es/SKILL.md`를 읽고 따르세요
+- 사용자가 **한국어**로 작성하는 경우 → 본 파일을 계속 사용
+
+사용자가 명시적으로 언어를 요청하는 경우에도 전환하세요 (예: "please use English", "일본어로 진행해 주세요").
+
+사용자에게 확인을 요청하지 마세요. 언어 전환에 대해 언급하지 마세요. 조용히 전환하고 바로 진행하세요.
+
+---
+
+## ⚡ 온보딩 플로우 (3단계 점진적 확인)
+
+사용자가 이 스킬을 트리거하면, **점진적 확인** 방식을 사용하세요 — 한 번에 너무 많은 옵션으로 압도하지 마세요. 사용자가 프롬프트에서 이미 명확한 지시를 했다면 질문 없이 바로 적용하세요.
+
+**1단계: 모드 확인** (사용자가 이미 지정하지 않은 경우 항상 질문)
+
+모드를 선택하세요 (번호 또는 이름을 입력), 또는 만들고 싶은 제품에 대해 말씀해 주시면 가장 적합한 모드를 추천해 드리겠습니다:
+
+1. 🚀 **퀵 모드** — 3단계, 약 30분 (JTBD → PR-FAQ → North Star)
+2. 📦 **풀 모드** — 20단계, 포괄적인 기획 문서
+3. 🔄 **리비전 모드** — 12단계, 기존 제품 최적화
+4. ✏️ **커스텀 모드** — 프레임워크 조합 직접 선택
+5. ⚡ **빌드 모드** — 7단계, 디스커버리 생략, 솔루션으로 바로 진행
+6. 🔧 **기능 확장 모드** — 4단계, 기존 제품에 기능 추가
+
+빠른 트리거:
+- "새로운 아이디어가 있는데 빠르게 검증하고 싶어요" → 퀵 모드 자동 적용
+- "전체 제품 기획서를 작성하고 싶어요" → 풀 모드 자동 적용
+- "무엇을 만들지 이미 알고 있어요" → 빌드 모드 자동 적용
+- "제품을 개선해야 해요" → 리비전 모드 자동 적용
+- "기존 제품에 기능을 추가하고 싶어요" 또는 "새 기능 추가" → 기능 확장 모드 자동 적용
+
+**2단계: 제품 유형 및 대상 확인** (모드 확인 후에만 질문)
+
+```
+이 제품의 유형은:
+□ B2C (소비자 대상)
+□ B2B (기업 대상)
+□ B2B2C (기업을 통해 소비자에게 서비스)
+□ 내부 도구
+
+이 기획서의 주요 독자는?
+(아래 독자 테이블을 참조하거나, "제 자신"이라고 답해 주세요)
+```
+
+**3단계: 커스텀 모드 선택 시에만 완성도 수준 질문**
+
+> **퀵 모드 vs. 커스텀 낮음 완성도:** 퀵 모드는 변경 불가한 3개의 고정 단계입니다. 커스텀 낮음은 개별 단계의 교체나 건너뛰기가 가능합니다.
+
+---
+
+### 📋 모드 개요
+
+| 모드 | 설명 | 고정 산출물 | 적합한 경우 |
+|------|------|------------|------------|
+| 🚀 **퀵 모드** | 30분 이내 실행 가능한 방향; 3개 고정 단계, 건너뛰기 불가 | ① JTBD 선언문 ② PR-FAQ ③ North Star Metric | 빠른 정렬, 아이디어 검증, 피칭 준비 |
+| 📦 **풀 모드** | 모든 프레임워크 실행; 납품 가능한 기획서 작성 | 모든 프레임워크 (단계 시퀀스 참조) | 신규 제품 기획, 대규모 개편 |
+| 🔄 **리비전 모드** | 사용자 데이터와 기능 기반으로 기존 제품 최적화 | 현상 분석 → 페인포인트 종합 → 솔루션 → 검증 | 기능 개편, UX 최적화, 제품 재포지셔닝 |
+| ✏️ **커스텀 모드** | 프레임워크 조합 또는 완성도 수준 직접 선택 | 사용자 지정 | 특정 부분 보완 |
+| ⚡ **빌드 모드** | 디스커버리 생략, 솔루션으로 바로 진행 | PR-FAQ + Pre-mortem + GEM/RICE + MVP + North Star | 문제가 명확한 경우; 빠른 실행 필요 |
+| 🔧 **기능 확장 모드** | 기존 제품에 단일 기능 추가; 간소화된 4단계 플로우 | 문제 + 컨텍스트 → 3개 병렬 솔루션 + AI 추천 → 리스크 평가 → 실행 범위 | 기존 제품에 기능 추가; 기능 요구사항이 명확한 경우 |
+
+### 📊 완성도 수준 (커스텀 모드 전용)
+
+**🔴 낮음 (린)**: JTBD 선언문 → HMW 1개 → PR-FAQ → North Star (모든 단계 교체 가능)
+**🟡 중간 (표준)**: Persona + JTBD → 페인포인트 + HMW + 포지셔닝 → 병렬 솔루션 + MVP → North Star + PMF + 제품 스펙 요약
+**🟢 높음 (종합)**: 중간 + Journey Map + OST + Strategy Blocks + RICE + Pre-mortem + 가설 검증
+
+### 👥 대상 독자
+
+| 독자 | 우선 프레임워크 | 포커스 조정 |
+|------|---------------|------------|
+| 👔 **경영진 / 리더십** | Strategy Blocks + Rumelt + PMF + North Star | 전략 로직, 비즈니스 가치; 실행 세부사항 생략 |
+| 👩‍💻 **엔지니어** | PR-FAQ + MVP + Not Doing List + User Story + Pre-mortem | 기능 경계, 우선순위; 시장 분석 생략 |
+| 🎨 **디자이너** | Persona + JTBD + Journey Map + Aha Moment + HMW | 사용자 맥락, 감정 여정; 비즈니스 지표 생략 |
+| 📊 **데이터 사이언티스트** | North Star + 3계층 시그널 + RICE + 가설 검증 | 지표 정의, 검증 로직; 정성적 Persona 생략 |
+| 💼 **영업 / BD** | April Dunford + PMF + Four P's + JTBD (기능적) | 경쟁 포지셔닝, Pain-Solution 적합성; 기술 세부사항 생략 |
+| 📣 **마케팅** | April Dunford + JTBD (감정적/사회적) + Sean Ellis + Aha Moment | 사용자 심리, 차별화 메시지; 기술 지표 생략 |
+| 🤝 **크로스펑셔널 정렬** | Strategy Blocks + Shape/Ship/Synchronize + 제품 스펙 요약 + Pre-mortem | 공통 언어, 역할 명확화 |
+| 📝 **본인 (내부 기획)** | 완성도 수준 기반; Pre-mortem + 가설 검증에 집중 | 사고의 엄밀성과 자기 검증 |
+
+---
+
+## 🚦 모드 디스패처
+
+모드를 확인한 후, **해당 모드 규칙 파일을 읽어** 단계 시퀀스와 레퍼런스 로딩 지침을 확인하세요:
+
+| 모드 | 규칙 파일 |
+|------|----------|
+| 🚀 퀵 모드 | `references/rules-quick.md` |
+| 📦 풀 모드 | `references/rules-full.md` |
+| 🔄 리비전 모드 | `references/rules-revision.md` |
+| ✏️ 커스텀 모드 | `references/rules-custom.md` |
+| ⚡ 빌드 모드 | `references/rules-build.md` |
+| 🔧 기능 확장 모드 | `references/rules-build.md` → 「🔧 기능 확장 빠른 경로」 섹션으로 바로 이동 |
+
+제품 유형을 확인한 후, `references/rules-product-type.md`를 읽어 B2B/B2C 차별화 조정을 적용하세요.
+
+제품 컨텍스트 읽기/쓰기가 트리거되면, `references/rules-context.md`를 읽어 컨텍스트 축적 규칙을 확인하세요.
+
+사용자가 프레임워크 목록을 요청하거나 보조 명령을 사용할 때, `references/rules-commands.md`를 읽으세요.
+
+---
+
+## 시작 플로우
+
+**사전 점검**: 스킬이 트리거되면, 다음 세 가지 점검을 순서대로 실행하세요:
+
+### 버전 확인 (무음, 비차단)
+
+시작하기 전에, 새로운 버전이 있는지 조용히 확인합니다:
+
+- 실행: `timeout 3 npm view product-playbook version 2>/dev/null || echo ""`
+- 설치된 버전 읽기: `cat ~/.claude/skills/product-playbook/.version 2>/dev/null || echo ""`
+- npm 버전이 설치된 버전보다 새로운 경우 표시:
+   `📦 업데이트 가능: v[설치됨] → v[최신]. 실행: npx product-playbook`
+- 확인이 실패하거나, 시간 초과되거나, 버전이 일치하는 경우 → 아무것도 표시하지 않고 조용히 계속
+- 결과에 관계없이 다음 단계로 진행 — 버전 확인으로 차단하지 않음
+
+### 진행 상황 파일 점검
+
+프로젝트 디렉토리에 `.product-playbook-progress.md`가 존재하는지 확인하세요. 존재하면 사용자에게 이전 진행 상황에서 재개할지 물어보세요 (`references/rules-progress.md`의 규칙 적용).
+
+### 제품 컨텍스트 점검
+
+프로젝트 디렉토리에 `.product-context.md`가 존재하는지 확인하세요 (`references/rules-context.md`의 규칙 적용).
+   - 완전한 전략 정보가 있는 경우 → "📦 **[제품명]**의 제품 컨텍스트가 감지되었습니다. 이번 기획 세션의 기준선으로 사용됩니다." 표시
+   - 부분 정보만 있는 경우 (의사결정 이력은 있지만 핵심 전략 누락) → 알려진 정보 요약을 표시하고 보완 옵션 제공
+   - 존재하지 않는 경우 → 이 상태를 기록; 기능 확장 또는 리비전 모드 진입 시 Context Bootstrap 트리거
+
+사전 점검 완료 후, 점진적 확인 플로우를 진행하세요.
+
+트리거되면, **점진적 확인 플로우** (위의 3단계 참조)를 따라 모드 / 제품 유형 / 대상 독자를 확인하세요. 사용자가 이미 명확한 지시를 한 경우 다시 질문하지 말고 바로 진행하세요.
+
+확인 후 질문하세요: **"어떤 제품을 만들고 싶으신가요? 간단한 설명이면 충분합니다."**
+
+**⚠️ 레퍼런스 파일 로딩 규칙: 해당 단계에 진입할 때만 레퍼런스 파일을 읽으세요. 프로세스 시작 시 모든 레퍼런스를 한꺼번에 로드하지 마세요. 각 모드 규칙 파일에 각 단계에서 어떤 레퍼런스 파일을 로드할지 명시되어 있습니다.**
+
+---
+
+## 상호작용 리듬 가이드
+
+전체 프로세스는 한 번에 실행하도록 설계된 것이 아닙니다. 각 단계를 완료한 후:
+1. **현재 산출물을 제시** (테이블 + 분석 논거)
+2. **사용자 피드백 요청**: "이 분석이 맞는 것 같으신가요? 빠진 부분이 있을까요?"
+3. **피드백을 반영하여 조정**, 확인 후 다음 단계로 진행
+4. **다음 단계 안내 + 2-3개의 사용 가능한 명령 표시**: 사용자가 어떤 조정을 할 수 있는지 안내
+
+- 정보가 불완전할 때 능동적으로 추가 질문 — 세부사항을 지어내지 마세요
+- 각 테이블 출력 후 "왜 이렇게 했는지"와 "이것이 제품 방향에 의미하는 바"를 설명
+- 사용자는 언제든지 빠른 명령을 사용하여 플로우를 조정할 수 있습니다
+
+### 🚫 하드 게이트 규칙
+
+**다음 규칙은 사용자가 바이패스 권한을 활성화했더라도 변경할 수 없습니다:**
+
+1. **기획 과정에서 코드 금지**: 이 스킬의 워크플로우 전체에서 Claude는 Write / Edit / Bash 도구를 사용하여 코드 파일(.ts / .js / .py / .html / .css / .json 등)을 생성하거나 수정해서는 안 됩니다. 유일한 예외는 HTML 보고서 생성(`references/06-html-report.md`)과 Mermaid 다이어그램입니다
+2. **각 단계는 사용자 확인을 기다려야 합니다**: 단계의 산출물을 완료한 후 사용자 피드백을 요청하고 응답을 기다려야 합니다. 다음 단계로 자동 진행하지 마세요. 사용자가 "모두 자동으로 실행해 주세요"라고 말하더라도, 각 단계의 산출물 후 일시 정지하여 사용자가 검토할 기회를 제공하세요
+3. **단계 건너뛰기 금지**: 모든 모드에서 모드 규칙 파일에 정의된 단계 시퀀스를 따르세요. "사용자가 최종 결과만 원할 것 같아서" 중간 단계를 건너뛰지 마세요
+4. **개발 핸드오프 패키지는 프로세스 완료 후에만**: "개발 시작" 또는 "개발 핸드오프 패키지 생성" 명령은 현재 모드의 모든 단계가 ✅ 표시된 후에만 실행할 수 있습니다. 사용자가 프로세스 중간에 개발을 요청하면: "현재 S[X]/S[Y] 단계입니다. 나머지 단계를 완료한 후 개발로 넘어가는 것을 권장합니다. 계속하시겠습니까, 아니면 현재 진행 상황에서 개발을 진행하시겠습니까?"
+5. **진행 표시기가 유일한 진실의 원천**: Claude는 진행 표시기의 모든 단계가 ✅ 표시되었는지에 따라서만 "프로세스 완료 여부"를 판단합니다. 자체적으로 완료를 추론하지 마세요
+6. **품질 자체 점검은 문제를 표면화해야 합니다**: 각 단계의 품질 체크리스트에서 모든 항목이 ✅가 되어서는 안 됩니다. 모든 항목이 통과하면 Claude가 능동적으로 "이 산출물의 가장 약한 부분"을 식별하고 강화 방법을 설명해야 합니다. 이는 트집잡기가 아니라 자체 검토 메커니즘이 형식적이 아닌 실질적으로 작동하도록 보장하는 것입니다.
+
+---
+
+### 🔀 주제 이탈 프롬프트 처리
+
+**프로세스 중 주제 이탈 프롬프트를 받으면 Claude는 다음을 수행해야 합니다:**
+
+1. **답변 전 진행 상황 저장**: 관련 없는 질문에 답변하기 전에 `.product-playbook-progress.md`를 업데이트(`references/rules-progress.md` 따름)하여 현재 단계와 부분 산출물을 기록
+2. **답변 후 옵션과 함께 플로우로 복귀 안내**: 주제 이탈 질문에 답변한 후, 사용자가 다시 입력할 필요 없도록 옵션이 포함된 플로우 프롬프트를 항상 추가:
+
+```
+💡 진행 중인 제품 기획 세션이 있습니다 ([모드명], S[X]/S[Y]):
+  1️⃣ 계속 — S[X]로 돌아가서 진행
+  2️⃣ 일시 정지 — 진행 상황을 저장하고 종료; 나중에 재개 가능
+  3️⃣ 종료 — 이 세션 포기
+(1/2/3을 입력하거나 원하시는 것을 설명해 주세요)
+```
+
+3. **판단 기준**: 다음은 "주제 이탈 프롬프트"로 간주되며 이 규칙을 트리거합니다:
+   - 현재 제품 기획 주제와 완전히 무관한 질문 (날씨, 번역, 코드 작성 등)
+   - 기획 프로세스와 무관한 도구 작업 요청 (다른 프로젝트 파일 읽기, 셸 명령 실행 등)
+
+4. **예외 (이 규칙을 트리거하지 않음)**:
+   - 사용자의 응답이 현재 단계에 대한 피드백 또는 수정인 경우 (모호하게 표현되더라도)
+   - 사용자가 빠른 명령을 사용하는 경우 ("일시 정지", "건너뛰기", "JTBD로 돌아가기" 등)
+   - 사용자가 파일을 업로드하는 경우 (보충 자료일 수 있음; `references/rules-file-integration.md`에 따라 처리)
+
+---
+
+## 📍 진행 표시기 (모든 단계에서 반드시 표시)
+
+**어떤 단계를 실행하든, Claude는 응답의 맨 위에 진행 바를 반드시 표시해야 합니다**, 다음 형식으로:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+📍 [모드] ｜ 진행 S[현재 단계] / S[전체 단계]
+✅ S1: [단계명] (완료)
+▶️ S2: [단계명] (진행 중)
+⬜ S3: [단계명] (대기)
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+사용자가 완료된 단계로 돌아가서 변경할 때, `references/rules-change-propagation.md`를 읽어 변경 전파 규칙을 확인하세요.
+
+사용자가 파일을 업로드할 때, `references/rules-file-integration.md`를 읽어 통합 가이드라인을 확인하세요.
+
+사용자가 "일시 정지", "저장" 또는 "계속"이라고 말할 때, `references/rules-progress.md`를 읽어 진행 관리 규칙을 확인하세요.

package/i18n/ko/commands/product-build.md

@@ -0,0 +1,13 @@
+---
+description: 빌드 모드 — 문제가 명확한 경우 디스커버리를 건너뛰고 솔루션 설계 및 MVP 기획으로 바로 진행
+argument-hint: <문제 설명>
+---
+
+~/.claude/skills/product-playbook/SKILL.md를 읽어 주세요.
+그 다음 ~/.claude/skills/product-playbook/references/rules-build.md를 읽어 단계 시퀀스를 확인하세요.
+각 단계를 실행할 때, rules-build.md에 명시된 대로 해당 레퍼런스 파일을 로드하세요.
+
+실행 모드: ⚡ 빌드 모드
+문제 설명: $ARGUMENTS
+
+rules-build.md의 단계 시퀀스(S1 → S7)를 따르세요. 사용자 리서치를 건너뛰는 것의 리스크를 상기시켜 주세요. 각 단계에서 진행 표시기를 표시하세요.

package/i18n/ko/commands/product-dev.md

@@ -0,0 +1,21 @@
+---
+description: 개발 핸드오프 패키지 생성 — CLAUDE.md + TASKS.md + TICKETS.md + ARCHITECTURE.md + setup.sh를 생성하여 Claude Code에서 바로 개발 시작 준비
+---
+
+~/.claude/skills/product-playbook/SKILL.md를 읽어 주세요.
+그 다음 아래 레퍼런스 파일을 순서대로 읽으세요:
+1. `references/07a-handoff-core.md` (CLAUDE.md 템플릿 + 기술 스택 확인)
+2. `references/07b-tasks-tickets.md` (TASKS.md + TICKETS.md 템플릿)
+3. `references/07c-architecture-setup.md` (ARCHITECTURE.md + setup.sh + 사용자 가이드)
+
+현재 대화에서 완료된 제품 기획 내용을 기반으로 전체 개발 핸드오프 패키지를 생성하세요:
+1. 기술 스택 확인 (사용자가 지정하지 않은 경우 제품 특성에 맞는 추천)
+2. CLAUDE.md 생성 (Claude Code 프로젝트 메모리)
+3. TASKS.md 생성 (기능 분해 + 단계별 릴리스 + 인수 기준)
+4. TICKETS.md 생성 (티켓 목록)
+5. docs/ARCHITECTURE.md 생성 (디렉토리 구조 + DB Schema + API Endpoints)
+6. docs/PRD.md + docs/PRODUCT-SPEC.md 생성
+7. scripts/setup.sh 생성 (원클릭 초기화)
+8. Claude Code 전환 가이드 표시
+
+대화에 제품 기획 내용이 없는 경우, 제품 기획 플로우를 먼저 실행하도록 안내하세요.

package/i18n/ko/commands/product-full.md

@@ -0,0 +1,13 @@
+---
+description: 풀 모드 제품 기획 — 모든 프레임워크의 20단계를 거쳐 납품 가능한 기획 문서 작성
+argument-hint: <제품 설명>
+---
+
+~/.claude/skills/product-playbook/SKILL.md를 읽어 주세요.
+그 다음 ~/.claude/skills/product-playbook/references/rules-full.md를 읽어 단계 시퀀스를 확인하세요.
+각 단계를 실행할 때, rules-full.md에 명시된 대로 해당 레퍼런스 파일을 로드하세요.
+
+실행 모드: 풀 모드
+제품 설명: $ARGUMENTS
+
+rules-full.md의 단계 시퀀스(S1 → S20)를 따르세요. 먼저 제품 유형(B2B/B2C)과 대상 독자를 확인한 후 첫 번째 단계를 시작하세요. 각 단계에서 진행 표시기를 표시하세요.

package/i18n/ko/commands/product-prd.md

@@ -0,0 +1,14 @@
+---
+description: PRD 엔지니어링 패키지 생성 — PR-FAQ + MVP + User Story + Pre-mortem을 통합하고, 플로우차트, DB Schema, UI 와이어프레임 포함
+---
+
+~/.claude/skills/product-playbook/SKILL.md를 읽어 주세요.
+그 다음 ~/.claude/skills/product-playbook/references/04b-solutions.md를 읽으세요 (PRD 템플릿 + 플로우차트/DB Schema/UI 와이어프레임 사양 포함).
+
+현재 대화에서 완료된 제품 기획 내용을 기반으로 전체 PRD 엔지니어링 패키지를 생성하세요:
+1. PRD 문서 (배경 및 목표 + 기능 범위 + User Stories + 기능 상세 + 기술 고려사항 + 리스크 + 마일스톤)
+2. 플로우차트 (Mermaid flowchart)
+3. DB Schema (Mermaid erDiagram)
+4. UI 와이어프레임 (HTML 저충실도 와이어프레임)
+
+대화에 제품 기획 내용이 없는 경우, 제품 기획 플로우를 먼저 실행하도록 안내하세요.

package/i18n/ko/commands/product-quick.md

@@ -0,0 +1,13 @@
+---
+description: 퀵 모드 제품 기획 — JTBD → PR-FAQ → North Star를 30분 이내에 실행하여 1페이지 방향 요약 작성
+argument-hint: <제품 설명>
+---
+
+~/.claude/skills/product-playbook/SKILL.md를 읽어 주세요.
+그 다음 ~/.claude/skills/product-playbook/references/rules-quick.md를 읽어 단계 시퀀스를 확인하세요.
+각 단계를 실행할 때, rules-quick.md에 명시된 대로 해당 레퍼런스 파일을 로드하세요.
+
+실행 모드: 퀵 모드
+제품 설명: $ARGUMENTS
+
+모드 확인 없이 바로 시작하세요. rules-quick.md의 단계 시퀀스(S1 → S2 → S3)를 따르고, 각 단계에서 진행 표시기를 표시하세요.

package/i18n/ko/commands/product-report.md

@@ -0,0 +1,12 @@
+---
+description: HTML 기획 보고서 생성 — 모든 제품 기획 내용을 오프라인 열람 가능한 단일 HTML 보고서로 통합
+---
+
+~/.claude/skills/product-playbook/SKILL.md와 references/06-html-report.md를 읽어 주세요.
+
+현재 대화에서 완료된 제품 기획 내용을 기반으로, 06-html-report.md의 디자인 사양에 따라 전체 HTML 기획 보고서를 생성하세요:
+- 단일 HTML 파일 (CSS + JS 인라인, Google Fonts CDN으로 Inter 로드)
+- 완료된 단계만 동적으로 렌더링; 아직 완료되지 않은 단계는 건너뛰기
+- 고정 목차 네비게이션, 카드 기반 레이아웃, 인터랙티브 효과 포함
+
+대화에 제품 기획 내용이 없는 경우, 제품 기획 플로우를 먼저 실행하도록 안내하세요.

package/i18n/ko/commands/product-revision.md

@@ -0,0 +1,13 @@
+---
+description: 리비전 모드 제품 기획 — 기존 제품을 사용자 데이터와 기능 기반을 활용하여 최적화 및 반복 개선
+argument-hint: <제품명과 리비전 목표>
+---
+
+~/.claude/skills/product-playbook/SKILL.md를 읽어 주세요.
+그 다음 ~/.claude/skills/product-playbook/references/rules-revision.md를 읽어 단계 시퀀스를 확인하세요.
+각 단계를 실행할 때, rules-revision.md에 명시된 대로 해당 레퍼런스 파일을 로드하세요.
+
+실행 모드: 리비전 모드
+제품 설명: $ARGUMENTS
+
+rules-revision.md의 단계 시퀀스(S1 → S12)를 따르세요. S1에서 기존 제품 지표(DAU/MAU, 리텐션율, 주요 사용자 피드백 등)를 능동적으로 질문하세요. 각 단계에서 진행 표시기를 표시하세요.

package/i18n/ko/references/00-opportunity-check.md

@@ -0,0 +1,44 @@
+# 사전 단계: 기회 점검
+
+> **참고: 각 모드에서 실행할 단계는 SKILL.md의 "모드 단계 시퀀스"가 권위 있는 기준입니다. 아래 내용은 참고용입니다.**
+
+**적용: 풀 모드, 높은 완성도, 독자가 경영진/리더십인 경우**
+**생략 가능: 퀵 모드, 빌드 직행 모드, 독자가 엔지니어/디자이너인 경우**
+
+사용자가 0-to-1 제품을 처음부터 구축하는 경우, 먼저 다음 5개 질문을 거쳐가세요. 어떤 질문에서든 "아니오"가 나오면 재검토가 필요한 신호입니다:
+
+```
+| # | 평가 질문 | 사용자 답변 | 평가 |
+|---|----------|-----------|------|
+| 1 | 이것은 실제로 긴급한 사용자 페인포인트를 해결하나요? 최초 수혜 고객은 누구인가요? 어떻게 찾을 것인가요? | | ✅/⚠️ |
+| 2 | 이 문제를 해결하는 데 고유한 장점이 있나요? 타겟 고객이 최소 주 1회 이상 사용할 것인가요? 시장이 충분히 큰가요? | | ✅/⚠️ |
+| 3 | 현재 리소스로 2-3년 내에 사용 가능한 제품을 구축할 수 있나요? | | ✅/⚠️ |
+| 4 | 경쟁 구도는 어떤가요? 이길 수 있나요? 차별화 포인트는 무엇인가요? | | ✅/⚠️ |
+| 5 | 지속 가능한 사용자 성장과 수익화 경로가 있나요? | | ✅/⚠️ |
+```
+
+## DHM 빠른 점검 (Gibson Biddle / Netflix)
+
+이 기회가 달성할 수 있는지 확인하세요:
+- **D (Delight)**: 사용자의 기대를 놀라게 하고 초과할 수 있는가?
+- **H (Hard to copy)**: 경쟁자가 복제하기 어려운가?
+- **M (Margin-enhancing)**: 규모가 커질수록 마진이 개선되는가?
+
+일부 시장 신호가 불명확하다면 방향성 신호를 찾으세요:
+- 거시 트렌드 (예: AI 도입으로 인한 워크플로우 대체 기회)
+- 행동 변화 (사용자가 이미 우회 방법을 사용 중이라면 실제 수요가 있다는 의미)
+- 유사 시장 (검증된 비교 가능한 시나리오 찾기)
+
+## 팀 열정 점검
+
+팀이 이 문제 영역에 진정한 열정을 가지고 있는지 확인하세요. 내재적 동기가 부족한 팀은 PMF로 가는 길에서 필연적으로 흔들립니다.
+
+---
+
+## 📎 이 단계의 파일 통합 팁
+
+| 업로드 내용 | 통합 대상 | 통합 작업 |
+|------------|----------|----------|
+| 시장 보고서 (PDF) | 5개 평가 질문 (#2 시장 규모, #4 경쟁 구도) | 가정을 보고서 데이터로 대체 |
+| 산업 분석 / 트렌드 보고서 | DHM + 방향성 신호 | 거시 트렌드와 행동 변화를 DHM 근거로 추출 |
+| 경쟁사 펀딩/매출 정보 | 5개 평가 질문 (#4, #5) | 경쟁 강도 및 시장 검증 신호 평가 |

package/i18n/ko/references/01-strategy.md

@@ -0,0 +1,90 @@
+# 제품 전략 계층
+
+> **참고: 각 모드에서 실행할 단계는 SKILL.md의 "모드 단계 시퀀스"가 권위 있는 기준입니다. 아래 내용은 참고용입니다.**
+
+**적용: 풀 모드, 높은 완성도, 독자가 경영진/크로스펑셔널 정렬인 경우**
+**생략 가능: 퀵 모드, 빌드 직행 모드, 낮은 완성도**
+
+## Strategy Blocks (Chandra Janakiraman / Headspace / Meta)
+
+좋은 전략의 계층 구조 — 각 층은 다음 층의 기반입니다:
+
+```
+Mission
+  └→ Vision — 5-10년 후 세상이 어떤 모습이길 원하는가?
+       └→ Strategy — 그 비전에 어떻게 도달할 것인가? (핵심 선택과 트레이드오프)
+            └→ Goals / OKRs — 향후 6-12개월의 우선순위
+                 └→ Roadmap — 구체적으로 무엇을 만들 것인가?
+                      └→ Tasks — 누가, 언제, 무엇을 하는가?
+```
+
+## Richard Rumelt의 좋은 전략의 핵심
+
+- **진단(Diagnosis)**: 직면한 도전을 명확히 정의 (모든 문제가 아닌 가장 중요한 문제)
+- **방침(Guiding Policy)**: 전반적 접근 방식 (목표가 아닌 방법)
+- **일관된 행동(Coherent Actions)**: 서로 강화하는 구체적 행동, 독립적인 계획의 집합이 아님
+
+> 나쁜 전략의 징후: 진단 없는 거창한 목표; 공허한 사고를 가리는 화려한 언어; 모든 계획을 "전략"이라고 부르기.
+
+## Shreyas Doshi의 제품 업무 3단계
+
+제품 문제를 다루기 전에, 어떤 수준에서 작업하고 있는지 파악하세요:
+
+```
+Level 3: 제품 탁월성 — 올바른 일을 탁월하게 잘 하기
+Level 2: 제품 전략 — 올바른 일을 하기
+Level 1: 제품 기반 — 일을 할 수 있는 기반 갖추기 (문화, 프로세스, 인재)
+```
+
+> 대부분의 PM은 Level 2 문제를 방치하면서 Level 3에 너무 많은 시간을 씁니다. 대부분의 이른바 "실행 문제"는 근본적으로 전략 문제입니다.
+
+## Shreyas Doshi의 LNO 시간 배분 프레임워크
+
+매주 작업 항목에 대해 먼저 질문하세요: 이것이 제품에 어떤 유형의 임팩트를 주는가?
+
+```
+L (Leverage): 전략, 비전, 문화 → 충분한 시간을 투자하고 탁월함을 추구
+N (Neutral): 일반적인 협업, 루틴 커뮤니케이션 → 잘 하되 완벽을 추구하지 않기
+O (Overhead): 행정, 회의, 서류 작업 → 빠르게 끝내고 과잉 투자하지 않기
+```
+
+> 절약한 O 시간을 방치된 L 업무에 재투자하세요.
+
+## OKR 작성 가이드라인
+
+Strategy Blocks의 Goals/OKRs는 전략을 하위로 전파하는 핵심 계층입니다. 좋은 OKR을 작성하기 위한 최소 규칙:
+
+**Objective**: 정성적이고, 영감을 주며, 이해하기 쉬운. 달성하고 싶은 상태를 설명하지, 할 일 항목이 아닙니다.
+- ✅ 좋은 O: "신규 사용자가 첫날 제품의 핵심 가치를 느끼게 하기"
+- ❌ 나쁜 O: "온보딩 재설계 완료" (그것은 작업이지, 목표가 아닙니다)
+
+**Key Results**: 정량적이고, 측정 가능하며, 기한이 있는. 목표 달성 여부를 어떻게 알 수 있는지 설명합니다.
+- ✅ 좋은 KR: "신규 사용자 D1 핵심 행동 완료율을 20%에서 40%로 증가"
+- ❌ 나쁜 KR: "새로운 온보딩 플로우 출시" (그것은 산출물이지, 성과가 아닙니다)
+
+**흔한 함정:**
+- 작업 목록을 OKR로 위장 ("기능 X 완료"는 KR이 아닙니다)
+- OKR이 너무 많음 (분기당 Objective 2-3개, Objective당 KR 3-5개가 목표)
+- 서로 모순되거나 무관한 KR
+- 후행 지표만 있고 선행 지표가 없음
+
+**예시:**
+```
+O: 타겟 사용자가 우리 제품을 사랑하게 만들기 (PMF Level 2 → Level 3)
+  KR1: D28 리텐션을 12%에서 20%로
+  KR2: Sean Ellis Score를 28%에서 40%로
+  KR3: 월간 자발적 추천 비율을 10%에서 25%로
+```
+
+## 세 가지 핵심 제품 질문 (전체 프로세스에 걸쳐)
+
+이 세 가지 질문은 순서대로 답해야 합니다 — **순서를 바꿀 수 없습니다**:
+
+> **Q1: 사용자를 어떻게 문 앞으로 데려올 것인가?**
+> **Q2: Aha Moment에 어떻게 가장 빠르게 도달하게 할 것인가?**
+> **Q3: 핵심 가치를 어떻게 반복적으로 전달할 것인가?**
+
+Define 단계에서 이것은 다음으로 변환됩니다:
+- **누구를 위한 것인가?**
+- **왜 만드는가?**
+- **그것은 무엇인가?**

package/i18n/ko/references/02a-persona.md

@@ -0,0 +1,57 @@
+# 1단계: 디스커버리 — Persona 구축
+
+## Continuous Discovery Habits (Teresa Torres)
+
+하나의 핵심 습관을 구축하세요: **매주 최소 한 명의 타겟 사용자와 대화하기.** 디스커버리는 일회성 의식이 아니라 지속적인 시스템입니다.
+
+> "제품 디스커버리는 프로젝트 시작 전 일회성 의식이 아닌, 지속적인 습관이어야 합니다." — Teresa Torres
+
+## 1.1 Persona 테이블 구축
+
+Persona는 나이와 성별이 아닌 **목적 / 과업 / 동기**로 구분하여 다양한 유형의 사용자를 식별합니다.
+
+```
+| 항목 | Persona 1: [별칭] | Persona 2: [별칭] | Persona 3: [별칭] |
+|------|---|---|---|
+| 목적 / 과업 / 동기 | | | |
+| 규모 (SCALE) | | | |
+| 문제 / 과제 / 동인 | | | |
+| 현재 접근법 및 이유 | | | |
+| 빈도 | | | |
+| 정보 소스 | | | |
+| 채택 / 실행 장벽 | | | |
+```
+
+세분화 논리를 설명하고; MECE (상호 배타적이고 전체를 아우르는지) 확인; 1차 TA와 2차 TA를 식별하세요.
+
+### 📝 Persona 품질 체크리스트
+- ✅ 세분화가 인구통계가 아닌 "목적/과업/동기" 기반인가?
+- ✅ Persona가 MECE인가 (타겟 시장에서 상호 배타적이고 전체를 아우르는가)?
+- ✅ 1차 TA vs. 2차 TA가 명확히 식별되었는가?
+- ✅ 각 Persona의 "문제/과제"가 실제 관찰이나 합리적 추론에 기반하는가?
+- ✅ "현재 접근법 및 이유"가 우회 방법을 식별할 수 있을 만큼 구체적인가?
+- ❌ 흔한 문제: 나이/성별로 세분화, Persona 간 차이 미미, 페인포인트가 너무 모호
+
+## 1.2 Persona 카드 구축
+
+```
+## [Persona 별칭]: [한 줄 설명]
+
+**기본 정보**: 나이 / 성별 / 직업 / 지역 / 성격 특성
+**배경**: [제품 관련 배경 설명]
+**목표 / 과업**: [목표 1], [목표 2]
+**현재 접근법 및 이유**: [현재 하고 있는 것과 그 이유]
+**정보 소스**: [관련 정보를 얻는 곳]
+**장벽 / 문제 / 과제 / 불만**: [페인포인트 1], [페인포인트 2], [페인포인트 3]
+```
+
+---
+
+## 📎 이 단계의 파일 통합 팁
+
+이 단계에서 사용자가 파일을 업로드하면, Claude는 다음 규칙에 따라 통합합니다:
+
+| 업로드 내용 | 통합 대상 | 통합 작업 |
+|------------|----------|----------|
+| 사용자 인터뷰 녹취록 / 음성 전사 | 1.1 Persona + 1.3 JTBD | 추출: 사용자 배경 → Persona 항목; 페인포인트 + 현재 접근법 → JTBD 심층 질문; 감정적 반응 → 감정적/사회적 Job |
+| 사용자 리서치 보고서 (PDF) | 1.1 + 1.2 + 1.3 | 정량 데이터(사용자 세그먼트 비율)를 Persona 규모에 추출; 정성적 인사이트를 JTBD에 추출 |