product-playbook 1.0.0

package/i18n/ko/references/08-security-checklist.md

@@ -0,0 +1,221 @@
+# 보안 체크리스트
+
+> 개발 핸드오프 패키지 작성 전에 로드됩니다. 제품 기획 단계에서 핵심 보안 요구사항이 고려되도록 하여, 보안이 사후 고려가 되지 않도록 합니다.
+
+## 🔐 보안 아키텍처 빠른 점검
+
+개발 핸드오프 패키지 작성 전에, 다음 보안 측면을 각각 검증하세요. 각각 ✅ (기획에 반영됨) 또는 ❌ (추가 필요)로 표시하세요.
+
+### 1. 인증 & 인가
+
+```
+| 점검 항목 | 상태 | 비고 |
+|----------|------|------|
+| 인증 방식 결정됨 (JWT / Session / OAuth / Passkey) | | |
+| 토큰 저장이 안전함 (HttpOnly Cookie, localStorage 아님) | | |
+| 토큰 만료 및 갱신 메커니즘 설계됨 | | |
+| 비밀번호 저장에 bcrypt / argon2 사용 (MD5/SHA 아님) | | |
+| 권한 모델 정의됨 (RBAC / ABAC / 단순 역할) | | |
+| 모든 API 엔드포인트에 해당 인가 체크 있음 | | |
+| 로그인 실패에 무차별 대입 방어 (잠금 / 점진적 지연) | | |
+```
+
+**JWT 모범 사례 (JWT 사용 시):**
+- 짧은 수명의 Access Token (15-30분) + 긴 수명의 Refresh Token 사용
+- Refresh Token을 HttpOnly Secure Cookie에 저장
+- Token Revocation 구현 (로그아웃 시 Refresh Token 무효화)
+- JWT 페이로드에 민감한 정보 저장하지 않기
+
+### 2. CORS 정책 (Cross-Origin Resource Sharing)
+
+```
+| 점검 항목 | 상태 | 비고 |
+|----------|------|------|
+| 허용 Origin 목록 정의됨 (와일드카드 * 사용 금지) | | |
+| 필요한 HTTP 메서드만 허용됨 | | |
+| Access-Control-Allow-Credentials 설정됨 | | |
+| Preflight 캐시 기간이 합리적 (Access-Control-Max-Age) | | |
+```
+
+**CORS 설정 템플릿:**
+```
+허용 Origins:
+  - 프로덕션: https://[your-domain.com]
+  - 개발: http://localhost:[port]
+
+허용 Methods: GET, POST, PUT, DELETE, PATCH
+허용 Headers: Content-Type, Authorization
+Credentials: true (쿠키 기반 인증 사용 시)
+Max-Age: 86400 (24시간)
+```
+
+### 3. 입력 유효성 검증 & 새니타이징
+
+```
+| 점검 항목 | 상태 | 비고 |
+|----------|------|------|
+| 모든 API 입력에 서버사이드 유효성 검증 있음 | | |
+| SQL Injection 방지를 위해 파라미터화 쿼리 사용 | | |
+| 사용자 입력이 HTML 렌더링 전 출력 인코딩됨 (XSS 방지) | | |
+| 파일 업로드에 타입 / 크기 제한 있음 | | |
+| URL / 리디렉트 대상에 화이트리스트 검증 (Open Redirect 방지) | | |
+```
+
+**유효성 검증 원칙:**
+- 프론트엔드 유효성 검증은 UX; 백엔드 유효성 검증은 보안 — 둘 다 필요하지만, 백엔드 유효성 검증은 타협 불가
+- Schema Validation Library 사용 (예: Zod, Joi, Pydantic)으로 통합 유효성 검증 로직
+- 예상 형식과 맞지 않는 입력은 거부 — 사용자 입력을 "수정"하려 하지 마세요
+
+### 4. CSRF 방어 (Cross-Site Request Forgery)
+
+```
+| 점검 항목 | 상태 | 비고 |
+|----------|------|------|
+| 상태 변경 작업에 POST/PUT/DELETE 사용 (GET 아님) | | |
+| CSRF Token 구현 또는 SameSite Cookie 사용 | | |
+| 중요 작업에 2차 확인 있음 | | |
+```
+
+### 5. 보안 헤더
+
+```
+| 헤더 | 용도 | 권장 값 |
+|------|------|--------|
+| Content-Security-Policy (CSP) | XSS, 데이터 주입 방지 | default-src 'self'; script-src 'self' |
+| X-Content-Type-Options | MIME 스니핑 방지 | nosniff |
+| X-Frame-Options | 클릭재킹 방지 | DENY 또는 SAMEORIGIN |
+| Strict-Transport-Security (HSTS) | HTTPS 강제 | max-age=31536000; includeSubDomains |
+| X-XSS-Protection | 브라우저 XSS 필터 | 0 (CSP에 의존하는 것이 더 신뢰성 있음) |
+| Referrer-Policy | 리퍼러 정보 제어 | strict-origin-when-cross-origin |
+| Permissions-Policy | 브라우저 기능 제한 | camera=(), microphone=(), geolocation=() |
+```
+
+### 6. API 보안 & Rate Limiting
+
+```
+| 점검 항목 | 상태 | 비고 |
+|----------|------|------|
+| API에 글로벌 rate limiting 있음 (예: 100 req/min/IP) | | |
+| 민감한 엔드포인트에 더 엄격한 제한 (로그인 5 req/min, 등록 3 req/min) | | |
+| API 에러 응답에 내부 상세 노출 없음 (스택 트레이스, SQL문) | | |
+| API 버전 관리 전략 결정됨 (/api/v1/) | | |
+| 대량 데이터 엔드포인트에 페이지네이션 제한 있음 | | |
+```
+
+**Rate Limiting 설계 권장사항:**
+```
+| 엔드포인트 유형 | 권장 제한 | 식별 방법 |
+|---------------|----------|----------|
+| 일반 API | 100 req/min | IP + User ID |
+| 로그인/등록 | 5 req/min | IP |
+| 비밀번호 재설정 | 3 req/hour | IP + Email |
+| 파일 업로드 | 10 req/min | User ID |
+| 검색/쿼리 | 30 req/min | IP + User ID |
+```
+
+### 7. 스크래핑 방지 & 봇 보호
+
+```
+| 점검 항목 | 상태 | 비고 |
+|----------|------|------|
+| robots.txt 설정됨 (민감한 경로 제한) | | |
+| 중요 폼에 봇 보호 있음 (reCAPTCHA / hCaptcha / Honeypot) | | |
+| API에 User-Agent 체크 있음 (선택) | | |
+| 민감한 작업에 행동 분석 있음 (선택, 고급) | | |
+```
+
+**계층적 보호 전략:**
+1. **기본 계층**: Rate Limiting + robots.txt — 모든 제품에 필수
+2. **표준 계층**: + CAPTCHA (등록/로그인) + Honeypot 필드 — B2C 제품에 권장
+3. **고급 계층**: + 행동 분석 + IP 평판 + Device Fingerprint — 고위험 제품
+
+### 8. 민감한 데이터 보호
+
+```
+| 점검 항목 | 상태 | 비고 |
+|----------|------|------|
+| 민감한 데이터 전송 중 암호화 (HTTPS/TLS) | | |
+| 민감한 데이터 저장 시 암호화 (필요한 경우) | | |
+| 시크릿과 키가 코드에 저장되지 않음 | | |
+| .env 및 민감 파일이 .gitignore에 추가됨 | | |
+| 로그에 비밀번호, 토큰, 신용카드 번호 등 기록하지 않음 | | |
+| 명확한 데이터 보존 및 삭제 정책 (해당되는 경우 GDPR) | | |
+```
+
+**시크릿 관리 권장사항:**
+- 개발: `.env` 파일 (버전 관리에 포함하지 않음) + `.env.example` (키 이름만, 값 없음)
+- 프로덕션: 플랫폼 제공 환경 변수 관리 사용 (Vercel Environment Variables / Railway Variables / AWS Secrets Manager)
+- 커밋 메시지, PR 설명, 이슈에 시크릿 언급하지 않기
+
+### 9. .gitignore 보안 템플릿
+
+```gitignore
+# 환경 변수 및 시크릿
+.env
+.env.local
+.env.*.local
+*.pem
+*.key
+
+# 제품 기획 진행 상황 (민감한 비즈니스 정보 포함 가능)
+.product-playbook-progress.md
+
+# IDE 및 OS
+.idea/
+.vscode/
+*.swp
+.DS_Store
+Thumbs.db
+
+# 의존성
+node_modules/
+__pycache__/
+*.pyc
+venv/
+
+# 빌드 출력
+dist/
+build/
+.next/
+```
+
+---
+
+## 🏷️ OWASP Top 10 빠른 참조
+
+| # | 리스크 | 이 제품에 해당? | 대응 점검 |
+|---|--------|--------------|----------|
+| A01 | Broken Access Control | [예/아니오] | §1 인증 & 인가 |
+| A02 | Cryptographic Failures | [예/아니오] | §8 민감한 데이터 보호 |
+| A03 | Injection (SQL / XSS / Command) | [예/아니오] | §3 입력 유효성 검증 |
+| A04 | Insecure Design | [예/아니오] | 전체 아키텍처 설계 |
+| A05 | Security Misconfiguration | [예/아니오] | §5 헤더 + §2 CORS |
+| A06 | Vulnerable Components | [예/아니오] | 의존성 관리 (npm audit / pip audit) |
+| A07 | Authentication Failures | [예/아니오] | §1 인증 & 인가 |
+| A08 | Data Integrity Failures | [예/아니오] | §3 입력 유효성 검증 + §8 데이터 보호 |
+| A09 | Logging & Monitoring Failures | [예/아니오] | §8 로깅 규칙 |
+| A10 | SSRF (Server-Side Request Forgery) | [예/아니오] | §3 URL 화이트리스트 검증 |
+
+---
+
+## 📎 통합 타이밍
+
+| 트리거 | 통합 작업 |
+|--------|----------|
+| 개발 핸드오프 패키지 작성 전 | 보안 빠른 점검 실행, 결과를 CLAUDE.md "리스크 알림" 및 ARCHITECTURE.md "보안 아키텍처" 섹션에 통합 |
+| PRD 작성 시 | 보안 점검 결과를 PRD §6 "기술 고려사항 → 보안 요구사항"에 통합 |
+| Pre-mortem 단계 | 사용자에게 보안 실패 시나리오를 고려하도록 프롬프트 |
+| 리비전 모드 S1 | 사용자에게 기존 제품의 현재 보안 상태를 제공하도록 프롬프트 |
+
+## 품질 자체 점검
+
+```
+| 점검 항목 | ✅/❌ |
+|----------|------|
+| 인증 방식이 명시적으로 선택됨, "TBD"로 남기지 않음 | |
+| 최소 3개 보안 헤더 계획됨 | |
+| Rate limiting 전략이 제품 특성에 맞게 조정됨 (템플릿 그대로 복사하지 않음) | |
+| .gitignore에 모든 민감 파일 포함 | |
+| "해당"으로 표시된 모든 OWASP Top 10 항목에 대응 조치 있음 | |
+| 보안 조치 복잡성이 제품 단계에 적합 (MVP에 완벽한 보안은 필요 없지만, 기본은 타협 불가) | |
+```

package/i18n/ko/references/rules-build.md

@@ -0,0 +1,152 @@
+# ⚡ 빌드 모드 단계 시퀀스 (7단계 + 최종 산출물)
+
+> 이 파일은 빌드 모드의 권위 있는 단계 정의입니다. SKILL.md 코어 디스패처에 의해 로드됩니다.
+
+> ⚠️ 필수 알림: "사용자 리서치 단계를 건너뛰면 솔루션이 가정에 기반하게 됩니다. 실행 후 가능한 빨리 Continuous Discovery를 수행하여 검증하는 것을 권장합니다."
+
+## 단계 시퀀스
+
+```
+S1. 문제 진술 확인 (한 문장)
+S2. PR-FAQ → references/04a-prfaq.md 읽기
+S3. 병렬 솔루션 → references/04b-solutions.md → 3.2 읽기
+S4. Pre-mortem → references/04b-solutions.md → 3.3 읽기
+S5. GEM + RICE 우선순위 → references/04b-solutions.md → 3.4 + 3.5 읽기
+S6. MVP + Not Doing List → references/04c-mvp.md 읽기
+S7. North Star + Aha Moment → references/05a-northstar-aha.md 읽기
+────
+최종 산출물 → 엔지니어 지향 실행 요약
+```
+
+## 레퍼런스 로딩 지침
+
+| 단계 | 레퍼런스 파일 |
+|------|-------------|
+| S1 | 외부 레퍼런스 필요 없음 (사용자가 문제를 진술하도록 직접 안내) |
+| S2 | `references/04a-prfaq.md` |
+| S3-S5 | `references/04b-solutions.md` |
+| S6 | `references/04c-mvp.md` |
+| S7 | `references/05a-northstar-aha.md` |
+
+## 최종 산출물 형식
+
+**엔지니어 지향 실행 요약**: 솔루션 결정 → MVP 경계 → 성공 지표 → 핵심 리스크
+
+완료 후, `references/rules-end-of-flow.md`에 따라 플로우 종료 규칙을 실행하세요.
+
+---
+
+## 🔧 기능 확장 빠른 경로 (4단계)
+
+> **기존 제품에 단일 기능을 추가**하는 경우 이 경로로 자동 전환됩니다.
+> 트리거 조건: 사용자 설명에 "기능 추가", "새 기능", "XX 기능 추가", "기존 시스템에", "기존 제품에 필요한" 등의 표현 포함.
+
+**전체 빌드 모드(7단계)와의 차이**: 기존 제품에는 이미 North Star, Aha Moment, 제품 포지셔닝이 있으므로 재정의할 필요가 없습니다. 단일 기능에는 PR-FAQ 보도자료나 전체 GEM+RICE 재우선순위가 필요하지 않습니다. 초점은 "무엇을 추가하고, 어떻게 추가하며, 기존 기능을 손상시키지 않는가"입니다.
+
+### 기능 확장 단계 시퀀스
+
+```
+S1. 문제 + 기존 시스템 컨텍스트
+S2. 3개 병렬 솔루션 + 장단점 + AI 추천 → references/04b-solutions.md → 3.2 읽기
+S3. 리스크 평가 (회귀 + 호환성) → references/04b-solutions.md → 3.3 읽기
+S4. 실행 범위 (할 것 / 건드리지 않을 것 / 인수 기준) → references/04c-mvp.md 읽기
+────
+최종 산출물 → 기능 개발 사양
+```
+
+### S1 사전 단계: 제품 컨텍스트 로딩
+
+S1에 진입하기 전, `references/rules-context.md`를 읽고 `.product-context.md`를 확인하세요:
+
+- **완전한 컨텍스트 있음 (시나리오 1)**: 제품명, 기술 스택, 주요 모듈, 가장 최근 3개의 Decision History 항목을 자동으로 가져옵니다. S1 안내를 **확인 스타일**로 변경: "당신의 제품은 [이름]이고, [기술 스택]을 사용하며, 주요 모듈에는 [모듈 목록]이 있습니다. 어떤 기능을 추가하고 싶으신가요? 어떤 모듈이 영향을 받나요?" (질문 2와 질문 3의 일부가 사전 입력됨 — 확인만 필요)
+- **컨텍스트 없음 (시나리오 2)**: Context Bootstrap을 트리거(`rules-context.md` 섹션 4)하고, 아래 표준 S1으로 진행
+- **부분 컨텍스트 (시나리오 3)**: 알려진 기술 스택과 모듈을 가져오고(Decision History에서 병합), 누락된 부분을 수집합니다. 예: "[알려진 모듈] 외에 영향을 받을 수 있는 다른 모듈이 있나요?"
+
+### S1 안내 내용 (문제 + 기존 시스템 컨텍스트)
+
+Claude는 다음 정보를 수집해야 합니다 (단계적으로 안내 — 모든 질문을 한 번에 하지 마세요. 컨텍스트가 일부 답변을 사전 입력한 경우 재수집이 아닌 확인):
+
+```
+1. 어떤 기능을 추가하고 싶나요? 어떤 문제를 해결하나요?
+2. 현재 제품 아키텍처 개요 (기술 스택, 주요 모듈) ← 컨텍스트가 사전 입력 가능
+3. 이 기능이 어떤 기존 모듈에 영향을 미치나요? ← 컨텍스트가 부분 사전 입력 가능
+4. 이 요구사항을 뒷받침하는 사용자 피드백이나 데이터가 있나요?
+```
+
+### S2 안내 내용 (3개 병렬 솔루션 + AI 추천)
+
+```
+| HMW | 솔루션 A (보수적 / 최소 변경) | 솔루션 B (균형적) | 솔루션 C (대담한 / 리팩토링) |
+|-----|--------------------------|----------------|------------------------|
+| [문제] | | | |
+
+| 솔루션 | 장점 | 단점 | 영향 범위 | 구현 복잡도 |
+|--------|------|------|----------|-----------|
+| A | | | | |
+| B | | | | |
+| C | | | | |
+
+🤖 AI 추천: 솔루션 [X]
+근거: [영향 범위, 복잡도, 리스크를 종합적으로 판단]
+```
+
+### S3 안내 내용 (리스크 평가 — 회귀 & 호환성 중심)
+
+```
+| 리스크 유형 | 구체적 리스크 | 가능성 | 완화 조치 |
+|-----------|------------|-------|----------|
+| 회귀 리스크 | [기존 기능이 영향 받을 수 있는 영역] | | |
+| 호환성 리스크 | [기존 아키텍처/데이터/API와의 충돌] | | |
+| 성능 리스크 | [새 기능이 시스템 성능에 미치는 영향] | | |
+| 보안 리스크 | [새 기능이 도입하는 보안 고려사항] | | |
+```
+
+### S4 안내 내용 (실행 범위)
+
+```
+**할 것 (Scope)**:
+- [추가할 구체적 기능 항목]
+- [수정이 필요한 기존 모듈]
+
+**건드리지 않을 것**:
+- [명시적으로 수정하지 않을 모듈과 기능]
+- [건드리지 않는 이유]
+
+**인수 기준**:
+- [ ] [구체적 테스트 가능 조건]
+- [ ] [회귀 테스트: 기존 기능이 영향받지 않음 확인]
+```
+
+### 기능 확장 최종 산출물 형식
+
+**기능 개발 사양**: 문제 진술 → 선택한 솔루션 + 근거 → 영향 범위 → 실행 범위 + 인수 기준 → 리스크 목록
+
+### 증분 문서 산출 (원본 문서가 있는 경우)
+
+사용자가 프로세스 중에 원본 문서(PRD, 사양서 등)를 업로드한 경우:
+
+1. **증분 버전** (원본 문서가 있을 때 기본값):
+   - 원본 문서 구조에 섹션을 삽입/수정
+   - 원본 파일의 형식, 스타일, 명명 규칙을 유지
+   - 새로운 콘텐츠에 `[NEW]` 표시
+   - 수정된 콘텐츠에 `[UPDATED]` 표시, 원본은 참고용으로 보존
+   - 새 기능과 관련 없는 섹션은 전혀 변경하지 않음
+
+2. **독립 버전** (원본 문서가 없는 경우):
+   - 표준 기능 개발 사양 형식 사용 (위에서 정의한 대로)
+
+3. **생성 전 사용자에게 확인**:
+   "[문서 유형]이 업로드된 것을 감지했습니다. 산출물 방식을 어떻게 하시겠습니까?
+    A) 원본 문서에 증분 업데이트 (권장)
+    B) 독립 기능 개발 사양"
+
+### 레퍼런스 로딩 지침
+
+| 단계 | 레퍼런스 파일 |
+|------|-------------|
+| S1 | 외부 레퍼런스 필요 없음 |
+| S2 | `references/04b-solutions.md` → 3.2 |
+| S3 | `references/04b-solutions.md` → 3.3 |
+| S4 | `references/04c-mvp.md` |
+
+완료 후, `references/rules-end-of-flow.md`에 따라 플로우 종료 규칙을 실행하세요.

package/i18n/ko/references/rules-change-propagation.md

@@ -0,0 +1,74 @@
+# 🔄 변경 전파 규칙
+
+> 사용자가 이전에 완료한 단계를 수정할 때 로드됩니다.
+
+## 📍 진행 표시기 (모든 단계에서 반드시 표시)
+
+어떤 단계를 실행하든, Claude는 응답의 맨 처음에 진행 바를 반드시 표시해야 합니다, 다음 형식으로:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+📍 [실행 모드] ｜ 진행 S[현재 단계 번호] / S[전체 단계]
+✅ S1: [단계명] (완료)
+✅ S2: [단계명] (완료)
+▶️ S3: [단계명] (진행 중)
+⬜ S4: [단계명] (대기)
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+이 진행 표시기는 다음 상황에서 반드시 표시되어야 합니다:
+- 새 단계에 진입할 때
+- 사용자가 이전 단계로 돌아가 수정할 때
+- 단계를 완료하고 다음 단계로 넘어가기 전 사용자 확인을 요청할 때
+
+## 트리거 방법
+- "Persona로 돌아가기", "JTBD로 돌아가기", "HMW로 돌아가기", "PR-FAQ로 돌아가기" 또는 다른 단계명
+- "[단계명]을 수정하고 싶어요", "[단계명] — 변경하고 싶은 것이 있어요"
+- 이미 작성된 테이블이나 내용을 직접 참조하며 "이것을 ...으로 변경해 주세요"
+
+## 수정 후 필수 조치
+
+어떤 단계가 수정되면, Claude는 **다음 점검을 능동적으로 수행해야 합니다**:
+
+```
+수정된 계층               영향받는 하위 (재확인 또는 업데이트 필수)
+─────────────────────────────────────────────────────
+Persona / JTBD            → HMW, 기회 평가 테이블, 포지셔닝, PR-FAQ, North Star, 제품 스펙 요약
+HMW / 기회 평가            → PR-FAQ, 병렬 솔루션, MVP, North Star, 제품 스펙 요약
+포지셔닝                   → PR-FAQ, 제품 스펙 요약
+PR-FAQ / 솔루션            → Pre-mortem, GEM/RICE, MVP, Aha Moment, 제품 스펙 요약
+MVP / Not Doing List      → User Story, DB schema (이미 생성된 경우), 제품 스펙 요약
+North Star / 지표          → 가설 검증 계획, 제품 스펙 요약
+제품 스펙 요약              → HTML 보고서, PRD (이미 생성된 경우)
+```
+
+### 기능 확장 의존 관계:
+```
+기능 확장 의존 관계:
+─────────────────────────────────────────────────────
+S1 (문제 + 컨텍스트)     → S2 (솔루션), S3 (리스크), S4 (실행 범위)
+S2 (선택된 솔루션)       → S3 (리스크), S4 (실행 범위)
+S3 (리스크 평가)         → S4 (실행 범위)
+```
+
+## 실행 프로세스
+
+1. **사용자에게 영향 범위를 알림**: "당신이 [단계]를 수정했습니다. 이것은 [하위 단계 목록]에 영향을 미칩니다. 각각 업데이트하겠습니다."
+2. **하위 항목을 확인하거나 자동 업데이트**:
+   - 하위 변경이 경미한 경우 (문구 조정) → 직접 업데이트하고 변경 내용 설명
+   - 하위 변경이 중대한 경우 (방향 전환) → 업데이트 전 사용자에게 새 방향 확인 요청
+3. **제품 스펙 요약 재통합**
+4. **HTML 보고서 또는 PRD가 이미 생성된 경우**: 직접 재생성하고 버전 스냅샷 출력:
+
+```
+📋 버전 스냅샷 v[이전 버전] → v[새 버전]
+수정된 단계: [단계명]
+수정 전 핵심 내용: [1-3문장]
+수정 후 핵심 내용: [1-3문장]
+트리거된 하위 업데이트: [함께 조정된 단계]
+```
+
+## 원칙
+- 어떤 수정도 무성하게 일어나지 않음 — 영향 범위를 항상 명시적으로 전달해야 함
+- 사용자는 "이 단계만 수정하고, 하위는 당분간 그대로 두겠다"를 선택할 권리가 있음. Claude는 어떤 부분이 구식인지 표시해야 함 (⚠️ 업데이트 필요 라벨 추가)
+- 수정 이력은 대화 내에서 추적 가능하게 유지

package/i18n/ko/references/rules-commands.md

@@ -0,0 +1,98 @@
+# 🔧 프레임워크 메뉴 + 보조 명령
+
+> 사용자가 "프레임워크 목록", "사용 가능한 프레임워크를 보여주세요"를 요청하거나 보조 명령을 사용할 때 로드됩니다.
+
+## 프레임워크 지정
+
+**두 가지 트리거 방법:**
+
+**방법 A (사용자가 프레임워크를 직접 지정):** 해당 프레임워크의 안내 플로우로 바로 진행 — 다시 질문할 필요 없음.
+
+**방법 B (사용자가 "프레임워크를 고르고 싶어요", "모든 프레임워크를 보여주세요" 등):** 다음 메뉴를 제시:
+
+```
+📚 사용 가능한 프레임워크 — 번호 또는 이름을 입력하세요:
+
+【사용자 이해】
+ 1. JTBD (Jobs to Be Done) — 사용자가 진정으로 완수하고 싶은 과업 식별
+ 2. Persona — 사용/과업/동기 기반 사용자 프로필 구축
+ 3. User Journey Map — 완전한 사용자 경험 여정 매핑
+ 4. Continuous Discovery — 주간 사용자 소통 습관 구축
+
+【문제 정의】
+ 5. OST / Opportunity Solution Tree — 기회와 솔루션을 체계적으로 연결
+ 6. 포지셔닝 / April Dunford — 실제 경쟁 영역과 차별화 발견
+ 7. HMW — 페인포인트를 디자인 질문으로 재구성
+
+【솔루션 설계】
+ 8. Working Backwards / PR-FAQ — 사용자 성과에서 역으로 솔루션 도출
+ 9. Pre-mortem — 실패가 발생하기 전에 예측하고 방지
+10. GEM — Growth / Engagement / Monetization 3차원 우선순위
+11. RICE — 정량적 기능 우선순위 결정
+12. MVP — 최소 실행 가능한 제품 범위 정의
+
+【전략 계층】
+13. 전략 / Strategy Blocks — Mission → Vision → Strategy 계층
+14. DHM Model — Delight / Hard to copy / Margin-enhancing 기회 평가
+15. LNO Framework — Leverage / Neutral / Overhead 시간 배분
+16. Empowered Teams — 임파워드 팀 vs. 기능 팀
+
+【측정 계층】
+17. North Star / North Star Metric — 핵심 사용자 가치를 대표하는 단일 지표 정의
+18. PMF — 4단계 Product-Market Fit 평가
+19. Sean Ellis Score — PMF 열정 수준 정량화
+
+【비즈니스 계층】
+20. 비즈니스 모델 & 프라이싱 — 수익 모델 선택 및 가치 기반 가격 정렬
+21. GTM 전략 — Go-to-Market 출시 및 고객 획득 전략
+
+【개발 핸드오프】
+22. 개발 핸드오프 — CLAUDE.md + TASKS.md + TICKETS.md를 생성하여 Claude Code에 개발 핸드오프
+
+프레임워크 번호 또는 이름을 입력하세요 (복수 선택 가능, 쉼표로 구분):
+```
+
+## 디스커버리 건너뛰기 / 빌드로 바로 진행
+
+사용자가 "사용자 리서치 건너뛰기", "문제는 이미 알고 있어요", "Develop으로 바로 가기"라고 말하면, `references/rules-build.md`를 읽고 빌드 모드 단계 시퀀스를 따르세요.
+
+> 사용자에게 알림: "사용자 리서치 단계를 건너뛰면 솔루션이 가정에 기반하게 됩니다. 실행 후 가능한 빨리 Continuous Discovery를 수행하여 검증하는 것을 권장합니다."
+
+## 기능 확장 모드 트리거
+
+- "기능 추가" / "새 기능을 추가하고 싶어요" / "기존 제품에 새 기능" → 기능 확장 모드를 트리거합니다 (`references/rules-build.md` → 기능 확장 빠른 경로를 읽음)
+
+## 보조 명령
+
+| 명령 | 동작 |
+|------|------|
+| `"[프레임워크]로 전환"` | 즉시 전환, 완료된 내용 유지 |
+| `"대상 독자를 바꾸고 싶어요"` | 프레임워크 우선순위와 표현 스타일 재조정 |
+| `"이 단계를 건너뛰기"` | 필요성을 알리고, 결정을 존중하여 다음 단계로 이동 |
+| `"[단계/프레임워크명]으로 돌아가기"` | 지정된 단계로 복귀하여 재안내 (`references/rules-change-propagation.md` 참조) |
+| `"간소화"` / `"확장"` | 핵심만 요약 / 심층 분석 추가 |
+| `"보고서 생성"` | `references/06-html-report.md`를 읽고 HTML 기획 보고서 작성 |
+| `"PRD 생성"` / `"엔지니어 문서 생성"` | `references/04b-solutions.md`를 읽고 PR-FAQ + MVP + User Story + Pre-mortem 통합, **자동으로 추가 생성: 플로우차트(Mermaid) + DB schema(Mermaid ERD) + UI 와이어프레임(HTML)** |
+| `"플로우차트 생성"` / `"플로우차트 그려주세요"` | Mermaid 구문으로 플로우차트 출력 (독립 트리거) |
+| `"DB schema 생성"` / `"데이터베이스 설계"` | Mermaid ERD 구문으로 DB schema 출력 (독립 트리거) |
+| `"UI 와이어프레임 생성"` / `"와이어프레임 그려주세요"` | HTML/SVG로 저충실도 UI 와이어프레임 출력 (독립 트리거) |
+| `"프레젠테이션 생성"` / `"PPT 만들어 주세요"` | 시스템 pptx 스킬 호출 |
+| `"이 문서를 [독자]에 맞게 조정"` | 지정된 독자에 맞게 프레임워크 하이라이트와 언어 재구성 |
+| `"15분밖에 없어요"` | 가장 중요한 3가지 의사결정 질문 또는 행동 제공 |
+| `"완성도 평가를 해 주세요"` | 어떤 영역이 견고하고 어떤 영역에 리스크가 있는지 평가 |
+| `"가정을 찾아주세요"` | 모든 미검증 핵심 가정 식별 |
+| `"Pre-mortem 실행"` | 모든 솔루션에 대해 즉시 Pre-mortem 실행 |
+| `"다른 독자용 버전 생성"` | 여러 독자에 맞춘 요약을 자동 생성 |
+| `"이 제품의 PMF 수준은?"` | PMF 수준 판단 및 다음 마일스톤 설명 |
+| `"병목을 찾아주세요"` | Aha Moment 달성의 가장 큰 장애물 분석 |
+| `"이것은 신규가 아니라 리비전이에요"` | 리비전 모드로 전환 (`references/rules-revision.md` 읽기) |
+| `"상사를 설득해야 해요"` | 보스 모드로 전환 — 비즈니스 가치와 리소스 논리 강조 |
+| `"개발 시작"` / `"개발 핸드오프 패키지 생성"` | `references/07a-handoff-core.md`를 읽고 기술 스택 확인 후 전체 개발 핸드오프 패키지 생성 |
+| `"프로젝트 설정"` / `"Claude Code 연결"` | 위와 동일 |
+| `"일시 정지"` / `"저장"` / `"다른 것 먼저"` | `references/rules-progress.md`에 따라 진행 저장 |
+| `"계속"` / `"기획으로 돌아가기"` | `references/rules-progress.md`에 따라 재개 |
+| `"진행 초기화"` / `"처음부터 다시"` | 진행 파일 삭제 후 처음부터 시작 |
+| `/export [format]` | 지정된 형식으로 내보내기. format = `pdf` / `docx` / `pptx` / `html` / `md`. `references/rules-export-document.md`를 읽음. 최초 사용 시 먼저 `references/rules-document-tools.md`를 로드하여 도구 확인. |
+| `/parse [file]` | 업로드된 문서를 Markdown으로 파싱. PDF / DOCX / PPTX / 이미지 지원. `references/rules-import-document.md`를 읽음. 최초 사용 시 먼저 `references/rules-document-tools.md`를 로드하여 도구 확인. |
+
+**컨텍스트 인식 명령 힌트**: 각 단계 완료 후, 현재 진행 상황에 맞게 가장 관련 있는 사용 가능한 명령 2-3개를 능동적으로 제안하세요.