Menü
회의록, 고객 요청, 아이디어 메모 등을 읽어 PRD(제품 요구사항 정의서)를 생성합니다. 파일 경로를 인자로 전달하세요.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
지정 디렉터리의 문서를 심층 분석하여 지식을 추출하고, 기존 문서 갱신 + 신규 문서 생성으로 프로젝트 지식 베이스에 반영합니다.
기술 의사결정 기록 (Architecture Decision Record). 중요한 기술적 결정의 맥락, 대안, 근거를 구조화하여 기록합니다.
현재 디렉터리의 내용을 분석하여 어떤 목적의 폴더인지 파악
슬랙/메일/메신저로 받은 업무 요청 메시지를 분석하여 의도, 핵심 내용, 판단, 액션 플랜, 대응 가이드를 정리합니다.
비즈니스 규칙, 도메인 규칙, 상태 전이 규칙을 하나의 문서로 관리합니다. 변경 이력이 누적됩니다.
열린 질문, 문제 해결, 기술 의사결정, 아이디어 발산을 구조화합니다. 회의록이나 메모 파일 경로를 인자로 전달하거나 직접 질문하세요.
| name | prd |
| description | 회의록, 고객 요청, 아이디어 메모 등을 읽어 PRD(제품 요구사항 정의서)를 생성합니다. 파일 경로를 인자로 전달하세요. |
| when_to_use | PRD 써줘, 제품 요구사항 정의서, 기획 문서 작성. 개발자용 명세는 srs. |
| allowed-tools | Read, Write, Glob, Grep, Bash |
외부-가시 문서:
rules/external-doc.md10원칙 준수. PRD는 기획, 경영진, 고객 담당자, 개발팀 공통 참조 문서. 내부 경로 금지, Outside-in(사용자 가치에서 구현으로), What > How, 정량과 절대 표기.
거친 아이디어, 고객 요청, 회의록, 구두 메모를 이해관계자(기획팀, 경영진, 고객사) 합의 가능한 PRD로 구조화. 빠진 비즈니스 맥락(왜, 누가, 성공 기준)을 질문으로 채우고, 답변을 반영해 반복 업데이트.
핵심 원칙: PRD는 "왜 만드는지, 누가 어떻게 쓰는지, 성공했는지 어떻게 아는지"를 비개발자도 이해할 수 있게 정리. 기술 상세(데이터 타입, API 명세)는 PRD에 넣지 않음. SRS 영역.
톤: PM. 기술 용어와 비즈니스 언어 사이 통역.
| 질문 | 담당 | 이 스킬에서 |
|---|---|---|
| 개발자용 요구사항 명세 (데이터 타입, API, 흐름) | /srs | [FAIL] 다루지 않음 |
| 긴급 시연과 아이디어 검증용 PoC | /poc | [FAIL] 다루지 않음 |
| 제품 정의 (왜, 누가, 성공 기준), 비개발자 합의 문서 | 이 스킬 | [OK] 핵심 |
| 데이터 | 경로 | 필수/선택 | 부재 시 동작 |
|---|---|---|---|
| 프로젝트 컨텍스트 | CLAUDE.md | 선택 | 일반 가정으로 진행, [프로젝트 규칙 미확인] 태그 |
| 봇 인덱스 | bot/INDEX.md 또는 .local.claude/ONBOARDING.md | 선택 | 디렉터리 Glob 으로 fallback |
| 비즈니스 규칙 | .local.claude/biz-rules.md | 선택 | 일반 SW 관점으로만 진행 (Tier 1) |
| 모듈 상세 | .local.claude/modules/{name}.md | 선택 | 코드 Grep 직접 fallback |
| 고객 프로필 | .local.claude/customers/*.md | 선택 | B2B 맥락 부재, 일반 기능 요구사항 수준으로 |
| CS 이력 | .local.claude/cs/*.md | 선택 | 고객 요구 근거 부재, [고객 근거 없음] 태그 |
| 이전 PRD | .local.claude/prd/*.md | 선택 | 신규 PRD 기본 템플릿으로 시작 |
다음 파일이 존재하면 우선 read 하여 회사, 제품, 팀, 고객 정보를 파악:
CLAUDE.md (자동 로드, 회사, 제품, 기술 스택, 컨벤션)bot/INDEX.md 또는 .local.claude/INDEX.md (사실 카탈로그).local.claude/customers/*.md (고객사, 있을 시).local.claude/people/*.md 또는 팀원 매핑 파일위 파일이 없으면 사용자에게 비즈니스 컨텍스트 (회사, 제품, 사용자) 를 직접 입력 요청.
정적 knowledge file 대신 코드베이스의 문서를 직접 참조한다. 회의록에서 언급된 모듈/기능과 관련된 문서를 선택적으로 읽는다.
| 문서 | 경로 | 용도 |
|---|---|---|
| 프로젝트 전체 구조 | CLAUDE.md | 모듈 목록, 도메인 약어, 컨벤션 |
| 아키텍처 온보딩 | bot/INDEX.md 또는 .local.claude/ONBOARDING.md | 핵심 사용자 여정과 모듈 매핑, 이벤트 흐름도 |
| 모듈 상세 분석 | .local.claude/modules/{name}.md | 개별 모듈 서비스, 테이블, 연동 상세 |
| 고객사 프로필 | .local.claude/customers/{고객사}.md | 고객사 Pain Point, 과거 요청, 커스터마이징 현황. 고객 요청 PRD 시 필수 참조 |
| 기존 PRD/분석 | .local.claude/projects/*/PRD-*.md | 기존 PRD 스타일/형식 참조 |
참조 전략:
$ARGUMENTS로 받은 회의록/메모를 Read로 읽기ls .local.claude/projects/{project-name}/로 회의록, 브레인스토밍 등 기존 파일 읽기CLAUDE.md의 도메인 약어 및 모듈 목록 섹션modules/{name}.md 읽기projects/*/PRD-*.md 읽어 스타일 일관성 유지회의록 파일 경로가 제공된 경우 ($ARGUMENTS):
$ARGUMENTS 파일을 읽는다파일 경로가 없는 경우:
"회의록 파일 경로를 전달해주세요. 예: /prd path/to/meeting-notes.md
또는 여기에 직접 내용을 입력해주셔도 됩니다."
[1M 활용] 다음을 단일 메시지에서 병렬 호출:
- Read:
$ARGUMENTS입력 파일,CLAUDE.md, 관련 기존 PRD (.local.claude/projects/*/PRD-*.md,.local.claude/prd/*.md)- Glob:
.local.claude/modules/*.md,.local.claude/customers/*.md- Bash:
ls .local.claude/projects/{project-name}/(기존 회의록, 브레인스토밍 확인)
1) 문제 검증: 이 기능 요청의 본질이 뭔가?
2) 효용 검증: 도입할 만한 가치가 있나?
3) 접근 방식 검증: PRD가 맞나?
modules/*.md 검색.1)에서 "근본이 다른 곳"이면 근본 문제를 먼저 제시. 2)에서 빈도/효용이 불분명하면 측정/로깅을 먼저 제안. 3)에서 더 단순한 방법이 있으면 "이런 방법도 있는데요"를 먼저 제시. 그래도 PRD가 필요하면 진행.
(A) 범위: 하나의 기능/개선인지, 여러 개가 섞여 있는지.
(B) 유형: 신규 기능 / 기존 기능 개선 / 문제 해결(버그, 성능) 중 어디에 해당하는지.
(C) 입력 충분도: PRD 초안을 바로 생성할 수 있을 만큼 비즈니스 맥락이 충분한지. 충분의 기준은 아래 3가지 중 2개 이상 파악 가능:
충분도에 따른 분기:
PRD를 의미 있게 생성하기 위한 최소 비즈니스 맥락을 수집한다. 질문은 최대 4개, 아래 우선순위 순:
사용자가 답하면 2단계로 진행.
[메타인지] 초안 완성 후 자기 검증:
- 근거 재점검: 각 주장에 근거(출처, 측정, 인용)가 있는가? [미측정] 태그가 빠진 주장은 없는가?
- 전제 검증: 이 PRD가 유효하려면 어떤 전제가 필요한가? 전제가 실제로 성립하는가?
- 반대 증거: "이대로 전달 시 수신자(기획, 경영진, 고객)가 오해할 여지는?" 반박 1개 이상 생성 후 반영
## [기능명] PRD
### 1. 개요
| 항목 | 내용 |
|------|------|
| 기능명 | |
| 관련 모듈 | 프로젝트 모듈명 |
| 요청 출처 | 고객사명 / 내부 기획 / 현장 피드백 |
| 유형 | 신규 기능 / 기능 개선 / 문제 해결 |
| 우선순위 | 긴급/높음/중간/낮음 + 근거 |
| 상태 | 초안 / 검토 중 / 확정 |
### 2. 배경 & 문제 정의
현재 상태(AS-IS)와 원하는 상태(TO-BE) 대비.
비개발자가 읽어도 "아, 이게 필요하구나"라고 납득할 수 있는 수준으로 서술.
**현황 데이터** (있으면 설득력이 올라감):
| 항목 | 내용 |
|------|------|
| 현재 빈도/규모 | 이 문제가 얼마나 자주, 몇 명에게 발생하는가? |
| 측정 근거 | 로그, CS 접수 건수, 사용자 피드백 등 데이터 출처 |
| 기대 효과 | 도입 시 예상되는 개선 (정량적이면 최선, 정성적이라도 명시) |
데이터가 없으면 [미측정] 표시 + "측정을 위해 ~로깅이 선행되어야 함" 명시.
### 3. 사용자 & 이해관계자
| 사용자 유형 | 역할 | 이 기능과의 관계 |
직접 사용자, 간접 수혜자, 의사결정자를 구분.
### 4. 사용자 시나리오
"누가, 어떤 상황에서, 무엇을 하면, 어떤 결과를 얻는다" 형태.
기술 용어 없이. 주요 시나리오 1~3개.
### 5. 기능 요구사항
#### 5-1. 핵심 기능 (Must Have)
"시스템은 ~해야 한다" 형태. 번호 매겨 나열.
#### 5-2. 부가 기능 (Nice to Have)
첫 릴리스에서 빠져도 되는 기능. 없으면 생략.
### 6. 성공 기준 & 측정 방법
| 성공 기준 | 측정 방법 | 목표값 |
정량적 기준 지향. 어려우면 정성적이라도 명시.
### 7. 범위 & 제외 사항
#### 7-1. 이번 범위에 포함
#### 7-2. 이번 범위에서 제외 (명시적 제외)
#### 7-3. 향후 확장 가능성
### 8. 일정 & 마일스톤
| 마일스톤 | 예상 일정 | 산출물 |
대략적 일정. 정확한 공수 산정은 SRS 이후.
### 8-1. 스코프 조정 옵션 (일정/자원 제약 시)
전체 스코프를 기한 내에 달성하기 어려울 때, "불가"가 아닌 실행 가능한 대안을 제시.
| 옵션 | 포함 범위 | 제외 범위 | 예상 일정 | 트레이드오프 |
|------|----------|----------|----------|------------|
| Full | 전체 기능 | 없음 | N주 | 최선이지만 일정 리스크 |
| MVP | 핵심 기능(5-1)만 | 부가 기능(5-2) 전체 | N주 | 핵심 가치 전달 가능, 후속 Phase 필요 |
| Lite | 최소 기능 | 대부분 후순위 | N주 | 빠른 검증 가능, 기능 제한 큼 |
기능별 우선순위 판단 기준: 비즈니스 임팩트 × 구현 난이도 매트릭스.
### 9. 의존성 & 리스크
| 항목 | 유형 | 내용 | 대응 방안 |
### 10. 참고 자료
관련 미팅 기록, 유사 기능 벤치마크, 기존 분석 문서 링크 등.
1차 PRD 작성 후 빠진 비즈니스 맥락을 찾아 질문한다.
질문 우선순위 (상위일수록 먼저):
고객은 문제를 느끼지만 정확히 뭐가 문제인지 모르는 경우가 대부분이다. "이런 거 만들어주세요"라는 솔루션(How)으로 요청이 들어오면, 아래 질문으로 고객 자신도 모르는 진짜 필요를 끌어낸다.
1차 PRD에서 [미정의]인 항목이 있으면, 아래 카테고리에서 해당하는 질문을 갭 분석 질문에 포함한다. 전부 물어보는 게 아니라, PRD 완성에 필요한 것만 선별.
1) 맥락 (왜/왜 지금)
2) 사용자 (누가/어디서/언제)
3) 데이터 (무엇을/얼마나)
4) 기대 결과 (성공이면 어떤 모습)
5) 제약 (못 하는 것/하면 안 되는 것)
기능 개선/문제 해결 유형일 때 추가 질문:
질문 형식:
**PRD 보강: 답해주시면 기획 문서가 더 완성됩니다**
1. [질문 내용]
- 이유: [왜 이 정보가 PRD에 필요한지]
답해주시면 반영해서 업데이트합니다.
"이 정도면 됐어"라고 하시면 현재 버전으로 확정합니다.
PRD는 비개발자도 읽는 문서이므로, 복잡한 흐름을 직관적으로 전달해야 할 때만 mermaid 다이어그램을 포함한다.
| 조건 | 다이어그램 유형 | 배치 위치 |
|---|---|---|
| 사용자 시나리오가 분기/반복을 포함 | flowchart | 4. 사용자 시나리오 |
| 모듈 간 연동이 복잡한 기능 | flowchart | 2. 배경 & 문제 정의 또는 9. 의존성 |
| 상태 변화가 핵심인 기능 | stateDiagram-v2 | 5. 기능 요구사항 |
Frontmatter (CONTRACT 7-2절 표준): category: project-docs, retention: project-end
PRD가 확정되면 반드시 마크다운 파일로 저장한다.
$ARGUMENTS에 프로젝트명이 있으면 해당 프로젝트ls .local.claude/projects/로 기존 프로젝트 확인 후 관련 있으면 해당 프로젝트.local.claude/projects/{project-name}/PRD-{기능명}.md.local.claude/prd/YYYY-MM-DD-{기능명}.mdmkdir -p로 생성최종본 확정 후 안내:
/srs {저장된 파일 경로}/poc {저장된 파일 경로}rules/external-doc.md (가독성 5 + 정직성 5). PRD는 기획, 경영진, 고객 담당자 등 외부 독자가 읽음.사용자: "{고객사}에서 마감 3일 전 5일 전에도 알림 보내달라고 했어. 지금은 당일에만 가거든."
바로 2단계(PRD 초안 생성) 진행. 관련 모듈(modules/{모듈명}.md)을 읽어 기존 알림 기능을 파악하고, PRD 초안에 반영.
사용자: "{모듈명}에 바코드 스캔 개선해야 할 것 같아"
1-1단계(사전 질문) 진행:
방향은 보이지만, PRD를 의미 있게 작성하려면 비즈니스 맥락이 좀 더 필요합니다.
**PRD 작성 전 확인 사항**
1. **현재 바코드 스캔에 어떤 문제가 있나요?** (예: 스캔 속도가 느리다, 인식률이 낮다)
- 이유: "개선"의 방향이 완전히 달라집니다.
2. **이 요청이 나온 배경이 있나요?** (고객사 불만? 현장 작업자 피드백?)
- 이유: 문제의 심각도와 우선순위 판단에 필요합니다.
3. **어떤 상황/맥락에서 쓰이는 건가요?** (예: 어떤 사용자, 어떤 업무 흐름, 어떤 빈도)
- 이유: 맥락에 따라 시나리오가 달라집니다.
답해주시면 바로 PRD 초안을 작성합니다.
공통 3블록(빈 / 부분 / 풀 데이터)은 CONTRACT 6-1절 참조.
[사용자 개입 필요] 비즈니스 임팩트 정보(매출, ROI, 사용자 수) 부재
[데이터 결함] 기존 PRD/SRS와 기능 요구사항이 상충
.local.claude/prd/*.md 또는 projects/*/SRS-*.md 의 기존 요구사항과 현재 요청이 모순[요구사항 충돌] 태그 + 양쪽 기술 + 사용자에게 어느 쪽을 기준으로 할지 확인