@kood/claude-code 0.6.0 → 0.6.2

package/templates/.claude/skills/prd/references/ai-native-prd.md

@@ -0,0 +1,116 @@
+# AI 에이전트용 PRD 작성법
+
+> Addy Osmani (Google), David Haberlah, GitHub Spec Kit, ChatPRD, Thoughtworks 기반
+
+---
+
+## Spec-Driven Development (GitHub, 2025.09~)
+
+명세가 진실의 원천(source of truth)이 되어 AI 에이전트가 직접 실행하는 패러다임.
+
+**GitHub Spec Kit 4단계:**
+
+| 단계 | 설명 | 초점 |
+|------|------|------|
+| **Specify** | 무엇을 왜 만드는지 기술 | 사용자 경험, 성공 지표 |
+| **Plan** | 스택, 아키텍처, 제약조건 | 기술 계획 |
+| **Tasks** | 작고 테스트 가능한 청크로 분해 | 검증 가능한 단위 |
+| **Implement** | 순차 구현, 단계별 검증 | 코드 생성 |
+
+---
+
+## Addy Osmani의 5대 원칙
+
+### 1. 고수준 비전으로 시작
+AI에게 상세 명세 생성을 맡기고 협업으로 정제. 간단한 목표 설명 → AI가 세부사항 작성.
+
+### 2. 전문 PRD처럼 구조화
+6개 핵심 영역 필수 포함 (GitHub 2,500+ 리포지토리 분석):
+
+| 영역 | 내용 | 예시 |
+|------|------|------|
+| **Commands** | 실행 가능한 명령어 + 플래그 | `npm test`, `pytest -v` |
+| **Testing** | 프레임워크, 파일 위치, 커버리지 | Jest, 80% coverage |
+| **Project Structure** | 소스, 테스트, 문서 경로 | `src/`, `tests/`, `docs/` |
+| **Code Style** | 선호 패턴을 코드 스니펫으로 | ESLint 규칙, 네이밍 컨벤션 |
+| **Git Workflow** | 브랜치 네이밍, 커밋 형식, PR | `feat/`, conventional commits |
+| **Boundaries** | 에이전트가 절대 하지 말아야 할 것 | "Never edit node_modules/" |
+
+### 3. 모듈형 프롬프트로 분해
+"지시의 저주" -- 동시 지시가 많으면 성능 저하. Frontier LLM은 약 150-200개 instruction까지 합리적 일관성 유지, 이후 급락.
+
+**해결:** 300개 요구사항의 단일 문서 대신 5-6개 Phase x 30-50개 요구사항으로 분해.
+
+### 4. 자체 검증과 제약 내장
+3단계 경계 시스템:
+
+```
+ALWAYS DO:  "항상 커밋 전 테스트 실행", "네이밍 규칙 준수"
+ASK FIRST:  DB 스키마 변경, 의존성 추가, CI/CD 수정
+NEVER DO:   "비밀키 커밋 금지", "node_modules 수정 금지"
+```
+
+### 5. 테스트, 반복, 진화
+마일스톤마다 테스트, 발견 시 명세 업데이트. 초기 명세서는 시작점.
+
+---
+
+## David Haberlah의 AI PRD 핵심 규칙 (2026)
+
+| 규칙 | 설명 |
+|------|------|
+| **Non-Goals 필수** | AI는 "생략에서 추론" 불가 → "X를 구현하지 말 것" 명시 안 하면 임의 추가 |
+| **원자적 User Stories** | 1 스토리 = 1 요구사항, 복합 스토리 금지 |
+| **Given-When-Then AC** | 체크 가능한 Acceptance Criteria |
+| **의존성 순서 Phase** | 기초 → 핵심 → 고급, 각 Phase에 테스트 체크포인트 |
+| **기존 기능 보호** | "기존 X 기능에 영향 주지 말 것" 명시 |
+| **코드 스니펫 패턴** | 텍스트 설명보다 코드 예시가 AI에게 효과적 |
+
+---
+
+## ChatPRD: Claude Code를 위한 PRD
+
+**역할 분리:**
+- PRD = "무엇을(What)" + "왜(Why)"
+- CLAUDE.md = "어떻게(How)"
+
+**필수 섹션:** Introduction, Problem Statement, Solution Overview, User Stories, Technical Requirements, Acceptance Criteria, Constraints
+
+**Claude Code 4가지 기법:**
+1. `@-mention`으로 회사 전략/사용자 연구/템플릿 등 전체 맥락 제공
+2. 소크라테스식 질문 (문제 명확화, 솔루션 검증, 성공 지표, 제약 조건)
+3. 다중 전략 병렬 생성 ("채팅 우선", "목록 우선", "균형형")
+4. Sub-agent 다각 피드백 (엔지니어/임원/사용자 연구자 관점)
+
+---
+
+## Thoughtworks: 명세(Specification) vs PRD
+
+| 문서 | 초점 | 대상 |
+|------|------|------|
+| **PRD** | 제품 요구사항 (사용자/비즈니스 관점) | 인간 정렬 |
+| **Specification** | 외부 동작 명시적 정의 (input/output, 사전/사후 조건, 불변량) | AI 에이전트 실행 |
+
+명세가 포함해야 할 것:
+- Input/Output 매핑
+- 사전/사후 조건
+- 불변량, 제약조건
+- 인터페이스 타입
+- 통합 계약
+- 순차 로직/상태 머신
+- Given/When/Then 시나리오
+
+**반구조화된 입력이 추론 성능을 크게 향상시키고 환각을 줄임.**
+
+---
+
+## 출처
+
+- https://addyosmani.com/blog/good-spec/
+- https://medium.com/@haberlah/how-to-write-prds-for-ai-coding-agents-d60d72efb797
+- https://www.chatprd.ai/resources/PRD-for-Claude-Code
+- https://ccforpms.com/advanced/write-prd
+- https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
+- https://github.com/github/spec-kit
+- https://www.thoughtworks.com/en-us/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices
+- https://tessl.io/blog/from-code-centric-to-spec-centric

package/templates/.claude/skills/prd/references/anti-patterns.md

@@ -0,0 +1,82 @@
+# PRD 안티패턴 & 평가 기준
+
+> Scopilot AI, PM Prompt, Addy Osmani, Parallel HQ, Carnegie Mellon SEI
+
+---
+
+## 안티패턴
+
+### 작성 단계
+
+| # | 안티패턴 | 문제 | 해결 |
+|---|----------|------|------|
+| 1 | **모호한 요구사항** | "빠른 로딩", "좋은 UX" 측정 불가 | "3G에서 2초 내 로딩", "3클릭 이내 완료" |
+| 2 | **기능 과적재** | 스코프 크리프, 지연, 비대한 제품 | MoSCoW/RICE 우선순위화, Appetite 설정 |
+| 3 | **이해관계자 배제** | 나중에 비용 큰 분쟁 | 초기부터 다기능 팀 참여, Contributor Review |
+| 4 | **솔루션 편향** | 문제 정의 전 솔루션 결정, 최적 솔루션 배제 | 문제 공간 먼저 정의, Opportunity Solution Tree |
+| 5 | **엣지 케이스 무시** | 사용자 불만, 제품 갭 | Happy Path + Alternative Flow + Edge Case |
+| 6 | **성공 지표 부재** | 성공 여부 판단 불가, Landing Review 불가 | 현재값 → 목표값 KPI + 측정 방법 |
+| 7 | **정적 문서화** | 빠르게 구식화, 개발 현실과 괴리 | 정기 리뷰 + 변경 이력 + Living Document |
+| 8 | **기술 요구사항 누락** | 개발자 혼란, 잘못된 구현 | API, 통합, 보안, 성능 요구사항 명시 |
+| 9 | **부실한 User Stories** | 개발 중 오해, 범위 논쟁 | "As a [user], I want to [action] so that [benefit]" |
+| 10 | **체크박스용 PRD** | 형식만 갖춘 비효과적 문서 | 결정 중심 문서, Discovery First |
+
+### AI 시대 특유
+
+| 안티패턴 | 설명 | 해결 |
+|----------|------|------|
+| **LLM으로 긴 PRD 생성** | 내용 없이 길기만 함, 가독성 급락 | 간결하고 결정 중심 작성, 인간 편집 필수 |
+| **모호한 프롬프트** | "멋진 걸 만들어" -- 앵커링 포인트 없음 | 구체적 목표, AC, 제약조건 명시 |
+| **계층 없는 장문 컨텍스트** | 50페이지 덤프 → 모델 이해 실패 | Phase 분해, 모듈형 구조 |
+| **인간 리뷰 생략** | 테스트 통과 ≠ 올바른 코드 | 각 Phase 완료 후 인간 검토 |
+| **Vibe Coding과 프로덕션 혼동** | 빠른 프로토타이핑 ≠ 엔지니어링 | 명세 기반 검증 프로세스 |
+| **Non-Goals 누락** | AI가 범위 외 기능 임의 추가 | 하지 않을 것 명시적 기술 |
+| **속도/품질 긴장 무시** | 생성 속도가 검증 능력 초과 | 단계별 체크포인트 |
+
+---
+
+## 품질 평가 기준
+
+### 종합 평가 체크리스트
+
+| 항목 | 기준 | 가중치 | 확인 방법 |
+|------|------|--------|----------|
+| **명확성** | 모호한 용어 없이 측정 가능 | 높음 | "빠른", "좋은" 등 형용사 검색 |
+| **완전성** | 범위, 제약, AC, Non-Goals 포함 | 높음 | 섹션 체크리스트 대조 |
+| **전략 정렬** | 비즈니스 목표/OKR과 직접 연결 | 높음 | "왜 지금?"에 답할 수 있는가 |
+| **성공 메트릭** | 정량적 KPI + 현재값 → 목표값 | 높음 | 숫자 없는 목표 검색 |
+| **사용자 중심** | 페르소나, JTBD, User Stories, AC | 중간 | 사용자 관점 서술 비율 |
+| **우선순위** | MoSCoW/RICE 기반 명확한 순위 | 중간 | P0/P1 태그 존재 여부 |
+| **가정 명시** | 검증되지 않은 가정 문서화 | 중간 | 가정 섹션 존재 여부 |
+| **AI 실행 가능** | Phase 분해, Non-Goals, 체크포인트 | 중간 | Given-When-Then AC 비율 |
+| **간결성** | 불필요한 내용 없이 결정 중심 | 낮음 | 전체 분량, 반복 내용 |
+| **이해관계자 정렬** | 리뷰/사인오프 문서화 | 낮음 | Contributor Review 기록 |
+
+### Carnegie Mellon SEI 연구 기반
+
+- 소프트웨어 개발 비용의 **60-80%가 재작업**
+- 효과적 요구사항 관리 시 **50-80% 결함 제거** 가능
+- 요구사항 결함은 나중에 발견할수록 수정 비용 **기하급수적 증가**
+
+### 좋은 PRD의 신호
+
+| 신호 | 설명 |
+|------|------|
+| **읽힌다** | 팀원이 실제로 읽고 참조함 (Cagan: "거의 읽히지 않는" PRD는 실패) |
+| **결정을 담는다** | "왜 A가 아닌 B를 선택했는가" 기록 (Linear: 거부된 대안 분석) |
+| **변한다** | 개발 중 발견사항이 반영됨 (Living Document) |
+| **짧다** | 필요한 것만 포함 (Lenny: 1-Pager로 시작) |
+| **측정 가능하다** | 모든 목표에 숫자가 있음 (현재값 → 목표값) |
+| **블로킹하지 않는다** | 팀이 PRD 없이도 병렬 진행 가능 (Doshi: "just enough") |
+
+---
+
+## 출처
+
+- https://www.scopilot.ai/top-10-mistakes-to-avoid-when-writing-a-product-requirements-document/
+- https://www.parallelhq.com/blog/how-to-write-product-requirements
+- https://pmprompt.com/blog/prd-examples
+- https://addyosmani.com/blog/good-spec/
+- https://shreyasdoshi.com/good-product-managers-great-product-managers/
+- https://www.svpg.com/revisiting-the-product-spec/
+- https://www.lennysnewsletter.com/p/prds-1-pagers-examples

package/templates/.claude/skills/prd/references/frameworks.md

@@ -0,0 +1,216 @@
+# PRD 프레임워크
+
+> PRFAQ, Shape Up, JTBD, RICE, Opportunity Solution Tree, GitHub Spec Kit
+
+---
+
+## Amazon PRFAQ (Working Backwards)
+
+미래 시점에서 제품이 이미 존재하는 것처럼 보도자료를 작성하고, 예상 질문/반론을 FAQ로 정리.
+
+### 구조
+
+| 구성요소 | 설명 | 분량 |
+|----------|------|------|
+| **Press Release** | 고객 관점의 제품 발표문, "oprah-speak" (누구나 이해 가능) | 1.5페이지 이내 |
+| **Customer FAQ** | 고객 예상 질문 (사용법, 가격, 차별화) | 1-2페이지 |
+| **Internal FAQ** | 내부 질문 (기술, 리소스, 리스크, ROI) | 1-2페이지 |
+
+### Press Release 필수 요소
+1. **Heading**: 제품명 + 타깃 고객
+2. **Sub-heading**: 핵심 혜택 1문장
+3. **Problem**: 현재 고객이 겪는 문제
+4. **Solution**: 이 제품이 어떻게 해결하는지
+5. **Quote (내부)**: 회사 대변인의 발언
+6. **How It Works**: 시작하기 쉬운 3단계
+7. **Quote (고객)**: 가상의 고객 추천사
+8. **CTA**: "지금 시작하세요" + URL
+
+### 적합한 상황
+- 신규 제품/서비스 기획
+- 큰 비전이 필요한 프로젝트
+- 고객 중심 사고가 약한 팀
+- 이해관계자 정렬이 필요한 상황
+
+---
+
+## Basecamp Shape Up
+
+### 핵심 개념
+
+| 개념 | 설명 |
+|------|------|
+| **Shaping** | 추상적 수준에서 솔루션 핵심 요소 정의 (와이어프레임 X, 개념 수준) |
+| **Appetite** | "이 문제에 6주를 투자할 가치가 있는가?" (deadline이 아닌 budget) |
+| **Betting** | 6주 사이클에 어떤 작업을 할지 결정 |
+| **Building** | 팀이 자율적으로 6주 내 완료, 세부 구현은 팀 재량 |
+
+### Pitch 문서 구조
+1. **Problem**: 해결할 문제 (Raw Idea가 아닌 구체적 상황)
+2. **Appetite**: 투자할 시간 (2주 또는 6주)
+3. **Solution**: 핵심 요소만 스케치 (fat marker sketch)
+4. **Rabbit Holes**: 함정 (복잡해질 수 있는 부분 사전 제거)
+5. **No-gos**: 명시적으로 하지 않을 것
+
+### 적합한 상황
+- 시간 제약이 명확한 프로젝트
+- 자율적인 소규모 팀
+- 과도한 상세 스펙을 피하고 싶을 때
+
+---
+
+## Jobs-to-be-Done (JTBD)
+
+고객이 제품을 "고용(hire)"하여 완수하려는 근본적 목표에 초점.
+
+### JTBD 문장 형식
+```
+When I [상황/맥락],
+I want to [동기/목표],
+So I can [기대하는 결과].
+```
+
+### Opportunity Score
+기회를 정량화하는 공식:
+
+```
+Opportunity = Importance + max(Importance - Satisfaction, 0)
+```
+
+- **Importance**: 이 과제가 고객에게 얼마나 중요한가 (1-10)
+- **Satisfaction**: 현재 솔루션에 얼마나 만족하는가 (1-10)
+- 중요도 높고 만족도 낮은 영역 = 최대 기회
+
+### 적합한 상황
+- 사용자 니즈 중심 기획
+- "왜 고객이 우리 제품을 쓰는가" 이해 필요
+- 기능 목록이 아닌 고객 가치 기반 우선순위
+
+---
+
+## RICE Scoring
+
+| 요소 | 설명 | 측정 |
+|------|------|------|
+| **Reach** | 기간 내 영향받는 사용자 수 | 분기당 N명 |
+| **Impact** | 개별 사용자에 대한 영향 | 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal |
+| **Confidence** | 추정치의 신뢰도 | 100%=high, 80%=medium, 50%=low |
+| **Effort** | 필요한 노력 | 인월(person-months) |
+
+```
+RICE Score = (Reach × Impact × Confidence) / Effort
+```
+
+### 적합한 상황
+- 백로그 우선순위 결정
+- 여러 기능 간 객관적 비교
+- 이해관계자 간 우선순위 합의
+
+---
+
+## Opportunity Solution Tree (Teresa Torres)
+
+### 구조
+
+```
+Desired Outcome (비즈니스/제품 목표)
+├── Opportunity 1 (사용자 니즈/페인)
+│   ├── Solution A
+│   │   └── Experiment (검증 실험)
+│   └── Solution B
+│       └── Experiment
+├── Opportunity 2
+│   ├── Solution C
+│   └── Solution D
+└── Opportunity 3
+```
+
+### 핵심 원칙
+- **Outcome에서 시작**: 기능이 아닌 결과에서 역방향 사고
+- **기회 공간 매핑**: 사용자 인터뷰에서 기회 도출
+- **다수의 솔루션 탐색**: 기회당 최소 3개 솔루션 후보
+- **가정 검증**: 각 솔루션의 핵심 가정을 실험으로 검증
+
+### 적합한 상황
+- Discovery 단계에서 구조화된 탐색 필요
+- 솔루션 편향 방지
+- 팀이 "왜 이것을 만드는가"에 대한 정렬 필요
+
+---
+
+## GitHub Spec Kit (2025.09~)
+
+### 4단계 워크플로우
+
+**1단계: Specify (명세)**
+```markdown
+## Overview
+사용자가 [행동]을 할 수 있는 [기능] 구축
+
+## Goals
+- 목표 1: [측정 가능한 결과]
+- 목표 2: [측정 가능한 결과]
+
+## Non-Goals
+- [명시적으로 하지 않을 것]
+
+## User Experience
+[사용자 관점에서 기능이 어떻게 동작하는지]
+```
+
+**2단계: Plan (계획)**
+```markdown
+## Technical Approach
+- 기술 스택: [사용 기술]
+- 아키텍처: [설계 결정]
+
+## Constraints
+- [기술적 제약]
+- [비즈니스 제약]
+```
+
+**3단계: Tasks (분해)**
+```markdown
+## Phase 1: Foundation
+- [ ] Task 1 (검증: [테스트 방법])
+- [ ] Task 2 (검증: [테스트 방법])
+
+## Phase 2: Core Features
+- [ ] Task 3 (검증: [테스트 방법])
+```
+
+**4단계: Implement (구현)**
+순차적으로 구현, 각 Task 완료 후 검증.
+
+### 적합한 상황
+- AI 코딩 에이전트 활용 개발
+- GitHub Copilot / Claude Code 기반 워크플로우
+- 명세에서 직접 코드 생성
+
+---
+
+## 프레임워크 선택 가이드
+
+| 상황 | 1순위 | 2순위 |
+|------|-------|-------|
+| **신규 제품** | PRFAQ | JTBD |
+| **기능 추가** | JTBD + RICE | Shape Up |
+| **우선순위 결정** | RICE | Opportunity Score |
+| **Discovery 단계** | Opportunity Solution Tree | JTBD |
+| **AI 에이전트 구현** | GitHub Spec Kit | Shape Up |
+| **시간 제약 명확** | Shape Up | RICE |
+
+---
+
+## 출처
+
+- https://productstrategy.co/working-backwards-the-amazon-prfaq-for-product-innovation/
+- https://workingbackwards.com/resources/working-backwards-pr-faq/
+- https://productschool.com/blog/product-fundamentals/prfaq
+- https://basecamp.com/shapeup
+- https://review.firstround.com/build-products-that-solve-real-problems-with-this-lightweight-jtbd-framework/
+- https://productschool.com/blog/product-fundamentals/jtbd-framework
+- https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/
+- https://www.producttalk.org/opportunity-solution-tree/
+- https://github.com/github/spec-kit
+- https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/

package/templates/.claude/skills/prd/references/pm-leaders.md

@@ -0,0 +1,106 @@
+# PM 리더 PRD 인사이트
+
+> Marty Cagan, Shreyas Doshi, Lenny Rachitsky, Kevin Yien
+
+---
+
+## Marty Cagan / SVPG
+
+### Discovery vs Documentation
+- PRD 자체는 문제가 아님 -- Discovery 이후 커뮤니케이션 도구로서는 유용
+- **PRD가 Discovery를 대체하면 문제**: "검증되지 않은 가정의 문서화"에 불과
+- 원격 근무 확산으로 팀들이 진정한 Product Discovery 대신 PRD에 과도하게 의존
+- Discovery 없는 PRD는 엔지니어의 혁신 잠재력을 "거세(neuter)"하는 결과
+
+### Revisiting the Product Spec
+전통적 PRD의 문제: "작성에 너무 오래 걸리고, 거의 읽히지 않으며, 필요한 세부사항을 제공하지 못함"
+
+**대안:** 고충실도 프로토타입(High-Fidelity Prototype)이 진정한 제품 명세
+- 사용자 경험 전체 표현
+- 소프트웨어 동작의 정확한 표현
+- 다중 이해관계자 대응
+- 단일 마스터 표현
+
+### PRD 4대 핵심 섹션
+1. **Purpose (목적)**: 왜 이것을 만드는가
+2. **Features (기능)**: 무엇을 만드는가 ("What", not "How")
+3. **Release Criteria (출시 기준)**: 언제 출시할 수 있는가
+4. **Rough Timing (대략적 일정)**: 스케치 수준의 타임라인
+
+### Opportunity Assessment
+90%의 경우 무거운 PRD 대신 **기회 평가(Opportunity Assessment)**로 충분:
+1. 이것이 어떤 비즈니스 목표를 지원하는가?
+2. 문제를 가지고 있는 고객이 누구인가?
+3. 성공을 어떻게 알 수 있는가?
+4. 가장 큰 리스크는 무엇인가?
+
+---
+
+## Shreyas Doshi (Stripe, Twitter, Google)
+
+### Good PM vs Great PM의 PRD 차이
+
+| Good PM | Great PM |
+|---------|----------|
+| 상세하고 명쾌한 PRD 작성 | **반복적으로(iteratively)** PRD 작성 |
+| 팀이 PRD에 크게 의존 | 엔지니어링/디자인이 PRD에 블로킹되지 않음 |
+| 2개월간 "완벽한 스펙" 후 전달 | "충분한(just enough)" 요구사항으로 병렬 진행 |
+
+**핵심 인사이트:**
+- "비범한 제품에서는 모든 요구사항을 사전에 필요한 수준의 세부사항으로 표현하는 것이 불가능하다"
+- PM-Design-Engineering 간 협업적 발견 프로세스를 만들어야 함
+- 디자인이 탐색을 시작하고 엔지니어링이 아키텍처를 구상할 수 있는 "just enough" 요구사항 제공
+
+### PRD에 반드시 포함할 것
+- **사용 지표 추적 방법**: "이 기능이 어떻게 사용되는지 이해하기 위한 메트릭"
+- PRD는 항상 엔지니어링이 구축 중인 내용을 반영해야 함
+- PRD 변경은 불가피하며, 이를 관리하는 프로세스가 중요
+
+---
+
+## Lenny Rachitsky
+
+### PRD 작성 핵심
+- **짧고 간결한 형식** 강조
+- **솔루션보다 문제 정의에 우선순위**
+- 실제 작성된 PRD와 1-Pager 예시 공개
+- Confluence에서 공식 템플릿으로 채택됨
+
+### Lenny의 1-Pager 구조
+전체 PRD 대신 1-페이지 요약으로 시작하는 접근법 권장. 필요시 확장.
+
+---
+
+## Kevin Yien (Stripe, Square, Mutiny)
+
+### 5단계 PRD 프로세스
+1. **초안** → 2. **문제 검토** → 3. **솔루션 검토** → 4. **출시 검토** → 5. **출시**
+
+### 핵심 특징
+
+**Non-Goals 섹션:**
+범위 제한을 명확히 -- 무엇을 만들지 않을지 정의. AI 에이전트 시대에 특히 중요.
+
+**"둘레 그리기(Perimeter Drawing)":**
+Shape Up과 유사하게 솔루션을 적절한 추상화 수준에서 유지. 엔지니어링/디자인 판단 여지 보존. 과도한 상세는 오히려 혁신을 저해.
+
+**Contributor Review 섹션:**
+"아무도 동의하지 않은 것을 만드는" 실패 방지. 이해관계자 정렬 문서화.
+
+**"쓰기(writing)는 대규모 명확성(clarity at scale)"** -- PM의 핵심 역량
+
+---
+
+## 출처
+
+- https://www.svpg.com/discovery-vs-documentation/
+- https://www.svpg.com/revisiting-the-product-spec/
+- https://www.svpg.com/assessing-product-opportunities/
+- https://www.cimit.org/documents/20151/228904/How%20To%20Write%20a%20Good%20PRD.pdf
+- https://shreyasdoshi.com/good-product-managers-great-product-managers/
+- https://shreyasdoshi.typepad.com/main/2008/01/how-to-deal-wit.html
+- https://www.lennysnewsletter.com/p/prds-1-pagers-examples
+- https://www.lennysnewsletter.com/p/my-favorite-templates-issue-37
+- https://www.atlassian.com/software/confluence/templates/lennys-product-requirements
+- https://almanac.io/docs/template-product-requirements-documentby-kevinyien-14ca95049c0a56c42842e34153d6ea72
+- https://www.lennysnewsletter.com/p/unorthodox-pm-wisdom-kevin-yien

package/templates/.claude/skills/prd/references/trends-2026.md

@@ -0,0 +1,157 @@
+# 2026 PRD 트렌드
+
+> Product School, Ant Murphy, Atlassian, GitHub, Thoughtworks, OpenAI
+
+---
+
+## 핵심 패러다임 전환
+
+| 기존 | 2026 |
+|------|------|
+| 기능 목록(Feature List) | **Outcome 중심** (결과 기반) |
+| 정적 문서 | **Living Document** (지속 진화) |
+| 인간 정렬 도구 | **AI 실행 가능 명세서** |
+| PM이 완성 후 전달 | **반복적 작성, 병렬 진행** |
+| 상세할수록 좋음 | **간결하고 결정 중심** |
+| 기능 출시 = 성공 | **Landing Review** (출시 후 성과 평가) |
+
+---
+
+## Spec-Driven Development
+
+Thoughtworks, GitHub, Tessl이 주도하는 새 패러다임.
+
+**정의:** "잘 작성된 소프트웨어 요구사항 명세를 프롬프트로 사용하여 AI 코딩 에이전트가 실행 가능한 코드를 생성하는 개발 패러다임"
+
+**AGENTS.md 표준:** Google, OpenAI, Factory, Sourcegraph, Cursor가 공동 출시한 벤더 중립 마크다운 표준. AI 에이전트가 리포지토리를 이해하기 위한 공통 형식.
+
+**비판 (Scott Logic, 2025.11):** "재발명된 워터폴?" -- 기존 워터폴과 구별하는 것은 AI의 빠른 피드백 루프.
+
+---
+
+## Outcome 중심 PRD
+
+### Before (기능 중심)
+```
+기능: 사용자 프로필 편집 페이지 구현
+- 이름, 이메일, 프로필 이미지 편집
+- 실시간 검증
+- 저장 버튼
+```
+
+### After (Outcome 중심)
+```
+목표: 사용자 프로필 완성률 40% → 75% 달성
+- 문제: 사용자의 60%가 프로필을 미완성 상태로 방치
+- 가설: 편집 UX 간소화 시 완성률 증가
+- 성공 지표: 프로필 완성률 75%, 편집 이탈률 20% 감소
+- 기능: (위 지표 달성을 위한 수단으로서의 기능)
+```
+
+### Landing Review
+출시 수개월 후 실시하는 평가 의식:
+- 채택률 (얼마나 많은 사용자가 실제 사용하는가?)
+- 행동 변화 (사용자 행동이 의도대로 변했는가?)
+- 비즈니스 성과 (KPI가 실제로 개선되었는가?)
+- 학습 (예상과 다른 결과에서 무엇을 배웠는가?)
+
+---
+
+## Continuous PRD (지속적 PRD)
+
+OpenAI의 Miqdad Jaffer가 제안한 **"Continuous PRM Mode"**:
+
+| 단계 | PRD 상태 | 활동 |
+|------|----------|------|
+| **Discovery** | Brief (1-2페이지) | 고객 인터뷰, 가설 검증 |
+| **Shaping** | Draft PRD | 요구사항 구체화, 기술 검토 |
+| **Building** | Living PRD | 개발 중 발견사항 반영 |
+| **Launch** | Final PRD | 출시 기준 확정 |
+| **Post-Launch** | Updated PRD | Landing Review 결과 반영 |
+
+PRD는 완성되는 것이 아니라 **지속적으로 진화**.
+
+---
+
+## PM 역할 변화
+
+### AI 도구의 영향
+- PRD 작성/편집/포맷에 소요되던 시간의 **40-60% 절약** (주당 6-9시간)
+- 94%의 프로덕트 전문가가 AI를 자주 사용
+- 절반 가까이가 워크플로우에 깊이 내장
+
+### 역할 전환
+- **문서 작성자** → **의사결정자**: AI가 초안을 작성, PM은 판단과 결정에 집중
+- **기능 정의자** → **Outcome 설계자**: 무엇을 만들지보다 어떤 결과를 달성할지
+- **프로세스 관리자** → **Discovery 리더**: 가설 수립, 실험 설계, 학습 루프
+
+### 핵심 역량 변화
+- **학습 속도가 곧 경쟁 우위**: AI로 누구나 제품 경험을 몇 주 만에 복제 가능
+- PM의 차별화 = 고객 이해 깊이 + 전략적 판단 + 실험 설계
+
+---
+
+## Prompt Requirements Document (PmRD)
+
+"Vibe Coding 시대"를 위한 새로운 개념:
+- AI와 인간이 함께 이해할 수 있는 구조화된 프롬프트
+- PRD의 정밀함 + 프롬프트의 실행 가능성 결합
+- 아직 초기 개념이지만 Spec-Driven Development와 수렴 중
+
+---
+
+## AI 제품 특화 PRD (OpenAI 템플릿)
+
+일반 PRD에 추가되는 AI 전용 Non-functional Requirements:
+
+| 항목 | 기준 |
+|------|------|
+| **정확도** | >= 90% |
+| **환각률** | < 2% |
+| **응답시간 SLA** | < 500ms |
+| **가동시간** | 99.9% |
+| **편향 감사** | 월간 인간 검증 |
+| **RAG 통합** | 문서 기반 응답 |
+| **보안** | GDPR, OWASP 준수 |
+
+주의: AI 제품 개발 시에만 적용. 일반 소프트웨어 PRD에는 해당 없음.
+
+---
+
+## 빅테크 PRD 공통 패턴 (12개 기업 분석)
+
+| 섹션 | 포함 빈도 |
+|------|-----------|
+| Overview / Problem Statement | 12/12 |
+| Key Features / Scope | 12/12 |
+| Success Metrics / KPIs | 12/12 |
+| Target Users / Personas | 11/12 |
+| Technical Requirements | 10/12 |
+| Timeline / Milestones | 9/12 |
+| User Stories / Use Cases | 8/12 |
+
+### 기업별 특징
+
+| 기업 | PRD 특징 |
+|------|----------|
+| **Google** | 데이터 기반 문제 정의, 구체적 메트릭 (12% 만족도 향상) |
+| **Amazon** | 정의된 페르소나, 3개월 내 25% 참여 증가 목표 |
+| **Stripe** | 타깃 세그먼트별 정의, 99.99% 가동시간 |
+| **Spotify** | 사용자 중심, 35% 발견율 증가, 85% 추천 정확도 |
+| **Linear** | 거부된 대안 분석 포함, 구체적 마일스톤 (Internal → Beta → GA) |
+| **Airbnb** | 전환 중심, 모바일 우선, 18% 전환율 향상 |
+
+---
+
+## 출처
+
+- https://productschool.com/blog/product-fundamentals/product-management-trends
+- https://antmurphy.medium.com/how-product-is-changing-in-2026-78a08f150aca
+- https://www.atlassian.com/blog/announcements/state-of-product-2026
+- https://www.productcompass.pm/p/ai-prd-template
+- https://pmprompt.com/blog/prd-examples
+- https://medium.com/@takafumi.endo/prompt-requirements-document-prd-a-new-concept-for-the-vibe-coding-era-0fb7bf339400
+- https://blog.scottlogic.com/2025/11/26/putting-spec-kit-through-its-paces-radical-idea-or-reinvented-waterfall.html
+- https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
+- https://www.news.aakashg.com/p/ai-prd
+- https://www.oreateai.com/blog/ai-prd-generator/