# Prd Write

> PRD(제품 요구사항 문서) 작성 스킬. JTBD·유저스토리 기반 15섹션 구조로 사람 팀과 AI 프로토타이핑 툴(Cursor/v0/Lovable/bolt.new) 양쪽이 바로 쓸 수 있는 PRD를 만들고, 산문 섹션은 번역투·AI 관용구를 걷어낸 자연스러운 한글로 자체 윤문한다. "PRD 작성해줘", "요구사항 문서 만들어줘", "기획서 써줘", "/prd" 같은 요청에 사용.

- Skill: `shwsgithub/prd-write` (Agent Skill)
- Install (CLI): `npx skillmds@latest add shwsgithub/prd-write`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shwsgithub/prd-write/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: SHWsgithub (https://skillmd.com/u/shwsgithub)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/shwsgithub/prd-write

---


# PRD 작성 스킬

디자이너 관점에서 사용자 경험·인터랙션·엣지케이스를 우선하되, 모든 섹션은 AI 코딩 툴이 추가 질문 없이 빌드 브리프로 쓸 수 있을 만큼 구체적으로 쓴다. 표·타입 정의·API 스펙 같은 구조화된 부분은 영어 용어를 그대로 쓰고, 설명 산문은 아래 §3 문체 원칙에 따라 자연스러운 한글로 쓴다.

## 0. 시작 질문

한 번에 하나씩, 대화하듯 묻는다:
1. 어떤 문제를 해결하나요? 누가 가장 영향을 받나요?
2. 주 사용자와 부 사용자는 누구인가요?
3. 선호하는 기술 스택이 있나요? 없으면 문제 유형에 맞춰 제안한다.
4. 하드 제약이 있나요? (플랫폼, 인증 체계, 오프라인 지원, 접근성 수준)

인자로 기능/프로젝트명이 주어졌으면 질문을 건너뛰고 그 이름을 작업 타이틀로 쓴다.

## 1. PRD 구조 (15섹션)

섹션은 필요한 만큼만 채운다 — 해당 없으면 패딩하지 말고 통째로 생략한다.

**1. 개요** — 문제 정의(2~4문장) · 제안 솔루션(1~2문장) · **AI Build Summary**(명령형으로 "무엇을·어떤 스택으로·가장 힘든 제약은 무엇인지"를 압축한 한 문단, AI 프로토타이핑 툴이 제일 먼저 읽는 부분)

**2. 목표 & 성공 지표** — 핵심 목표 1개, 측정 가능한 지표 1~3개, **안티골 목록**(성공에 포함되지 않는 것 — 스코프 관리에 필수)

**3. 스코프 & 제약** — 포함/제외 범위, 플랫폼·인증·접근성 등급(WCAG AA/AAA)·오프라인 지원 여부·성능 요구·데이터 규제 요건

**4. JTBD (Jobs to Be Done)** — "[상황]일 때, [동기]하고 싶다, 그래서 [기대 결과]를 얻는다" 형식. 빈도·중요도 순 2~5개.

| 우선순위 | Job Statement |
|---|---|
| 1 | ... |

**5. 유저 스토리** — 각 스토리는 §4 Job과 §13 수용 기준에 교차 참조된다.

| ID | 역할 | 액션 | 효익 | JTBD Ref |
|---|---|---|---|---|
| US1 | | | | J1 |

**6. 경험 설계** — 인터랙션 모델·화면/상태 목록(빈 상태·에러 상태·로딩 상태 포함)·접근성 노트(키보드 탐색·스크린리더·색 대비)

**7. 컴포넌트 인벤토리** — v0/Lovable 같은 컴포넌트 단위 AI 툴이 바로 쓸 수 있는 평면 목록

| 컴포넌트 | 타입 | 설명 | 관련 스토리 |
|---|---|---|---|

**8. 데이터 모델** — TypeScript interface로 정의 (스택이 TS가 아니면 JSON Schema나 평문 필드 설명)

**9. API / 연동 스펙** — 엔드포인트 표 또는 BaaS 테이블 오퍼레이션

| Method | Path | 설명 | 인증 필요 | 응답 형태 |
|---|---|---|---|---|

**10. 상태 관리 맵** — 어떤 상태가 어디(서버/로컬/URL/인증 컨텍스트/캐시)에 있고 왜인지

**11. 기술 스택 추천** — 사용자 선호가 없으면 문제 유형 기반 기본안 제시, 레이어별 선택 이유 명시

**12. 파일 구조** — 기능 코드용 ASCII 디렉토리 트리, 변경 없는 파일은 생략

**13. 수용 기준** — 유저 스토리 1개당 체크리스트 1묶음. 이진 판정 가능하게("정상 동작" 금지, "인증 상태에서 HTTP 200과 아이템 목록 반환" 같이 구체적으로)

**14. 미해결 질문 & 리스크** — 질문(오너 명시) · 리스크(완화책 명시) · 트레이드오프

**15. 롤아웃 & 다음 단계** — MVP 스코프(포함/제외) · Phase 2+ 아이디어 · 승인 필요 대상 · 액션 아이템(오너·기한)

## 2. 작성 원칙

- 디자이너 관점: 어포던스·멘탈 모델·정보 위계를 먼저 생각하고, PM/엔지니어링이 이해할 언어로 번역한다
- 모든 결정에 "왜"를 함께 쓴다
- 접근성·에러 상태·빈 상태·오프라인 동작처럼 사용자가 놓치기 쉬운 것을 먼저 제안한다
- 산문보다 불릿, 장황함보다 간결함
- 생성 후 어느 섹션이든 더 깊이 파고들거나 스코프를 조정할 수 있다고 안내한다

## 3. 문체 원칙 — 자연스러운 한글

산문 섹션(§1 문제 정의·제안 솔루션, §6 경험 설계, §14 미해결 질문, §15 롤아웃 설명 등 자유 서술 구간)에만 적용한다. 표·타입 정의·API 스펙·ASCII 트리는 대상이 아니다.

**4대 철칙**
1. **의미 불변** — 수치·고유명사·기술 용어·직접 인용은 100% 그대로 둔다
2. **근거 기반 수정** — 아래 체크리스트에 실제로 걸리는 표현만 손댄다. 걸리지 않은 문장은 건드리지 않는다
3. **장르 유지** — PRD는 실무 문서다. 에세이·마케팅 카피·블로그 톤으로 옮기지 않는다
4. **과윤문 금지** — 산문 섹션에서 손댄 문장 비율이 체감상 30%를 넘으면 "이 정도까지 수정했습니다"라고 사용자에게 알린다. 50%를 넘길 정도면 원래 표현이 대부분 자연스러웠다는 뜻이니 되돌아본다

**체크리스트** (걸리는 것만 수술적으로 고친다)

| 카테고리 | 예시 | 처방 |
|---|---|---|
| 번역투 | "~를 통해 ~할 수 있다", "~에 대해", "~에 있어서", "~에 의해 생성된다" | 능동태·간결형으로: "~로 ~한다", "~가 만든다" |
| 구조적 AI 패턴 | 기계적 "첫째/둘째/셋째" 나열, 불릿·이모지·볼드 과다 | 자연스러운 접속 또는 표로 대체 |
| AI 특유 관용구 | "결론적으로", "시사하는 바가 크다", "주목할 만하다", "혁신적인" | 삭제하거나 구체적 진술로 교체 |
| 수식·중복 | "매우", "정말", 동의어 이중 수식("완전히 전면적으로") | 하나만 남기거나 삭제 |
| 접속사 남발 | 문두 "또한/따라서/즉/나아가" 연속 사용 | 문장 합치기 또는 접속사 제거 |
| 형식명사 과다 | "~것이다", "~할 필요가 있다", "~하는 점" 남용 | 서술어로 직접 교체 |

## 4. 생성 흐름

1. §0 질문으로 컨텍스트 수집
2. §1 구조로 전체 초안 작성 (해당 없는 섹션은 생략)
3. 산문 섹션만 §3 체크리스트로 자체 검수, 걸린 표현만 수정
4. 최종본 제시
5. 놓쳤을 수 있는 것 제안: 접근성·에러 상태·빈 상태·오프라인 동작
6. 섹션 드릴다운이나 스코프 조정 의향 확인