--- name: prd-writer description: 사용자가 PRD, 제품 요구사항 문서, 기술 제품 기획서 또는 제품·기능 구현을 요청했을 때 작성하거나 다듬습니다. 요구사항 조사 결과를 제품 범위와 수용 기준으로 정리해 제시하고, 별도 사용자 메시지에서 기술 스펙 작성 승인을 기다립니다. --- # PRD 작성기 ## 출력 언어 사용자가 출력 언어를 명시적으로 지정하면 해당 언어를 사용합니다. 지정하지 않으면 이 스킬이 만드는 모든 사용자 대상 출력, 문서, 프롬프트, 보고서, 계획, 스펙 및 기타 산출물을 한국어로 작성합니다. 제목, 섹션, 레이블, 표, 체크리스트, 다이어그램, 템플릿에도 같은 언어를 사용합니다. 코드, 명령어, 파일 경로, 식별자, API 이름, 모델 ID, 프로토콜 이름과 필수 고유명사는 번역하지 않습니다. ## 작성 문서 첨부 요청된 모든 문서의 작성 또는 갱신을 마친 뒤 최종 응답에 각 문서를 `[문서 이름](절대 경로)` 형식의 Markdown 링크로 반드시 첨부합니다. 링크에는 독립된 디렉터리 세그먼트로 구성된 절대 경로를 사용하고, 디렉터리 구분자를 생략하거나 경로 세그먼트를 붙여 쓰지 않습니다. Windows 경로를 문자열로 표시할 때는 `C:\\Users\\WinUser\\Documents\\폴더\\문서.md`처럼 각 역슬래시를 두 번 씁니다. ## 목적 거친 아이디어를 구현자가 판단 가능한 PRD로 정리한다. 기본 출력은 "제품 판단 + 기능 요구사항 + 수용 기준 + 기술 아키텍처 + 리스크"가 한 문서에 들어간 기술 PRD다. ## 사용 원칙 - PRD는 구현 계획서가 아니라 제품과 범위의 결정 문서다. - "무엇을 만들지"와 "무엇을 만들지 않을지"를 같은 비중으로 쓴다. - MVP는 작게 잡고, 확장은 `v0.1`, `v0.2`, `v0.3`처럼 버전별로 분리한다. - 모든 기능 요구사항은 `FR-001` 형식의 ID와 수용 기준을 가진다. - 기술 제품 PRD에는 API 예시, 메시지 schema, 에러 모델, 보안 정책, repo/package 구조를 포함할 수 있다. - 불확실한 결정은 관련 섹션 안에 "미해결 문제" 블록으로 붙인다. - 문서 끝의 미해결 문제 섹션은 전체 복사본이 아니라 섹션별 인덱스와 우선순위 요약으로만 쓴다. - PRD는 기술 스펙의 입력 문서이며 구현 계약으로 사용하지 않는다. - 확인된 요구사항, 추정, 열린 질문, 사용자 결정 필요 항목과 제외 사항을 분리한다. - 기술 스펙 작성을 막는 열린 질문은 PRD 안에만 기록하지 않고, PRD 링크와 함께 사용자 대화에도 먼저 제시한다. - 플랫폼 지원, 정책, 사용자군, 법적 요구사항, 지표 또는 연동 대상을 근거 없이 만들지 않는다. - 가장 작은 실행 가능 범위를 제시하고 범위 밖 항목을 명시한다. - 기능, UX, 신뢰성, 개인정보 보호, 보안, 접근성, 분석 요구사항을 관련 있는 경우 구분한다. - PRD를 제시한 뒤 현재 턴을 끝낸다. 이후 별도 사용자 메시지에서 PRD 경로 또는 버전을 확인하며 기술 스펙 작성을 승인한 경우에만 `technical-spec-writer`에 전달한다. - 최초 요청의 `PRD 작성 후 스펙 작성` 또는 `문서 작성 후 구현` 같은 미래형 의사는 다음 단계 승인으로 인정하지 않는다. ## 작성 흐름 1. 요청을 요약하고 PRD 종류를 정한다. - 일반 제품 PRD - 기술 제품 PRD - 런타임/SDK/CLI/프레임워크 PRD - 기존 초안 정리/확장 - 기존 작업 문서와 관련 제품 맥락을 읽고 판단에 영향을 주는 사실을 조사한다. 2. 핵심 제품 판단을 먼저 고정한다. - 왜 필요한가 - 기존 대안은 왜 부족한가 - 무엇을 중심축으로 삼는가 - v0.1에서 어디까지 할 것인가 3. 범위를 버전별로 나눈다. - `v0.1`: 실제로 동작하는 최소 제품 - `v0.2`: 개발자 경험과 기본 생산성 - `v0.3`: 확장성, 최적화, 고급 기능 4. 기능 요구사항을 `FR-001`부터 작성한다. 5. 비기능 요구사항, 보안, 에러 모델, 리스크를 정리하면서 각 섹션의 미해결 문제를 그 자리에서 함께 기록한다. 6. 마지막에는 의사결정 표, 릴리즈 수용 기준, 섹션별 미해결 문제 인덱스를 둔다. 7. PRD 경로와 상태를 제시합니다. 기술 스펙 작성을 막는 열린 질문이 있으면 질문 전문·선택지·권장안·영향과 답변 방법을 함께 제시하고 현재 턴을 끝냅니다. 8. 별도 사용자 메시지에서 PRD 승인과 열린 질문의 답변을 확인합니다. 사용자가 먼저 승인했지만 질문을 아직 대화에 제시하지 않았다면 승인 상태는 보존하고 질문을 먼저 제시합니다. 9. 사용자의 직접 선택 또는 권장안 일괄 승인을 PRD에 반영한 뒤에만 `technical-spec-writer`에 전달합니다. ## 출력 위치 - 사용자가 파일 작성을 요청하면 `.codex/temp/-prd.md`에 저장한다. 사용자가 다른 위치를 명시하면 그 위치를 따른다. - 사용자가 채팅 답변만 원하면 파일을 만들지 않고 본문만 출력한다. ## 작성 원칙 참조 PRD 본문은 `cognitive-writing` 스킬의 원칙(인지 부하 최소화, GitHub-flavored Markdown 규칙)을 따라 작성한다. ## 기술 스펙 전 열린 질문 게이트 다음 단계를 막는 열린 질문이 하나라도 있으면 PRD를 첨부하는 최종 응답에 아래 정보를 포함합니다. 1. PRD 절대 경로 링크와 문서 버전 또는 상태 2. `Q1`, `Q2`처럼 식별 가능한 질문 전문 3. 각 질문의 선택지, 현재 권장안과 선택에 따른 영향 4. 다음 두 답변 방법 - `권장안대로 승인`: 방금 대화에 제시된 모든 권장안을 선택하고 PRD를 승인 - `Q1: ..., Q2: ...`: 질문별로 직접 선택하고 그 내용으로 PRD를 갱신 사용자가 질문을 보지 못한 채 `승인`만 보낼 수 있으므로 다음 규칙을 지킵니다. - `승인`만으로 열린 질문의 답을 추정하지 않습니다. - 승인 메시지를 받은 시점에 미제시 또는 미응답 질문을 발견하면 PRD 링크와 질문 전체를 다시 제시하고 그 턴에서 멈춥니다. - 사용자가 이미 한 PRD 승인은 유지합니다. 질문 답변을 받은 뒤 별도의 PRD 재승인을 반복해서 요구하지 않습니다. - `권장안대로 승인`은 질문을 대화에 제시한 뒤 받은 답일 때만 유효합니다. 문서 안에만 있던 권장안에 대한 사전 포괄 승인은 인정하지 않습니다. - 질문별 직접 답변을 받으면 결정과 영향을 PRD의 관련 섹션 및 의사결정 표에 반영하고 버전 또는 상태를 갱신합니다. - 다음 단계를 막는 열린 질문이 없으면 `기술 스펙 전 필수 열린 질문: 없음`이라고 명시합니다. ## 기본 문서 구조 기술 제품 PRD는 아래 구조를 기본값으로 사용한다. 해당 없는 섹션은 줄이되, 비목표, 수용 기준, 리스크, 섹션별 미해결 문제는 가능하면 유지한다. ```md # PRD: <제품명> **문서 상태:** Draft **작성일:** YYYY-MM-DD **제품명:** <가칭 또는 확정명> **대상 플랫폼:** <플랫폼> **핵심 방향:** <한 줄 방향성> --- ## 1. 제품 요약 ## 2. 배경과 문제 정의 ## 3. 제품 목표 ### 3.1 핵심 목표 ### 3.2 제품 철학 ## 4. 비목표 ## 5. 타깃 사용자 ## 6. 핵심 사용 시나리오 ## 7. 제품 범위 ### 7.1 v0.1 MVP 범위 ### 7.2 v0.2 범위 ### 7.3 v0.3 범위 ## 8. 기능 요구사항 ## 9. 비기능 요구사항 ## 10. 기술 아키텍처 ## 11. CLI 요구사항 ## 12. 설정 파일 ## 13. 에러 모델 ## 14. 보안 정책 ## 15. 개발자 경험 ## 16. 성공 지표 ## 17. 릴리즈 계획 ## 18. 주요 리스크 ## 19. 섹션별 미해결 문제 인덱스 ## 20. 의사결정 ## 21. 상세 수용 기준 ## 22. 예시 API ## 23. 최종 요약 ## 24. 의존성과 제약 ## 25. 출시 및 측정 계획 ## 26. 참고 자료 ``` ## 섹션 작성 규칙 ### 섹션별 미해결 문제 미해결 문제는 가장 관련 있는 섹션 안에 둔다. 독자가 문제를 이해하기 위해 앞 섹션의 내용을 기억한 채 문서 끝으로 이동하게 만들지 않는다. 권장 블록: ```md #### 미해결 문제 - **문제**: 아직 결정되지 않은 내용 - **영향**: 이 결정이 늦어질 때 막히는 범위 - **후보**: 선택지 A / 선택지 B - **결정 필요 시점**: v0.1 설계 전 / 구현 전 / 릴리즈 전 ``` 규칙: - 해당 섹션과 직접 관련된 문제만 둔다. - 문제가 1개뿐이면 짧은 bullet 하나로 줄인다. - 문서 끝에는 상세를 반복하지 않고 섹션 링크, 우선순위, 결정 필요 시점만 요약한다. - 전역 의사결정처럼 여러 섹션을 막는 문제만 마지막 인덱스에 별도 항목으로 둔다. ### 제품 요약 3~5문단으로 쓴다. - 이 제품이 무엇인지 - 기존 대안과 무엇이 다른지 - 가장 중요한 설계 판단이 무엇인지 - MVP에서 해결할 문제가 무엇인지 핵심 판단은 인용문으로 한 번 고정해도 된다. ```md > 앱 프레임워크를 만들지 말고, Rust와 WebView를 안정적으로 연결하는 모바일 런타임을 만든다. ``` ### 배경과 문제 정의 대안별 한계를 명확히 쓴다. 비판은 감정이 아니라 제품 요구사항 관점으로 쓴다. 예시 분류: - Tauri Mobile의 문제 - Expo/React Native의 문제 - Capacitor의 문제 - 직접 구현이 필요한 이유 ### 제품 목표 핵심 목표는 번호 목록으로 쓴다. 제품 철학은 짧은 bullet로 쓴다. 좋은 목표: - Rust core를 모바일 앱의 1급 실행 엔진으로 사용 - WebView UI에서 Rust command를 안전하게 호출 - iOS/Android 공통 IPC 프로토콜 제공 나쁜 목표: - 좋은 UX 제공 - 안정적으로 만들기 - 여러 기능 지원 ### 비목표 v0.x에서 하지 않을 것을 명시한다. 비목표는 범위 팽창을 막는 장치다. 예시: - Tauri 전체 기능 복제 - Expo/EAS 대체 - 대형 플러그인 마켓플레이스 구축 - 모든 네이티브 API 추상화 ### 타깃 사용자 1차, 2차, 3차 사용자로 나누고 각 사용자마다 다음을 쓴다. - 누구인가 - 원하는 것 - 이 제품을 쓰는 이유 ### 핵심 사용 시나리오 각 시나리오는 아래 형식을 따른다. ````md ### 시나리오 N: <이름> 상황 설명. ```ts // API 또는 명령어 예시 ``` 요구사항: - ... 성공 기준: - ... ```` ### 제품 범위 버전별로 포함/제외를 분리한다. - `v0.1`: end-to-end로 실제 앱 하나를 만들 수 있는 최소 런타임 - `v0.2`: 이벤트, 권한, 파일, typed binding, doctor 같은 생산성 기능 - `v0.3`: streaming, cancellation, binary payload, plugin boundary 같은 확장 기능 ### 기능 요구사항 모든 기능 요구사항은 이 형식을 따른다. ```md ### FR-001: <기능명> 제품은 <대상>에서 <동작>을 제공해야 한다. 요구사항: - ... 수용 기준: - ... ``` 수용 기준은 테스트 가능한 문장으로 쓴다. 좋은 수용 기준: - JS에서 `invoke()`를 호출하면 Rust command가 실행된다. - unknown command 호출 시 `COMMAND_NOT_FOUND` 에러를 반환한다. - WebView reload 후 bridge가 재초기화된다. 나쁜 수용 기준: - 잘 동작한다. - 안정적이다. - 사용하기 쉽다. ### 비기능 요구사항 필요한 항목만 사용한다. - 성능 - 안정성 - 보안 - 유지보수성 - 디버깅성 - 이식성 정량 목표가 있으면 표로 쓴다. 수치는 초기 가정임을 명시한다. ### 기술 아키텍처 기술 제품에는 텍스트 다이어그램을 포함한다. ```txt Web UI ↓ TypeScript SDK ↓ Injected WebView Bridge ↓ Swift/Kotlin Native Shell ↓ Rust FFI / JNI ↓ Rust Runtime ↓ Command Registry ``` 필요하면 repository 구조, package/crate 역할, native boundary를 추가한다. ### 에러 모델 IPC, SDK, CLI처럼 호출 계약이 있는 제품은 structured error를 정의한다. ```ts type ProductError = { code: string message: string data?: unknown } ``` 기본 error code는 표로 정리한다. ### 보안 정책 WebView, IPC, native bridge, plugin, remote URL이 있으면 별도 섹션을 둔다. 필수 검토 항목: - origin allowlist - navigation 제한 - command allowlist - release 모드 remote URL 차단 - IPC schema validation - file URL 접근 제한 - dev/release 보안 차이 ### 리스크 각 리스크는 문제와 대응을 분리한다. ```md ### 18.1 <리스크명> 문제: - ... 대응: - ... ``` ### 섹션별 미해결 문제 인덱스 문서 끝의 인덱스는 상세 목록이 아니라 리뷰 순서를 잡기 위한 요약이다. 상세 내용은 관련 섹션 안의 `미해결 문제` 블록에 둔다. 예시: | 섹션 | 우선순위 | 미해결 문제 | 결정 필요 시점 | |---|---|---|---| | `7.1 v0.1 MVP 범위` | 높음 | CLI를 v0.1에 포함할지 결정 필요 | 구현 전 | | `14. 보안 정책` | 높음 | release remote URL 허용 예외 정책 필요 | 릴리즈 전 | 이 섹션은 미해결 문제가 3개 이하이면 생략해도 된다. ### 의사결정 현재 기준 권장 결정을 표로 정리한다. ```md | 항목 | 결정 | |---|---| | UI 런타임 | WebView | | 핵심 로직 | Rust | | IPC v0.1 | JSON request/response | ``` ### 상세 수용 기준 릴리즈 단위 체크리스트로 작성한다. 플랫폼이 있으면 플랫폼별로 나눈다. 예시: - iOS - Android - Rust - JS SDK - CLI ### 의존성과 제약 - 외부 시스템, 정책, 플랫폼, 조직 또는 일정 의존성을 구분한다. - 확인된 제약과 아직 검증하지 않은 가정을 분리한다. - 제약이 범위, 위험 또는 수용 기준에 미치는 영향을 적는다. ### 출시 및 측정 계획 - 단계적 출시, rollback 또는 중단 조건이 필요하면 명시한다. - 성공 지표에는 가능한 경우 baseline, 목표값, 담당자와 측정 기간을 적는다. 알 수 없으면 열린 질문으로 남긴다. ### 참고 자료 - 제품 판단에 영향을 준 공식 문서, 조사 자료 또는 저장소 근거를 연결한다. - 근거가 없는 일정이나 결과를 약속하지 않는다. ## 품질 체크리스트 출력 전 아래를 확인한다. - [ ] 첫 화면에서 제품의 핵심 판단이 보이는가 - [ ] 기존 대안의 한계가 제품 요구사항과 연결되는가 - [ ] 비목표가 범위 팽창을 막을 만큼 구체적인가 - [ ] `v0.1`이 실제로 만들 수 있을 만큼 작게 잘렸는가 - [ ] 모든 `FR-*`에 수용 기준이 있는가 - [ ] API, schema, CLI, config 예시가 계약을 설명하는 데 필요한 만큼만 들어갔는가 - [ ] 보안/에러/lifecycle 같은 실패 지점이 빠지지 않았는가 - [ ] 미해결 문제가 관련 섹션 안에 있고 마지막에는 인덱스만 있는가 - [ ] 최종 요약이 MVP 범위를 다시 압축해서 보여주는가 - [ ] 각 요구사항이 actor, trigger, 기대 동작, 경계와 실패 동작을 식별하는가 - [ ] 의존성과 제약이 범위 및 수용 기준에 연결되는가 - [ ] 성공 지표가 측정 가능하거나 열린 질문으로 명시됐는가 - [ ] 기술 스펙 작성을 막는 열린 질문을 PRD 링크와 함께 대화에 제시했는가 - [ ] 열린 질문이 없으면 없다고 명시했는가 - [ ] 일반 `승인`을 권장안 선택으로 처리하지 않았는가