मैं जिस PRD जनरेटर स्किल का उपयोग करता हूँ, उसका परिचय
शुरुआत
जब feature implementation अटकती है, तो बहुत बार समस्या code लिखना शुरू करने के बाद नहीं बल्कि उससे पहले आती है। क्या बनाना है, कितनी सीमा तक बनाना है, किस क्रम में इसे तोड़ना है, और मौजूदा codebase में किस चीज़ को reference करना है, अगर यह साफ़ न हो और हम सीधे implementation में चले जाएँ, तो agent भी डगमगाता है और इंसान भी।
इसीलिए मैं PRD को सिर्फ planning document नहीं मानता। आज के AI coding environment में PRD लगभग execution plan के बराबर है। खासकर अगर आप Claude Code जैसे coding agent का इस्तेमाल कर रहे हैं, तो क्या बनाना है से भी ज़्यादा अहम यह है कि उसे किस तरह structure करके सौंपा जाता है।
इस लेख में मैं अपने इस्तेमाल के .claude/skills/prd-generator स्किल का परिचय देना चाहता हूँ। यह स्किल नए feature requirements को interactive तरीके से इकट्ठा करके उन्हें ऐसे PRD document में व्यवस्थित करती है जिसे Claude Code सीधे implementation phase में ले जा सके। चूँकि यह material sharing के लिए लिखा गया पोस्ट है, इसलिए बीच-बीच में सिर्फ summary पर नहीं रुकूँगा; अंत में SKILL.md और template का पूरा text भी साथ में छोड़ूँगा।
ऐसी स्किल की जरूरत क्यों पड़ी
किसी feature को बनाने से पहले बस मोटा-मोटा note छोड़ देना और सचमुच implement करने योग्य PRD बनाना, दोनों बिल्कुल अलग काम हैं।
सरल idea notes तेज़ होते हैं, लेकिन उनमें बहुत कुछ जल्दी छूट जाता है।
- core feature लिखा है, लेकिन user scenario नहीं है
- implementation plan है, लेकिन acceptance criteria नहीं हैं
- reference करने लायक existing code है, लेकिन उससे connection नहीं बनता
- बाद में कौन-सी implementation skill इस्तेमाल करनी है, यह छूट जाता है
- document कहाँ और किस नाम से save करना है, यह हर बार बदल जाता है
ऐसी स्थिति में document होने पर भी काम सीधे execution तक नहीं पहुँचता। आखिर में फिर से सवाल पूछने पड़ते हैं, फिर से व्यवस्थित करना पड़ता है, और फिर से structure बनानी पड़ती है।
prd-generator ठीक इसी बीच की बर्बादी को कम करने के लिए बनाया गया स्किल है। अगर सवाल पूछने का क्रम, document format, save rules, implementation steps, और implementation skill linkage एक साथ तय हों, तो PRD सिर्फ explanation नहीं रहता, बल्कि तुरंत इस्तेमाल की जा सकने वाली execution unit बन जाता है।
इस स्किल को एक वाक्य में समझाऊँ तो
मैं इस स्किल को सबसे छोटे रूप में यूँ बताता हूँ।
prd-generator एक ऐसी स्किल है जो नए फ़ीचर की आवश्यकताओं को संवादात्मक तरीके से इकट्ठा करती है और फिर उन्हें Claude Code के execution के लिए अनुकूलित व्यापक PRD दस्तावेज़ में बदल देती है।
असल structure भी बहुत simple है।
.claude/skills/prd-generator/
SKILL.md
assets/
prd_template.md
लेकिन simple folder structure की तुलना में इसकी भूमिका काफी बड़ी है। यह सिर्फ कुछ सवाल पूछकर खत्म नहीं हो जाती; document save rules से लेकर implementation plan के format, acceptance criteria, और आगे कौन-सी implementation skill इस्तेमाल करनी है, यह सब भी साथ में तय करती है।
वर्कफ़्लो को देखकर design intent और साफ़ दिखता है
इस स्किल की सबसे बड़ी ताकत इसका conversation flow है। PRD को एक बार में लिख देने के बजाय इसे ऐसे बनाया गया है कि जरूरी जानकारी एक-एक करके सही क्रम में इकट्ठा हो।
चरण 1: फ़ीचर अन्वेषण
सबसे पहले यह feature overview, core capability और main use cases के बारे में पूछती है।
यहाँ अहम बात यह है कि सारे सवाल एक साथ नहीं फेंके जाते। Skill document में साफ़ लिखा है कि सभी प्रश्न एक साथ नहीं पूछने चाहिए। यह एक पंक्ति उम्मीद से ज़्यादा महत्वपूर्ण है। अच्छा PRD प्रश्नावली की तरह एक साथ निकाल नहीं लिया जाता; वह जवाबों के साथ दायरा संकरा करते हुए बनता है।
चरण 2: reference implementation की पुष्टि
इसके बाद यह existing code या implementation pattern के बारे में पूछती है।
यह चरण इसलिए अच्छा है क्योंकि वास्तविक काम में नया feature पूरी तरह खाली canvas पर बनने से ज़्यादा बार मौजूदा structure का पालन करते हुए बनाया जाता है। Path लेकर, follow करने वाले pattern और rules की पुष्टि हो जाने पर PRD अब abstract planning document नहीं रह जाता, बल्कि सीधे codebase को छूने वाला working document बन जाता है।
चरण 3: scalability और architecture
फिर यह future growth, integration points और performance requirements के बारे में पूछती है।
मुझे यह हिस्सा खास तौर पर पसंद है। साधारण feature implement करते समय भी अक्सर यह लालच रहता है कि फिलहाल बस किसी तरह चलने लायक बना दिया जाए। लेकिन यह स्किल शुरुआत से ही scalability से जुड़े सवाल जोड़ती है, ताकि कम से कम न्यूनतम स्तर पर ही सही, भविष्य का बोझ document में दर्ज हो जाए।
चरण 4: save location का निर्धारण
यहाँ user से पूरा directory path तय नहीं करवाया जाता। सिर्फ filename confirm किया जाता है, और document generation rules के हिसाब से save path अपने-आप calculate हो जाता है।
यह चुनाव भी काफी practical है। अगर इंसान को हर बार path और filename दोनों पर एक साथ सोचना पड़े, तो documents बिखर जाते हैं। उल्टा, अगर save rules तय हों, तो बाद में document ढूँढना आसान हो जाता है और PRD काम की asset के रूप में जमा होते जाते हैं।
चरण 5: वास्तविक PRD बनाना
अंतिम चरण में यह template पढ़ती है, placeholders भरती है, implementation skills तय करती है, और document पूरा करती है।
यहीं इस स्किल की पहचान सबसे साफ़ दिखती है। इसका लक्ष्य सिर्फ planning document लिखना नहीं, बल्कि नीचे दिए गए तत्वों को बिना छोड़े भरने वाला execution-oriented PRD बनाना है।
- feature name और overview
- detailed feature description
- reference implementation
- scalability considerations
- 4-step implementation plan
- हर चरण के acceptance criteria
- file structure
- core implementation details
- test strategy
- potential challenges और solutions
- future improvements
- implementation में इस्तेमाल होने वाली skills
इसके साथ document generation rules होना भी महत्वपूर्ण है
prd-generator सिर्फ अच्छे सवाल पूछने वाली स्किल नहीं है। यह generated PRD को कहाँ save करना है, इसे भी काफी सख्ती से तय करती है।
documents/PRD/{연}-{월}-{주차}w/{일}d-{hh}h-{파일명}.md
यह नियम सोच से ज़्यादा महत्वपूर्ण है। अगर document को project asset के रूप में छोड़ना है, तो सिर्फ content नहीं, save करने का तरीका भी consistent होना चाहिए। यह स्किल week calculation rules तक तय करती है और अगर directory मौजूद न हो, तो उसे अपने-आप बनाने की बात भी साफ़ लिखती है।
यानी यह स्किल सिर्फ दस्तावेज़ को अच्छी तरह लिखने पर नहीं रुकती, बल्कि उसे बाद में भी manage किए जा सकने वाले काम के asset के रूप में छोड़ने तक ध्यान देती है।
लंबा template दरअसल फायदा है
इस स्किल के template को पहली बार देखने पर यह काफी लंबा लग सकता है। लेकिन मेरे हिसाब से यही इसकी ताकत है।
छोटा template तेज़ होता है, लेकिन उतनी ही जगह इंसान को खुद भरनी पड़ती है। इसके उलट, यह template शुरुआत से ही लगभग सभी जरूरी खानों को सामने खोल देता है।
- overview
- feature description
- reference implementation
- core features
- scalability considerations
- 4-step implementation plan
- file structure
- core implementation details
- test strategy
- potential challenges और solutions
- future improvements
- implementation में इस्तेमाल होने वाली skills
- Claude Code execution notes
इतने सारे headings खुले हों, तो कम से कम यह तुरंत दिख जाता है कि क्या छूटा है। मैं PRD template की असली value यहीं देखता हूँ। अच्छा template दस्तावेज़ को सुंदर बनाने वाला tool नहीं, बल्कि सोच में होने वाली omissions कम करने वाला tool है।
Implementation skill linkage ही इस स्किल का केंद्र है
इस स्किल में मुझे सबसे पसंद आने वाला हिस्सा अलग है। PRD बनाते समय यह कौन-सी implementation skills इस्तेमाल करनी हैं, उनका निर्णय लेकर उन्हें document में शामिल करती है।
कई PRD document पर ही खत्म हो जाते हैं। लेकिन असली काम उसके बाद शुरू होता है। अगर कौन-सी implementation skill चाहिए और किस क्रम में उसे बुलाना है, यह जुड़ा न हो, तो PRD और implementation फिर अलग हो जाते हैं।
prd-generator इसे रोकने के लिए implementation skill linkage section अलग से रखता है।
मौजूदा document के आधार पर यह खास तौर पर इन दो skills पर फैसला करता है।
| स्किल नाम | सक्रिय होने की शर्त | जिम्मेदारी का दायरा |
|---|---|---|
endpoint-implement-skill | Entity, Repository, Service, Controller, DTO में से एक भी शामिल हो | CRUD API की पूरी layer का implementation |
sse-streaming-skill | SSE streaming, TEXT_EVENT_STREAM_VALUE, या real-time response शामिल हो | SSE controller/service implementation |
यह decision logic अच्छा इसलिए है क्योंकि इससे PRD सिर्फ description नहीं रहता, बल्कि अगला action तय करने वाला document बन जाता है।
उदाहरण के लिए, अगर Entity से Controller तक पूरा feature चाहिए, तो यह साफ़ छोड़ा जा सकता है कि endpoint-implement-skill इस्तेमाल करना है। अगर AI response streaming जैसी जरूरत हो, तो यह भी बताया जा सकता है कि sse-streaming-skill किस चरण में जोड़ना है। ऐसी link मौजूद हो, तो document पढ़ने वाला इंसान हो या agent, दोनों बहुत कम भटकते हैं।
यह स्किल किन स्थितियों में खास काम आती है
यह स्किल हर स्थिति में जरूरी नहीं है। लेकिन नीचे की परिस्थितियों में यह खास तौर पर मज़बूत है।
- जब नए feature को बिल्कुल शुरुआत से design करना हो
- जब reference करने लायक existing code साफ़ तौर पर मौजूद हो
- जब feature requirements तो हों, लेकिन implementation order अभी धुँधला हो
- जब आगे Claude Code या किसी दूसरी implementation skill तक सीधे handoff करने की योजना हो
- जब document को team asset की तरह बचाकर रखना हो
इसके उलट, अगर सिर्फ बहुत छोटा setting change या मामूली fix चाहिए, तो यह थोड़ा भारी लग सकता है। यह हल्के note के लिए बना tool कम और feature development को structure करके handoff करने वाला tool ज़्यादा है।
साझा संदर्भ के लिए पूरा मूल पाठ भी रखता हूँ
अब तक का हिस्सा explanation था; नीचे से actual material sharing के लिए appendix है। आपके अनुरोध के अनुसार, .claude/skills/prd-generator की मुख्य सामग्री बिना संक्षेप किए देखने के लिए SKILL.md और assets/prd_template.md का पूरा text साथ में छोड़ रहा हूँ।
परिशिष्ट 1. .claude/skills/prd-generator/SKILL.md का पूरा पाठ
---
name: prd-generator
description: 기능 개발을 위한 대화형 PRD(제품 요구사항 문서) 생성기. 사용자가 새로운 기능에 대한 체계적인 구현 계획을 작성하고자 할 때 사용합니다. 이 스킬은 대화형 질문을 통해 요구사항을 수집한 후, Claude Code 실행에 최적화된 포괄적인 PRD 문서를 생성합니다. "PRD 만들어줘", "기능 기획해줘", "구현 계획 작성해줘", "기능 요구사항 문서화해줘" 등의 요청 시 활성화됩니다.
---
# PRD Generator (한글 버전)
이 스킬은 대화형 질문 프로세스를 통해 포괄적인 제품 요구사항 문서(PRD)를 생성합니다. 생성된 PRD는 Claude Code가 구현 계획을 효율적으로 실행할 수 있도록 최적화되어 있습니다.
## 워크플로우
스킬이 활성화되면 다음 대화형 워크플로우를 따르세요:
### 1단계: 기능 탐색
사용자가 원하는 기능에 대해 질문합니다. 다음 가이드 질문을 사용하세요 (상황에 맞게 조정):
1. **기능 개요**: "어떤 기능을 구현하고 싶으신가요? 상위 수준의 설명을 제공해주세요."
2. **기능 상세**: "이 기능의 핵심 기능과 사용자 상호작용을 설명해주실 수 있나요?"
3. **사용 사례**: "이 기능의 주요 사용 사례나 시나리오는 무엇인가요?"
사용자 응답을 기다린 후 진행하세요. 모든 질문을 한 번에 던지지 마세요.
### 2단계: 참조 구현
참조로 사용할 수 있는 기존 코드에 대해 질문합니다:
1. **기존 구현**: "참조해야 할 기존 코드나 구현이 있나요?"
2. **파일 경로**: 있다면: "이러한 참조 구현의 파일 경로는 무엇인가요?"
3. **따라야 할 패턴**: "이러한 참조에서 따라야 할 특정 패턴, 아키텍처 또는 규칙이 있나요?"
### 3단계: 확장성 및 아키텍처
확장성 및 확장 가능성에 대한 정보를 수집합니다:
1. **향후 성장**: "어떤 확장성 고려사항을 다루어야 하나요? 예: 사용자 부하, 데이터 볼륨, 기능 확장 등"
2. **통합 지점**: "이 기능이 다른 시스템이나 서비스와 통합되어야 하나요?"
3. **성능 요구사항**: "특정 성능 요구사항이나 제약사항이 있나요?"
### 4단계: 저장 위치
PRD 문서는 **문서 생성 규칙**에 따라 자동으로 경로가 결정됩니다.
사용자에게 파일명만 확인받고, 디렉토리는 자동 생성합니다.
1. **파일명 확인**: "PRD 문서의 파일명을 지정해주세요 (예: `AI_SCENARIO_GENERATOR`)"
- 제공되지 않으면 기능명을 UPPER_SNAKE_CASE로 변환하여 사용
---
## 문서 생성 규칙
### 디렉토리 구조
```
documents/PRD/{연}-{월}-{주차}w/
```
- **연**: 4자리 연도 (예: 2025)
- **월**: 2자리 월 (예: 12)
- **주차**: 해당 월의 주차 (1~5) + `w` 접미사 (week의 약자)
**주차 계산**: 해당 월 1일부터 시작하여 7일 단위로 계산
- 1~7일: 1w (1주차)
- 8~14일: 2w (2주차)
- 15~21일: 3w (3주차)
- 22~28일: 4w (4주차)
- 29일~: 5w (5주차)
### 파일명 형식
```
{일}d-{hh}h-{파일명}.md
```
- **일**: 2자리 일 + `d` 접미사 (day의 약자, 예: 27d)
- **hh**: 2자리 시간(24시간제) + `h` 접미사 (hour의 약자, 예: 14h)
- **파일명**: UPPER_SNAKE_CASE (예: AI_SCENARIO_GENERATOR)
### 예시
2025년 12월 27일 14시에 AI 시나리오 생성기 PRD 생성 시:
```
documents/PRD/2025-12-4w/27d-14h-AI_SCENARIO_GENERATOR.md
```
### 디렉토리 자동 생성
지정된 디렉토리가 없으면 자동으로 생성합니다.
### 5단계: PRD 생성
모든 정보가 수집되면:
1. `assets/prd_template.md`에서 템플릿 읽기
2. **구현 시 사용할 스킬 판단** (아래 "구현 스킬 연동" 섹션 참조)
3. 다음 내용으로 모든 템플릿 플레이스홀더를 채워 포괄적인 PRD 생성:
- 기능 이름 및 개요
- 상세한 기능 설명
- 참조 구현 세부사항 (제공된 경우)
- 확장성 고려사항
- 구체적인 작업이 포함된 4단계 구현 계획
- 각 단계별 수용 기준
- 파일 구조 개요
- 논리적 섹션으로 나뉜 핵심 구현 세부사항
- 테스트 전략
- 잠재적 과제 및 해결책
- 향후 개선 아이디어
- **구현 시 사용할 스킬 (필수)**
3. 적절한 구조로 PRD 생성:
- 명확한 단계별 구현 계획
- 구체적이고 실행 가능한 작업
- 구체적인 수용 기준
- Claude Code가 따를 수 있는 기술적 세부사항
- 파일 조직 지침
4. 지정된 경로에 PRD 저장
5. 사용자에게 문서 링크 제공
## 템플릿 구조
PRD 템플릿(`assets/prd_template.md`)은 다음을 포함합니다:
- **개요**: 기능의 상위 수준 요약
- **기능 설명**: 상세한 기능
- **참조 구현**: 기존 코드에 대한 링크
- **기술 요구사항**: 핵심 기능 및 확장성
- **구현 계획**: 작업 및 수용 기준이 포함된 4단계
- 1단계: 설정 및 기반
- 2단계: 핵심 구현
- 3단계: 통합 및 테스트
- 4단계: 다듬기 및 최적화
- **파일 구조**: 제안된 디렉토리 레이아웃
- **핵심 구현 세부사항**: 기술적 세부사항
- **테스트 전략**: 구현 검증 방법
- **과제 및 해결책**: 예상되는 문제
- **향후 개선사항**: 확장 지점
- **Claude Code 실행 참고사항**: PRD 사용 방법
## 모범 사례
1. **대화형으로 진행**: 한 번에 한두 가지 질문을 자연스럽게 던지세요
2. **질문 조정**: 사용자 응답에 따라 후속 질문을 맞춤화하세요
3. **모호함 명확화**: 사용자 응답이 모호하면 구체적인 예를 요청하세요
4. **모듈식 사고**: 복잡한 기능을 논리적 단계로 나누세요
5. **구체적으로**: 추상적인 목표가 아닌 구체적인 작업을 생성하세요
6. **코드 참조**: 참조 구현이 있다면 읽고 패턴을 통합하세요
7. **확장성 고려**: 간단한 기능이라도 항상 확장성 고려사항을 포함하세요
8. **실행 가능하게**: 각 단계는 Claude Code가 실행할 수 있는 명확한 작업이 있어야 합니다
## 대화 흐름 예시
```
사용자: "사용자 인증 시스템에 대한 PRD를 만들고 싶어요"
Claude: "좋습니다! 사용자 인증 시스템에 대한 포괄적인 PRD를 작성하도록 도와드리겠습니다.
먼저, 원하시는 핵심 기능을 설명해주시겠어요? 예를 들어:
- 어떤 인증 방법을 사용하나요? (이메일/비밀번호, OAuth 등)
- 어떤 사용자 역할이나 권한이 필요한가요?
- 특정 보안 요구사항이 있나요?"
사용자: [세부사항 제공]
Claude: "감사합니다! 제가 참조해야 할 기존 인증 코드나 유사한 구현이 코드베이스에 있나요?"
사용자: [경로 제공 또는 없다고 답변]
Claude: "어떤 확장성 고려사항을 염두에 두어야 할까요? 예를 들어:
- 예상 사용자 수는?
- 속도 제한이 필요한가요?
- 세션 관리 전략은?"
사용자: [세부사항 제공]
Claude: "마지막으로, 이 PRD 문서를 어디에 저장하시겠어요?"
사용자: [경로 제공 또는 Claude가 기본값 사용하도록 함]
Claude: [포괄적인 PRD 생성 및 저장]
"사용자 인증 시스템에 대한 PRD를 작성했습니다. [문서 보기](computer:///path/to/prd.md)"
```
## PRD 생성 팁
- **1단계**는 설정에 집중: 의존성, 기본 구조, 구성
- **2단계**는 핵심 기능 구현
- **3단계**는 통합 지점 및 테스트 처리
- **4단계**는 다듬기 추가: 오류 처리, 엣지 케이스, 최적화
- 각 단계는 이전 단계를 기반으로 구축되어야 함
- 수용 기준은 테스트 가능하고 구체적이어야 함
- 참조 구현 패턴을 따르는 파일 구조 포함 (제공된 경우)
- **모든 내용은 한글로 작성**: 기능 설명, 작업, 수용 기준, 주석 등 모두 한글로 작성
---
## 구현 스킬 연동 (핵심)
PRD 생성 시 **반드시** 구현에 필요한 스킬을 판단하여 문서에 포함해야 합니다.
이를 통해 구현 일관성을 확보하고, 프로젝트 규약을 자동으로 준수할 수 있습니다.
### 스킬 판단 기준
| 스킬명 | 활성화 조건 | 담당 범위 |
|--------|------------|----------|
| `endpoint-implement-skill` | Entity, Repository, Service, Controller, DTO 중 **하나라도** 포함 | CRUD API 전체 레이어 구현 |
| `sse-streaming-skill` | SSE 스트리밍, `TEXT_EVENT_STREAM_VALUE`, 실시간 응답 포함 | SSE 컨트롤러/서비스 구현 |
### 스킬 판단 로직
PRD 내용을 분석하여 다음 키워드가 있으면 해당 스킬 사용을 안내합니다:
**endpoint-implement-skill 활성화 키워드:**
- Entity, 엔티티
- Repository, 레포지토리, JPA
- Service, 서비스
- Controller, 컨트롤러, API 엔드포인트
- DTO, Request, Response
- CRUD, 생성, 조회, 수정, 삭제
**sse-streaming-skill 활성화 키워드:**
- SSE, Server-Sent Events
- TEXT_EVENT_STREAM_VALUE
- 스트리밍 응답, 실시간 스트리밍
- SseEmitter, Flux<ServerSentEvent>
- 실시간 이벤트 전송
### PRD에 작성할 스킬 안내 예시
```markdown
## 구현 시 사용할 스킬
이 PRD를 구현할 때 다음 스킬을 **반드시** 활용하세요:
| 구현 영역 | 사용 스킬 | 활성화 조건 |
|----------|----------|------------|
| Entity ~ Controller | `endpoint-implement-skill` | 시나리오 CRUD API 구현 필요 |
| SSE 스트리밍 | `sse-streaming-skill` | AI 응답 실시간 스트리밍 필요 |
### 스킬 사용 순서
1. **1단계 (Entity/Repository)**: `endpoint-implement-skill` 호출
- Entity 정의, Repository 생성
2. **2단계 (Service/Controller)**: `endpoint-implement-skill` 계속 사용
- Service 비즈니스 로직, Controller 엔드포인트
3. **3단계 (SSE 통합)**: `sse-streaming-skill` 호출
- SSE 컨트롤러, 스트리밍 서비스 구현
### 스킬별 담당 범위
**endpoint-implement-skill:**
- `entity/Scenario.kt`, `entity/Character.kt` 등 Entity 파일
- `ScenarioRepository.kt` 등 Repository 인터페이스
- `ScenarioService.kt` 등 Service 클래스
- `ScenarioController.kt` 등 Controller 클래스
- `ScenarioRequestDto.kt`, `ScenarioResponseDto.kt` 등 DTO
**sse-streaming-skill:**
- `GameChatSseController.kt` SSE 전용 컨트롤러
- `GameChatStreamService.kt` 스트리밍 서비스
- SSE 이벤트 타입, 이미터 설정
```
### 복합 스킬 사용 시 주의사항
1. **스킬 간 경계를 명확히**: Entity~Controller는 endpoint-implement-skill, SSE 전용 로직은 sse-streaming-skill
2. **순서 준수**: 기반 Entity/Service가 먼저, SSE 통합은 나중에
3. **스킬 호출 시점 명시**: PRD의 각 단계에서 어떤 스킬을 호출해야 하는지 명시
### 스킬이 필요 없는 경우
다음 경우에는 스킬 연동 섹션을 생략할 수 있습니다:
- 설정 파일(application.yml) 변경만 필요한 경우
- 기존 코드 수정/리팩토링만 필요한 경우
- 문서화, 마이그레이션 가이드 등 비코드 작업
परिशिष्ट 2. .claude/skills/prd-generator/assets/prd_template.md का पूरा पाठ
# PRD: {{기능명}}
## 개요
{{기능_개요}}
## 기능 설명
{{기능_상세_설명}}
## 참조 구현
{{참조_구현}}
## 기술 요구사항
### 핵심 기능
{{핵심_기능}}
### 확장성 고려사항
{{확장성_고려사항}}
## 구현 계획
### 1단계: 설정 및 기반
**목표**: {{1단계_목표}}
**작업**:
1. {{1단계_작업1}}
2. {{1단계_작업2}}
3. {{1단계_작업3}}
**수용 기준**:
- {{1단계_수용기준1}}
- {{1단계_수용기준2}}
---
### 2단계: 핵심 구현
**목표**: {{2단계_목표}}
**작업**:
1. {{2단계_작업1}}
2. {{2단계_작업2}}
3. {{2단계_작업3}}
**수용 기준**:
- {{2단계_수용기준1}}
- {{2단계_수용기준2}}
---
### 3단계: 통합 및 테스트
**목표**: {{3단계_목표}}
**작업**:
1. {{3단계_작업1}}
2. {{3단계_작업2}}
3. {{3단계_작업3}}
**수용 기준**:
- {{3단계_수용기준1}}
- {{3단계_수용기준2}}
---
### 4단계: 다듬기 및 최적화
**목표**: {{4단계_목표}}
**작업**:
1. {{4단계_작업1}}
2. {{4단계_작업2}}
3. {{4단계_작업3}}
**수용 기준**:
- {{4단계_수용기준1}}
- {{4단계_수용기준2}}
## 파일 구조
```
{{파일_구조}}
```
## 핵심 구현 세부사항
### {{세부사항1_제목}}
{{세부사항1_내용}}
### {{세부사항2_제목}}
{{세부사항2_내용}}
### {{세부사항3_제목}}
{{세부사항3_내용}}
## 테스트 전략
{{테스트_전략}}
## 잠재적 과제 및 해결책
{{과제_및_해결책}}
## 향후 개선사항
{{향후_개선사항}}
## 구현 시 사용할 스킬
이 PRD를 구현할 때 다음 스킬을 **반드시** 활용하세요:
| 구현 영역 | 사용 스킬 | 활성화 조건 |
|----------|----------|------------|
| {{skill_table_rows}} |
### 스킬 사용 순서
{{skill_usage_order}}
### 스킬별 담당 범위
{{skill_coverage}}
---
## Claude Code 실행 참고사항
이 PRD는 순차적 구현을 위해 구조화되었습니다:
1. 1단계 작업부터 순서대로 시작
2. 각 단계는 이전 단계를 기반으로 구축됨
3. 다음 단계로 넘어가기 전에 수용 기준 검증
4. 구체적인 지침은 "핵심 구현 세부사항" 섹션 참조
5. 각 단계 검증 시 "테스트 전략" 사용
6. **위 "구현 시 사용할 스킬" 섹션의 스킬을 반드시 활용하여 구현 일관성 확보**
समापन
मेरा मानना है कि जैसे-जैसे AI coding environment तेज़ होता जाएगा, सिर्फ implementation अच्छी होना पर्याप्त नहीं रहेगा; implementation में जाने से ठीक पहले चीज़ों को व्यवस्थित करने की क्षमता और महत्वपूर्ण होगी। prd-generator ठीक उसी बिंदु को संभालने वाला स्किल है।
यह स्किल कोई बहुत भव्य काम नहीं करती। यह feature के बारे में पूछती है, reference implementation देखती है, scalability पर सवाल करती है, save rules लागू करती है, और सब कुछ implementation करने योग्य PRD में व्यवस्थित करती है। लेकिन एक बार यह process structure में बदल जाए, तो उसके बाद implementation कहीं कम अस्थिर होता है।
अगर आप Claude Code के साथ अक्सर feature development करते हैं, लेकिन हर बार idea तो होता है और execution plan धुँधला रहता है, जिस वजह से शुरुआत देर से होती है, तो मैं सबसे पहले इस स्किल को व्यवस्थित करने की सलाह दूँगा। उम्मीद से कहीं अधिक productivity तेज़ code लिखने से नहीं, बल्कि code लिखने से पहले ज़्यादा सटीक तैयारी करने से आती है।
संलग्नक
स्किल से generated एक document भी साथ में संलग्न कर रहा हूँ। यह सोचना भी दिलचस्प हो सकता है कि यह दस्तावेज़ किस prompt से बनाया गया होगा।
# Blog Service 다국어 번역 구조 도입 PRD
## 📋 개요
| 항목 | 내용 |
|------|------|
| **문서 ID** | PRD-2026-01-24-BLOG-MULTILANG |
| **작성일** | 2026-01-24 |
| **작성자** | Claude Code |
| **상태** | ✅ 완료 |
| **대상 서비스** | blog-service |
## 🎯 목표
Flashcard/FlashcardTranslation 패턴을 blog-service에 도입하여 Post, Category, Comment, Tag 엔티티의 다국어 지원을 구현한다.
## 📊 진행 현황
| # | Phase | 작업 항목 | 상태 | 완료일 |
|---|-------|----------|------|--------|
| 1 | Entity | PostTranslation.kt | ✅ 완료 | 2026-01-24 |
| 2 | Entity | CategoryTranslation.kt | ✅ 완료 | 2026-01-24 |
| 3 | Entity | CommentTranslation.kt | ✅ 완료 | 2026-01-24 |
| 4 | Entity | TagTranslation.kt | ✅ 완료 | 2026-01-24 |
| 5 | Repository | PostTranslationRepository.kt | ✅ 완료 | 2026-01-24 |
| 6 | Repository | CategoryTranslationRepository.kt | ✅ 완료 | 2026-01-24 |
| 7 | Repository | CommentTranslationRepository.kt | ✅ 완료 | 2026-01-24 |
| 8 | Repository | TagTranslationRepository.kt | ✅ 완료 | 2026-01-24 |
| 9 | DTO | PostDto.kt 수정 | ✅ 완료 | 2026-01-24 |
| 10 | DTO | CategoryDto.kt 수정 | ✅ 완료 | 2026-01-24 |
| 11 | DTO | CommentDto.kt 수정 | ✅ 완료 | 2026-01-24 |
| 12 | DTO | TagDto.kt 수정 | ✅ 완료 | 2026-01-24 |
| 13 | DTO | TranslationDto.kt 신규 | ✅ 완료 | 2026-01-24 |
| 14 | Service | PostService.kt 수정 | ✅ 완료 | 2026-01-24 |
| 15 | Service | CategoryService.kt 수정 | ✅ 완료 | 2026-01-24 |
| 16 | Service | CommentService.kt 수정 | ✅ 완료 | 2026-01-24 |
| 17 | Service | TagService.kt 수정 | ✅ 완료 | 2026-01-24 |
| 18 | Service | TranslationService.kt 신규 | ✅ 완료 | 2026-01-24 |
| 19 | Controller | PostController.kt 수정 | ✅ 완료 | 2026-01-24 |
| 20 | Controller | CategoryController.kt 수정 | ✅ 완료 | 2026-01-24 |
| 21 | Controller | CommentController.kt 수정 | ✅ 완료 | 2026-01-24 |
| 22 | Controller | TagController.kt 수정 | ✅ 완료 | 2026-01-24 |
| 23 | Controller | BoTranslationController.kt 신규 | ✅ 완료 | 2026-01-24 |
**진행률: 23/23 (100%) ✅ 완료**
---
## 🏗️ 기술 설계
### 1. 번역 대상 필드
| 엔티티 | 번역 필드 | 원본 길이 | 번역 길이 (2배) |
|--------|----------|----------|----------------|
| Post | title | 200 | 400 |
| Post | excerpt | TEXT | TEXT |
| Post | content | TEXT | TEXT |
| Category | name | 100 | 200 |
| Category | description | TEXT | TEXT |
| Comment | content | TEXT | TEXT |
| Tag | name | 50 | 100 |
### 2. 핵심 패턴 (Flashcard 검증 완료)
#### 2.1 Entity 패턴
```kotlin
@Entity
@Table(indexes = [...])
@IdClass(PostTranslationPk::class)
data class PostTranslation(
@Id @Column(updatable = false)
val postId: Long,
@Id @Column(length = 5, updatable = false)
val languageCode: String,
// 번역 필드들
var title: String,
var excerpt: String?,
var content: String
) : BaseTimeEntity()
data class PostTranslationPk(
val postId: Long? = null,
val languageCode: String? = null,
) : Serializable
```
#### 2.2 DTO 패턴
```kotlin
data class DetailResponse(
// 원본 필드
@get:JvmName("titleOriginal")
private val title: String,
// 번역 필드 (JSON 숨김)
@JsonIgnore
val translatedTitle: String? = null,
// 실제 응답 (번역 우선)
@JsonGetter("title")
fun getTitle(): String =
translatedTitle?.takeIf { it.isNotBlank() } ?: title
)
```
#### 2.3 Service JOIN 패턴
```kotlin
queryFactory
.select(PostDto.ListResponse.buildProjectionWithTranslation())
.from(post)
.leftJoin(postTranslation)
.on(postTranslation.postId.eq(post.id)
.and(postTranslation.languageCode.eq(lang)))
.fetch()
```
#### 2.4 Controller 패턴
```kotlin
@GetMapping("/posts")
fun findAll(
@RequestParam(required = false) lang: String?,
// ...
): JPage<PostDto.ListResponse>
```
### 3. 지원 언어 코드
---
## 📁 파일 경로
```
modules/blog-service/src/main/kotlin/com/jongmin/blog/
├── entity/
│ ├── PostTranslation.kt # 신규
│ ├── CategoryTranslation.kt # 신규
│ ├── CommentTranslation.kt # 신규
│ └── TagTranslation.kt # 신규
├── repository/
│ ├── PostTranslationRepository.kt # 신규
│ ├── CategoryTranslationRepository.kt # 신규
│ ├── CommentTranslationRepository.kt # 신규
│ └── TagTranslationRepository.kt # 신규
├── dto/
│ ├── PostDto.kt # 수정
│ ├── CategoryDto.kt # 수정
│ ├── CommentDto.kt # 수정
│ ├── TagDto.kt # 수정
│ └── TranslationDto.kt # 신규
├── service/
│ ├── PostService.kt # 수정
│ ├── CategoryService.kt # 수정
│ ├── CommentService.kt # 수정
│ ├── TagService.kt # 수정
│ └── TranslationService.kt # 신규
└── controller/
├── PostController.kt # 수정
├── CategoryController.kt # 수정
├── CommentController.kt # 수정
├── TagController.kt # 수정
└── BoTranslationController.kt # 신규
```
---
## 📝 작업 로그
### 2026-01-24
- **15:00** - PRD 문서 생성, 작업 계획 수립 완료
---
## 🔗 참조
- **레퍼런스 구현**: `legacy-service/catch_on/platform/entity/FlashcardTranslation.kt`
- **레퍼런스 서비스**: `legacy-service/catch_on/platform/service/SubjectService.kt`
- **레퍼런스 DTO**: `legacy-service/catch_on/platform/dto/response/FlashCardResponseDto.kt`