[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CHJ29RN6Z71Y90ZKZCXG8V":3,"skill-same:01M6CHJ29RN6Z71Y90ZKZCXG8V":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":57,"repositoryHtmlUrl":61,"repositoryHomepageUrl":6,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":63,"install":64,"resources":76},"01M6CHJ29RN6Z71Y90ZKZCXG8V","prd",null,"PRD 작성 — 단일 양식(목표 → 결정 필요 항목 → 범위[포함·비포함·인수 조건] → 구현 방법[후보·채택안·선택 근거] → 리스크와 보완책[구현 부작용 포함] → 검증 → 결과, 번호 고정). PRD 는 문서 한 장이 아니라 의사결정 · 구현 설계 · 결과를 담은 **제품 맥락 집합**이며 LLM wiki 의 토대다(맥락 원칙 K1–K5 — 안정 ID · 결정 보존 · 근거 연결 · 결과는 사실 · 고정 메타). 요구사항 3대 유형(개발·콘텐츠·리포트), 작성 10규칙(R1 버전계층 목표상속 · R2 범위=포함+비포함+인수 조건 · R3 지시 전사+결정 필요 표시 · R4 As-Is\u002FTo-Be 개념+형태 · R5 작업 체크리스트 리뷰 · R6 AI 제품 분기[허용 답변 범위·Eval Plan] · R7 완성도 척도 · R8 인수 조건 Given-When-Then · R9 구현 방법 = 담당 에이전트가 전문가 관점에서 후보를 비교해 채택 · R10 리스크 = 외부 위험 + 채택안의 부작용). 프레임워크 체인·서브워크플로 출력을 입력으로 받아 PRD 생성. 사용 시점 — PRD·기획서·요구사항 문서를 새로 쓰거나 고칠 때, 릴리스 버전의 계획을 문서로 확정할 때, 검증 후 결과를 기록할 때.","Adelie-Squad\u002Fsolosquad","Adelie-Squad","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F269218606?v=4","01M6CHETAA89FK6KREADPVEF4T","SaPN","01M6CHETE7QEKZW6FK52137ZBP",25,"MIT","https:\u002F\u002Fgithub.com\u002FAdelie-Squad\u002Fsolosquad\u002Fblob\u002Fmain\u002Fskills\u002Fprd\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"as","when","eval plan","r2","manager","id","llm wiki","false","wiki","true","doc","design","eval","chief","planning","product","design doc","leader","plan","2026-11-10 10:12:30",false,"---\nname: prd\ndescription: PRD 작성 — 단일 양식(목표 → 결정 필요 항목 → 범위[포함·비포함·인수 조건] → 구현 방법[후보·채택안·선택 근거] → 리스크와 보완책[구현 부작용 포함] → 검증 → 결과, 번호 고정). PRD 는 문서 한 장이 아니라 의사결정 · 구현 설계 · 결과를 담은 **제품 맥락 집합**이며 LLM wiki 의 토대다(맥락 원칙 K1–K5 — 안정 ID · 결정 보존 · 근거 연결 · 결과는 사실 · 고정 메타). 요구사항 3대 유형(개발·콘텐츠·리포트), 작성 10규칙(R1 버전계층 목표상속 · R2 범위=포함+비포함+인수 조건 · R3 지시 전사+결정 필요 표시 · R4 As-Is\u002FTo-Be 개념+형태 · R5 작업 체크리스트 리뷰 · R6 AI 제품 분기[허용 답변 범위·Eval Plan] · R7 완성도 척도 · R8 인수 조건 Given-When-Then · R9 구현 방법 = 담당 에이전트가 전문가 관점에서 후보를 비교해 채택 · R10 리스크 = 외부 위험 + 채택안의 부작용). 프레임워크 체인·서브워크플로 출력을 입력으로 받아 PRD 생성. 사용 시점 — PRD·기획서·요구사항 문서를 새로 쓰거나 고칠 때, 릴리스 버전의 계획을 문서로 확정할 때, 검증 후 결과를 기록할 때.\nschema_version: 2\ntier: leader\nteam: _skill\ncategory: planning\nused_by: [\"product-manager\", \"chief\"]\ndev_capability: false\ntriggers:\n  keyword:\n    - \"prd\"\n    - \"요구사항 문서\"\n    - \"design doc\"\n    - \"기획서\"\npm_conventions:\n  anti_sycophancy: true\n  hard_gate: true\n  post_labeling: false\n  minimum_approaches: 2\n---\n\n# PRD Writer Skill\n\n## PRD 의 역할 — 제품 맥락 집합\n\nPRD 는 착수 전에 한 번 쓰고 버리는 기획서가 아니다. **이 버전에서 무엇을 왜 하기로 했고(결정), 어떻게\n만들기로 했고(구현 설계 — 기각한 후보 포함), 실제로 어떻게 됐는가(결과)** 를 한 곳에 남기는 제품 맥락\n집합이다. 버전마다 쌓인 PRD 가 이후 **LLM wiki 의 기본 토대**가 된다 — 에이전트가 \"왜 이렇게 돼 있지?\"를\n물었을 때 코드 대신 PRD 에서 답을 찾을 수 있어야 한다. 그래서 양식은 하나로 통일하고, 섹션 순서 · 번호 ·\nID 규칙을 고정한다(맥락 원칙 K1–K5).\n\n양식은 **하나**다 — 제품 기능 · 내부 개발 · 콘텐츠 · 리포트 모두 같은 양식을 쓰고, 해당하지 않는 하위 절만\n비운다. 저장소마다 다른 규칙(버전 체계 · 파일 위치 · 핫픽스 양식 · 배포 게이트)은 그 저장소의\narchitecture 문서가 정하고, 이 스킬은 그 규칙을 따른다.\n\n## 양식 (섹션 순서 · 번호 고정)\n\n```markdown\n# vX.Y.Z — \u003C제목>\n> **상태:** 초안 \u002F 검토 \u002F 진행 \u002F frozen (YYYY-MM-DD, revN) · **완성도(R7):** NN\u002F100\n> **요구사항 유형(R6):** [개발] \u002F [콘텐츠] \u002F [리포트] — LLM·에이전트가 들어가면 \"AI 제품\" 표기 → §6 AI 부록\n> **정본 · 선행:** 상위 PRD · 선행 PRD · 결정 문서 링크\n> **대체:** (있을 때만) 이 PRD 가 대체한 문서 \u002F 이 PRD 를 대체한 문서\n\n## 1. 목표\n- (R1) 상위 목표 인용 · 이 버전의 목표 · 이 버전이 그 안에서 맡는 조각 — 각 1줄\n- 이 버전이 끝나면 무엇이 가능해지나 — 한 문장\n- (제품 기능일 때) 배경(사용자 needs · JTBD · 기존 시도와 한계) · 대상(주 segment · 명시적 제외) ·\n  가치 문장(누가 · 왜 · 어떻게 · 어떤 가치) · 가설과 가정(V\u002FU\u002FV\u002FF 분류)\n\n## 2. 결정 필요 항목\n| ID | 항목 | 막는 것(섹션 · 작업) | 선택지 | 권장안 + 근거 | 결정 시점 | 상태 |\n- 사람(오너 · 사용자 · Chief)이 정해야 착수할 수 있는 것을 맨 앞에 둔다. 없으면 \"없음\".\n- 본문의 `[결정 필요: A vs B — 근거]` 인라인 표시(R3)는 모두 여기로 승격한다.\n- 닫힌 항목은 지우지 않는다 — 상태를 ✅ 로 바꾸고 **결정 내용 · 결정자 · 일시**를 남긴다(K2).\n- 기술 방식 선택(담당 에이전트가 정하는 것)은 여기가 아니라 §4 구현 결정으로 간다.\n\n## 3. 범위\n### 3.1 포함\n| 영역 | 유형 | 내용 | 관련 결정 |\n- 요구사항 1건 = 핵심 내용(무엇을 · 왜) + 작업 체크리스트(R5). 유형은 [개발] \u002F [콘텐츠] \u002F [리포트].\n### 3.2 이번 버전 비포함 — 후속으로 미룬 것과 그 버전(R2)\n### 3.3 영구 비범위 — 하지 않기로 한 것과 이유(있을 때만)\n### 3.4 인수 조건\n- `C1` … 기능 단위 Given-When-Then(R8). 테스트로 직역 가능해야 한다.\n- \"언제 완성인가\"의 유일한 정의다. §6 검증은 이 조건을 어떻게 확인하는지를 적는다.\n\n## 4. 구현 방법\nR9 에 따라 **작업 담당 에이전트**가 도출한다. 하위 절은 해당될 때만 쓴다.\n### 4.1 아키텍처 · 구조 — 층 · 구성요소 · 경계 · 의존 방향(다이어그램 보조, R4)\n### 4.2 설계 — 모듈 · 인터페이스 · 상태 · 오류\u002F재시도 · 동시성\n### 4.3 데이터 — 스키마 · 저장 위치 · 수명\u002F보존 · 마이그레이션 · 민감도\n### 4.4 보안 · 권한 — 위협 · 권한 경계 · 비밀 관리 · 감사 기록\n### 4.5 작업 분할 — 손댈 파일\u002F모듈 · 작업 체크리스트(R5) · 담당 에이전트 · 마일스톤 · 의존 관계\n\n각 절 안의 방식 선택은 **구현 결정** 단위로 기록한다:\n\n#### I1. \u003C무엇을 정하나>\n| 후보 | 방식 | 장점 | 단점 · 비용 |\n|---|---|---|---|\n| ⓐ | … | … | … |\n| ⓑ | … | … | … |\n- **채택:** ⓐ\n- **선택 근거:** 업계 관행 · 선례 · 측정값 · 제약(버전 목표 · 일정 · 기존 구조)과의 정합 — 근거 링크(K3)\n- **기각 이유:** ⓑ — 왜 아닌가(후보마다 한 줄)\n- **반증 조건:** 이것이 사실로 드러나면 이 결정을 다시 연다\n- **부작용:** 이 채택이 다른 모듈 · 성능 · 호환성 · 운영에 주는 영향 → §5 에 `I1` 출처로 옮긴다\n\n## 5. 리스크와 보완책\n| ID | 리스크 | 출처 | 영향 | 가능성 | 보완책 | 보완 후 잔여 리스크 |\n- 출처 = `외부`(시장 · 규제 · 제공사 · 사용자 행동) 또는 **구현 결정 ID**(`I1` …)(R10).\n- 리스크만 나열하지 않는다 — 행마다 보완책과 남는 위험을 같이 쓴다.\n\n## 6. 검증\n- §3.4 인수 조건(`C1` …)마다 무엇으로 확인하나(자동 테스트 · 골든 · 실기 · 사람 리뷰) · 통과 게이트\n- (제품 기능일 때) 성공 기준(공식 + 기간) · 선행 지표 · 후행 지표\n- (R6 Yes) AI 부록 4칸\n\n## 7. 결과\n검증을 실행한 **뒤** 사실만 기입한다(착수 전에는 \"미실행\", K4).\n- 실행한 검증과 결과(수치 · 통과\u002F실패 · 실행 일시 · 커밋)\n- 계획 대비 바뀐 것 — 바뀐 결정 · 구현 결정 ID 와 이유(원래 행은 남기고 \"→ §7 참조\")\n- 남은 것(미충족 인수 조건 · 미검증 항목)과 넘긴 버전\n\n## 8. 후속 문서 (선택)\n- 이 버전으로 갱신이 필요한 다른 문서(로드맵 · INDEX · 상·하위 PRD · 정책)\n```\n\n## 맥락 원칙 (K1–K5) — LLM wiki 토대\n\n| # | 원칙 | 규칙 |\n|---|---|---|\n| **K1** | 안정 ID | 결정 필요 항목은 PRD 별 접두어 + 번호(예: `W1`), 인수 조건 `C1…`, 구현 결정 `I1…`, 리스크 `K1…`. 한 번 붙인 ID 는 바꾸거나 재사용하지 않는다. 다른 문서에서는 `\u003C버전>#\u003CID>`(예: `v2.1.0#I3`)로 인용한다 |\n| **K2** | 결정 보존 | 닫힌 결정 · 기각한 후보를 지우지 않는다. 번복은 새 행 또는 §7 결과에 쓰고 \"이전 결정 X 를 대체\"를 명시한다 — 이력이 곧 맥락이다 |\n| **K3** | 근거 연결 | 채택 · 결정마다 근거를 링크한다(리포트 · ideation · 측정 · 외부 URL · 커밋 · 선행 PRD ID). 근거 없는 \"그냥 이렇게\"는 기록하지 않는다 |\n| **K4** | 결과는 사실 | §7 은 실행 후 관측한 사실만. 계획과 다르면 차이와 이유를 쓴다 — 다음 버전 PRD 가 이것을 인용해 출발한다 |\n| **K5** | 고정 메타 | 상단 메타 블록의 키(상태 · 완성도 · 유형 · 정본·선행 · 대체)와 섹션 번호를 바꾸지 않는다 — 기계가 문서들을 가로질러 읽을 수 있게 |\n\n용어는 정본 한 곳(용어집 · 결정 문서)에서 정의하고 PRD 는 링크한다. PRD 가 새 용어를 들이면 처음 쓰는\n곳에서 정의한다.\n\n## 요구사항 3대 유형\n\n| 유형 | 산출물 | 예시 |\n|---|---|---|\n| **개발** | 코드 | 웹사이트, 제품(앱\u002F기능), 내부 엔진 |\n| **콘텐츠 제작** | 글·미디어 | 광고 소재 · 아티클(긴 글) · 포스트(짧은 글) |\n| **리포트 작성** | 문서 | 보고서(docs) · PPT(슬라이드) |\n\n- 한 PRD 에 복수 · 혼재 가능 — §3.1 포함 표의 \"유형\" 열로 구분한다.\n- **디자인 = 내포**, 독립 4번째 유형 아님. 요구사항이 디자인 요소(도표 · 인포그래픽 · UI · 이미지 · 영상 ·\n  데이터 시각화 · PPT 레이아웃)를 포함하면 그 요구사항의 작업 체크리스트에 디자인 작업이 딸린다.\n- 요구사항 1건(핵심 내용 + 작업 체크리스트)이 다운스트림 실행(스페셜리스트 dispatch)의 입력 단위다.\n\n## 기획 워크플로 누적 기입\n\n기획 워크플로(new-build \u002F improvement)는 서브워크플로가 끝날 때마다 **같은 양식의 해당 섹션에 누적\n기입**한다(별도 양식을 만들지 않는다).\n\n| 서브워크플로 산출 | 기입 위치 |\n|---|---|\n| 아이디어 · 요구사항 | §1 목표(배경) · §3.1 포함 |\n| 시장(요약 + 리포트 evidence_ref) | §1 배경 · 대상 |\n| KPI · 데이터 | §1 배경 · §6 성공 기준 · 지표 |\n| 가설 | §1 가설과 가정 |\n| 문제정의 종착(problem-definition) | §1 ~ §3 확정 |\n| wbs | §4.5 작업 분할 |\n\n## 작성 규칙 (R1–R10)\n\n> **(A) R1–R5 = 맥락 · 오버스펙 축** — 세부 구현에 매몰돼 그 버전의 기획 의도를 해치지 않도록 경계와\n> 상위 목표를 PRD 가 직접 들고 있게 한다.\n> **(B) R6–R8 = 확률성 · 검증 축** — AI 제품 PRD 는 결정론적 SW PRD 와 다른 종(種)이라는 외부\n> 담론(ideation `260625-ai-planning-insights.md`, 21개 소스)을 흡수한다.\n> **(C) R9–R10 = 의사결정 기록 축** — 구현 방법을 \"정답 하나\"가 아니라 후보 · 채택 · 근거 · 부작용의\n> 기록으로 남겨 맥락 집합(K1–K5)을 채운다.\n\n**R1. 버전 계층 인지 (상위 목표 상속).** 버전의 어느 자리가 바뀌었나로 그 PRD 가 *정의*할 범위가 달라진다.\n\n| 바뀐 자리 | 그 PRD 가 정의 | 하위 PRD |\n|---|---|---|\n| **X**(major) | `X.n.n` 전체의 목표 · 개요(umbrella) | X.*.* 가 인용 |\n| **Y**(minor) | `n.Y.n` 전체의 목표 · 개요 | n.Y.* 가 인용 |\n| **Z**(patch) | 상위 목표를 **인용만**(재정의 금지) + 그 안에서 맡는 조각 | — |\n\n- §1 목표에 상위 목표 인용 · 이 버전 목표 · 맡는 조각을 둔다. 상위가 미정의면 관측 · 합성하고\n  \"synthesized\" 로 표기한다.\n- 버전 표기 · 핫픽스 처리 등 버전 체계 자체는 저장소의 architecture 문서를 따른다.\n\n**R2. §범위 = 포함 + 이번 버전 비포함 + 영구 비범위 + 인수 조건.** \"범위\"와 \"스코프\"는 같은 말이다 —\n섹션은 §3 범위 하나다. 이번 비포함(후속 버전 가능)과 영구 비범위(하지 않음)를 구분하고, **인수 조건도\n범위 안(§3.4)에 둔다** — 무엇을 하는가와 언제 다 했는가는 같은 경계의 두 면이다.\n\n**R3. 지시 요구사항 전사 + 결정 표시.** 사용자 · Chief 지시의 요구사항을 PRD 에 **그대로 전사**해\n\"요구사항 → 충족\"을 추적한다. 사람이 정해야 할 지점은 `[결정 필요: A vs B — 근거]` 로 표시해 §2 로\n승격하고, 기술 방식 선택이면 §4 구현 결정(R9)으로 기록한다. 임의 선택해 묻어두지 않는다.\n\n**R4. As-Is\u002FTo-Be = 개념 + 형태 이중 표현.** 표 · 다이어그램(트리 · 플로우)으로 두 층을 모두 쓴다.\n- **개념적 변화** — 역할 · 의미 · 책임의 이동.\n- **형태(코드) 변화** — 경로 · 파일 · 시그니처 · 디렉토리 구조의 전후.\n\n**R5. 작업 체크리스트 = 리뷰 대상(초안, 확정 아님).** §3.1 · §4.5 의 체크리스트 · 손댈 파일은 *제안*이다.\n`requirements-analysis` §리뷰 게이트에서 담당 스페셜리스트가 ① 실행 가능성 ② **오버스펙**(버전 목표\n대비 과대) ③ 누락 · 부작용을 검토해 가감 · 확정한다. 리뷰 전 체크리스트는 binding 아님.\n\n**R6. AI 제품 PRD 분기 (결정론\u002F확률론 = 세 번째 축).** 먼저 묻는다 — **\"이 제품에 LLM\u002F에이전트가\n들어가나?\"** No 면 §6 그대로. Yes 면 §6 에 **AI 부록 4칸**을 강제한다 — 같은 입력에 출력이 달라지므로\n\"단일 행동\"이 아니라 **\"받아들일 만한 답변의 범위\"** 를 설계한다.\n\n| 칸 | 정의 | 비고 |\n|---|---|---|\n| ① 허용 답변 범위 | \"무엇이 일어나야\"가 아니라 **\"어떤 답이 받아들일 만한가\"** | 범위로 정의 |\n| ② Eval Plan | 입력 · 기대 출력 · 실제 출력 · 합격 여부 셋 **20~30 케이스로 시작**(운영 시 누적). 프롬프트 수정마다 **전체 재실행(회귀)** | \"프롬프트 수렁\" 탈출 수단 |\n| ③ 실패 정의 + 가드레일 | 무엇이 실패인가 + **Always do \u002F Ask first \u002F Never do** 3단 경계 | 자율성 · 통제 균형 |\n| ④ 3단계 평가 피라미드 | 규칙 기반(자동 · 저렴) → LLM-as-Judge(빠르나 편향) → 사람(느리나 최종) | 일상=①②, 중대 변경=③ |\n\n> 근거: 외부 4소스(원티드랩 PO \"정답 대신 시험지\", \"AI PRD는 무엇이 달라야\", \"PRD는 죽었다 Evals=Moat\",\n> \"AI PM 2026 로드맵\")가 **\"AI PRD = 허용 범위 + Eval\"** 로 수렴. 평가 기준 · 가드레일 · 데이터셋은 모델\n> 교체 후에도 남는 고유 자산이다. 내부 개발 PRD 도 AI 기능이면 Yes.\n\n**R7. 완성도 단계 척도.** HARD GATE 의 이진 충족과 별개로 성숙도를 메타 블록에 표기한다.\n\n| 점수 | 도달 조건 | 의미 |\n|---|---|---|\n| **30** | 목표 · 대상 · 메인 시나리오 | 리뷰 시작 가능 |\n| **50** | + 배경 · 맥락 · 중요 유즈케이스 · 결정 필요 항목 | 본격 검토 |\n| **80** | + 구현 결정(후보 · 채택 · 근거) · 리스크 · 검증 계획 | 착수 가능 |\n| **100** | 전 섹션 + HARD GATE + §7 결과 | frozen(`docs` 스킬 판정) |\n\n**R8. 인수 조건 = Given-When-Then.** \"AC\" · \"수용 기준\" 대신 **인수 조건**이라고 쓴다. §3.4 에 `C1…`\nID 를 붙여 Given-When-Then 으로 쓰고 테스트로 직역 가능하게 한다. 문서 위계 — **PRD**(무엇을 만드나) →\n**인수 조건**(언제 완성인가) → **Policy**(어떤 기준으로 일관성).\n\n```\nC1  Given  사용자가 비회원 상태\n    When   이메일로 가입 시도\n    Then   인증 메일이 발송된다\n```\n\n**R9. 구현 방법 = 담당 에이전트가 전문가 관점에서 후보를 비교해 채택.** §4 는 PM 이 혼자 정하지 않는다.\n각 작업을 맡을 에이전트가 **자기 분야 최고 수준의 전문가라면 어떻게 하겠는가**를 기준으로 후보를 내고,\n그중 하나를 채택한 **의사결정 과정**을 구현 결정(`I1…`) 형식으로 남긴다. PM 은 통합 · 조정한다.\n\n| 하위 절 | 주로 도출하는 담당 | 반드시 담을 것 |\n|---|---|---|\n| 4.1 아키텍처 · 구조 | backend-engineer (설계 단계) | 경계 · 의존 방향 · 확장\u002F교체 지점 · 선례(업계 표준 · 레퍼런스 구현) |\n| 4.2 설계 | 해당 구현 담당(backend-engineer · frontend-engineer · infra …) | 인터페이스 · 상태 · 오류\u002F재시도 · 동시성 · 테스트 가능성 |\n| 4.3 데이터 | data-engineer (분석이면 data-analyst) | 스키마 · 저장 위치 · 보존\u002F삭제 · 마이그레이션 · 민감도 |\n| 4.4 보안 · 권한 | infra (보안) | 위협 · 권한 경계 · 비밀 관리 · 감사 기록 |\n\n- 구현 결정마다 **후보 ≥2 · 채택안 · 선택 근거(근거 링크) · 후보별 기각 이유 · 반증 조건 · 부작용**.\n  후보가 사실상 하나뿐이면 \"검토한 대안 없음 — 이유\"를 쓴다.\n- 최고 전문가 관점은 \"가장 정교한\"이 아니라 **\"이 버전 목표에 가장 적합한\"** 이다 — 버전 목표를 넘는\n  설계는 R5 리뷰에서 오버스펙으로 깎는다.\n- 담당이 정해지지 않은 작업은 §4.5 에서 담당을 먼저 배정한 뒤 도출한다.\n\n**R10. 리스크 = 외부 위험 + 채택안의 부작용.** §5 는 바깥에서 오는 위험만이 아니라 **§4 에서 채택한\n방식이 만들어내는 부작용**도 다룬다. 구현 결정(`I#`)마다 다음을 점검해 해당하면 그 ID 를 출처로 행을\n만든다 — 다른 모듈 · 기존 사용자에 대한 영향 · 성능 · 비용 · 호환성\u002F마이그레이션 · 운영 부담 · 보안 표면 ·\n되돌리기 어려움. 부작용이 없다고 판단한 결정도 §4 의 \"부작용\"에 \"없음 — 이유\"를 남긴다.\n\n### 어휘 · 프레임 정렬\n\n- **Spec Kit 4게이트** — `requirements-analysis` 를 Specify → Plan → Tasks → Implement 어휘로 정렬.\n- **가치 문장 4요소** — §1 가치 문장을 **\"누가 · 왜 · 어떻게 · 어떤 가치\"** 구조로.\n- **산문 우선** — 텍스트 서술형 우선, 다이어그램은 보조(R4 형태 층).\n- **지시의 저주 회피** — 한 프롬프트에 요구사항이 많을수록 준수율이 급락. 작업 체크리스트는 다운스트림\n  스페셜리스트에 **1건씩** dispatch.\n\n## 저장 위치\n\n```\n\u003Crepo>\u002Fdocs\u002Fprd\u002F\u003Cversion>_\u003Cname>.md      ← PRD 본체 (repo 계층 · 릴리스 버전 1:1)\n\u003Corg>\u002Fdocs\u002Freports\u002F\u003Cname>_\u003CYYMMDD>.md    ← 리포트 (org 계층 · evidence_ref 대상)\n\u003Corg>\u002Fdocs\u002Fideation\u002F\u003Cname>_\u003CYYMMDD>.md   ← ideation (org 계층 · 발산)\n```\n\n분류 · 배치 · INDEX 는 `docs` 스킬, 저장소별 명명 · 버전 · 핫픽스 규칙은 그 저장소 architecture 문서.\n\n## HARD GATE: PRD ship 조건\n\n- [ ] §1~§7 순서 · 번호 그대로, 메타 블록 키 고정(K5)\n- [ ] §1 상위 목표 인용 · 이 버전 목표 · 맡는 조각(R1)\n- [ ] §2 결정 필요 항목 — blocking 항목 모두 ✅ + 결정 내용 · 결정자 · 일시(K2)\n- [ ] §3 포함 · 이번 비포함 · (영구 비범위) · 인수 조건 `C#` Given-When-Then(R2 · R8)\n- [ ] 지시 요구사항 전사(R3) · As-Is\u002FTo-Be 개념+형태(R4) · 작업 체크리스트 리뷰 통과(R5)\n- [ ] §4 구현 결정마다 후보 ≥2(또는 사유) · 채택 · 근거 링크 · 기각 이유 · 반증 조건 · 부작용(R9 · K3)\n- [ ] §5 리스크마다 보완책 · 잔여 리스크, 채택안 부작용이 `I#` 출처로 반영(R10)\n- [ ] §6 인수 조건마다 확인 수단 · (R6 Yes) AI 부록 4칸\n- [ ] §7 결과는 검증 실행 후 사실로 기입(K4) · R7 완성도 표기\n\n## Anti-Sycophancy\n\nPRD 본문에 다음 표현 금지:\n- \"검토 부탁드립니다 :)\"\n- \"흥미로운 기능\"\n- \"한번 생각해보시면 좋을\"\n\n대신:\n- \"권고: X. 반증 조건: Y.\"\n- \"결정 필요 항목: Z 의 trade-off (A vs B)\"\n\n## Reference\n\n- phuryn\u002Fpm-skills\u002Fpm-execution\u002Fcreate-prd (배경 · 대상 · 가치 · 지표 항목을 §1 · §6 에 흡수)\n- gstack `\u002Foffice-hours` design doc · Anti-Sycophancy · minimum approaches 2\n- ADR(Architecture Decision Record) 관행 — 구현 결정의 후보 · 채택 · 근거 · 결과 기록\n","# PRD Writer Skill\n\n## PRD 의 역할 — 제품 맥락 집합\n\nPRD 는 착수 전에 한 번 쓰고 버리는 기획서가 아니다. **이 버전에서 무엇을 왜 하기로 했고(결정), 어떻게\n만들기로 했고(구현 설계 — 기각한 후보 포함), 실제로 어떻게 됐는가(결과)** 를 한 곳에 남기는 제품 맥락\n집합이다. 버전마다 쌓인 PRD 가 이후 **LLM wiki 의 기본 토대**가 된다 — 에이전트가 \"왜 이렇게 돼 있지?\"를\n물었을 때 코드 대신 PRD 에서 답을 찾을 수 있어야 한다. 그래서 양식은 하나로 통일하고, 섹션 순서 · 번호 ·\nID 규칙을 고정한다(맥락 원칙 K1–K5).\n\n양식은 **하나**다 — 제품 기능 · 내부 개발 · 콘텐츠 · 리포트 모두 같은 양식을 쓰고, 해당하지 않는 하위 절만\n비운다. 저장소마다 다른 규칙(버전 체계 · 파일 위치 · 핫픽스 양식 · 배포 게이트)은 그 저장소의\narchitecture 문서가 정하고, 이 스킬은 그 규칙을 따른다.\n\n## 양식 (섹션 순서 · 번호 고정)\n\n```markdown\n# vX.Y.Z — \u003C제목>\n> **상태:** 초안 \u002F 검토 \u002F 진행 \u002F frozen (YYYY-MM-DD, revN) · **완성도(R7):** NN\u002F100\n> **요구사항 유형(R6):** [개발] \u002F [콘텐츠] \u002F [리포트] — LLM·에이전트가 들어가면 \"AI 제품\" 표기 → §6 AI 부록\n> **정본 · 선행:** 상위 PRD · 선행 PRD · 결정 문서 링크\n> **대체:** (있을 때만) 이 PRD 가 대체한 문서 \u002F 이 PRD 를 대체한 문서\n\n## 1. 목표\n- (R1) 상위 목표 인용 · 이 버전의 목표 · 이 버전이 그 안에서 맡는 조각 — 각 1줄\n- 이 버전이 끝나면 무엇이 가능해지나 — 한 문장\n- (제품 기능일 때) 배경(사용자 needs · JTBD · 기존 시도와 한계) · 대상(주 segment · 명시적 제외) ·\n  가치 문장(누가 · 왜 · 어떻게 · 어떤 가치) · 가설과 가정(V\u002FU\u002FV\u002FF 분류)\n\n## 2. 결정 필요 항목\n| ID | 항목 | 막는 것(섹션 · 작업) | 선택지 | 권장안 + 근거 | 결정 시점 | 상태 |\n- 사람(오너 · 사용자 · Chief)이 정해야 착수할 수 있는 것을 맨 앞에 둔다. 없으면 \"없음\".\n- 본문의 `[결정 필요: A vs B — 근거]` 인라인 표시(R3)는 모두 여기로 승격한다.\n- 닫힌 항목은 지우지 않는다 — 상태를 ✅ 로 바꾸고 **결정 내용 · 결정자 · 일시**를 남긴다(K2).\n- 기술 방식 선택(담당 에이전트가 정하는 것)은 여기가 아니라 §4 구현 결정으로 간다.\n\n## 3. 범위\n### 3.1 포함\n| 영역 | 유형 | 내용 | 관련 결정 |\n- 요구사항 1건 = 핵심 내용(무엇을 · 왜) + 작업 체크리스트(R5). 유형은 [개발] \u002F [콘텐츠] \u002F [리포트].\n### 3.2 이번 버전 비포함 — 후속으로 미룬 것과 그 버전(R2)\n### 3.3 영구 비범위 — 하지 않기로 한 것과 이유(있을 때만)\n### 3.4 인수 조건\n- `C1` … 기능 단위 Given-When-Then(R8). 테스트로 직역 가능해야 한다.\n- \"언제 완성인가\"의 유일한 정의다. §6 검증은 이 조건을 어떻게 확인하는지를 적는다.\n\n## 4. 구현 방법\nR9 에 따라 **작업 담당 에이전트**가 도출한다. 하위 절은 해당될 때만 쓴다.\n### 4.1 아키텍처 · 구조 — 층 · 구성요소 · 경계 · 의존 방향(다이어그램 보조, R4)\n### 4.2 설계 — 모듈 · 인터페이스 · 상태 · 오류\u002F재시도 · 동시성\n### 4.3 데이터 — 스키마 · 저장 위치 · 수명\u002F보존 · 마이그레이션 · 민감도\n### 4.4 보안 · 권한 — 위협 · 권한 경계 · 비밀 관리 · 감사 기록\n### 4.5 작업 분할 — 손댈 파일\u002F모듈 · 작업 체크리스트(R5) · 담당 에이전트 · 마일스톤 · 의존 관계\n\n각 절 안의 방식 선택은 **구현 결정** 단위로 기록한다:\n\n#### I1. \u003C무엇을 정하나>\n| 후보 | 방식 | 장점 | 단점 · 비용 |\n|---|---|---|---|\n| ⓐ | … | … | … |\n| ⓑ | … | … | … |\n- **채택:** ⓐ\n- **선택 근거:** 업계 관행 · 선례 · 측정값 · 제약(버전 목표 · 일정 · 기존 구조)과의 정합 — 근거 링크(K3)\n- **기각 이유:** ⓑ — 왜 아닌가(후보마다 한 줄)\n- **반증 조건:** 이것이 사실로 드러나면 이 결정을 다시 연다\n- **부작용:** 이 채택이 다른 모듈 · 성능 · 호환성 · 운영에 주는 영향 → §5 에 `I1` 출처로 옮긴다\n\n## 5. 리스크와 보완책\n| ID | 리스크 | 출처 | 영향 | 가능성 | 보완책 | 보완 후 잔여 리스크 |\n- 출처 = `외부`(시장 · 규제 · 제공사 · 사용자 행동) 또는 **구현 결정 ID**(`I1` …)(R10).\n- 리스크만 나열하지 않는다 — 행마다 보완책과 남는 위험을 같이 쓴다.\n\n## 6. 검증\n- §3.4 인수 조건(`C1` …)마다 무엇으로 확인하나(자동 테스트 · 골든 · 실기 · 사람 리뷰) · 통과 게이트\n- (제품 기능일 때) 성공 기준(공식 + 기간) · 선행 지표 · 후행 지표\n- (R6 Yes) AI 부록 4칸\n\n## 7. 결과\n검증을 실행한 **뒤** 사실만 기입한다(착수 전에는 \"미실행\", K4).\n- 실행한 검증과 결과(수치 · 통과\u002F실패 · 실행 일시 · 커밋)\n- 계획 대비 바뀐 것 — 바뀐 결정 · 구현 결정 ID 와 이유(원래 행은 남기고 \"→ §7 참조\")\n- 남은 것(미충족 인수 조건 · 미검증 항목)과 넘긴 버전\n\n## 8. 후속 문서 (선택)\n- 이 버전으로 갱신이 필요한 다른 문서(로드맵 · INDEX · 상·하위 PRD · 정책)\n```\n\n## 맥락 원칙 (K1–K5) — LLM wiki 토대\n\n| # | 원칙 | 규칙 |\n|---|---|---|\n| **K1** | 안정 ID | 결정 필요 항목은 PRD 별 접두어 + 번호(예: `W1`), 인수 조건 `C1…`, 구현 결정 `I1…`, 리스크 `K1…`. 한 번 붙인 ID 는 바꾸거나 재사용하지 않는다. 다른 문서에서는 `\u003C버전>#\u003CID>`(예: `v2.1.0#I3`)로 인용한다 |\n| **K2** | 결정 보존 | 닫힌 결정 · 기각한 후보를 지우지 않는다. 번복은 새 행 또는 §7 결과에 쓰고 \"이전 결정 X 를 대체\"를 명시한다 — 이력이 곧 맥락이다 |\n| **K3** | 근거 연결 | 채택 · 결정마다 근거를 링크한다(리포트 · ideation · 측정 · 외부 URL · 커밋 · 선행 PRD ID). 근거 없는 \"그냥 이렇게\"는 기록하지 않는다 |\n| **K4** | 결과는 사실 | §7 은 실행 후 관측한 사실만. 계획과 다르면 차이와 이유를 쓴다 — 다음 버전 PRD 가 이것을 인용해 출발한다 |\n| **K5** | 고정 메타 | 상단 메타 블록의 키(상태 · 완성도 · 유형 · 정본·선행 · 대체)와 섹션 번호를 바꾸지 않는다 — 기계가 문서들을 가로질러 읽을 수 있게 |\n\n용어는 정본 한 곳(용어집 · 결정 문서)에서 정의하고 PRD 는 링크한다. PRD 가 새 용어를 들이면 처음 쓰는\n곳에서 정의한다.\n\n## 요구사항 3대 유형\n\n| 유형 | 산출물 | 예시 |\n|---|---|---|\n| **개발** | 코드 | 웹사이트, 제품(앱\u002F기능), 내부 엔진 |\n| **콘텐츠 제작** | 글·미디어 | 광고 소재 · 아티클(긴 글) · 포스트(짧은 글) |\n| **리포트 작성** | 문서 | 보고서(docs) · PPT(슬라이드) |\n\n- 한 PRD 에 복수 · 혼재 가능 — §3.1 포함 표의 \"유형\" 열로 구분한다.\n- **디자인 = 내포**, 독립 4번째 유형 아님. 요구사항이 디자인 요소(도표 · 인포그래픽 · UI · 이미지 · 영상 ·\n  데이터 시각화 · PPT 레이아웃)를 포함하면 그 요구사항의 작업 체크리스트에 디자인 작업이 딸린다.\n- 요구사항 1건(핵심 내용 + 작업 체크리스트)이 다운스트림 실행(스페셜리스트 dispatch)의 입력 단위다.\n\n## 기획 워크플로 누적 기입\n\n기획 워크플로(new-build \u002F improvement)는 서브워크플로가 끝날 때마다 **같은 양식의 해당 섹션에 누적\n기입**한다(별도 양식을 만들지 않는다).\n\n| 서브워크플로 산출 | 기입 위치 |\n|---|---|\n| 아이디어 · 요구사항 | §1 목표(배경) · §3.1 포함 |\n| 시장(요약 + 리포트 evidence_ref) | §1 배경 · 대상 |\n| KPI · 데이터 | §1 배경 · §6 성공 기준 · 지표 |\n| 가설 | §1 가설과 가정 |\n| 문제정의 종착(problem-definition) | §1 ~ §3 확정 |\n| wbs | §4.5 작업 분할 |\n\n## 작성 규칙 (R1–R10)\n\n> **(A) R1–R5 = 맥락 · 오버스펙 축** — 세부 구현에 매몰돼 그 버전의 기획 의도를 해치지 않도록 경계와\n> 상위 목표를 PRD 가 직접 들고 있게 한다.\n> **(B) R6–R8 = 확률성 · 검증 축** — AI 제품 PRD 는 결정론적 SW PRD 와 다른 종(種)이라는 외부\n> 담론(ideation `260625-ai-planning-insights.md`, 21개 소스)을 흡수한다.\n> **(C) R9–R10 = 의사결정 기록 축** — 구현 방법을 \"정답 하나\"가 아니라 후보 · 채택 · 근거 · 부작용의\n> 기록으로 남겨 맥락 집합(K1–K5)을 채운다.\n\n**R1. 버전 계층 인지 (상위 목표 상속).** 버전의 어느 자리가 바뀌었나로 그 PRD 가 *정의*할 범위가 달라진다.\n\n| 바뀐 자리 | 그 PRD 가 정의 | 하위 PRD |\n|---|---|---|\n| **X**(major) | `X.n.n` 전체의 목표 · 개요(umbrella) | X.*.* 가 인용 |\n| **Y**(minor) | `n.Y.n` 전체의 목표 · 개요 | n.Y.* 가 인용 |\n| **Z**(patch) | 상위 목표를 **인용만**(재정의 금지) + 그 안에서 맡는 조각 | — |\n\n- §1 목표에 상위 목표 인용 · 이 버전 목표 · 맡는 조각을 둔다. 상위가 미정의면 관측 · 합성하고\n  \"synthesized\" 로 표기한다.\n- 버전 표기 · 핫픽스 처리 등 버전 체계 자체는 저장소의 architecture 문서를 따른다.\n\n**R2. §범위 = 포함 + 이번 버전 비포함 + 영구 비범위 + 인수 조건.** \"범위\"와 \"스코프\"는 같은 말이다 —\n섹션은 §3 범위 하나다. 이번 비포함(후속 버전 가능)과 영구 비범위(하지 않음)를 구분하고, **인수 조건도\n범위 안(§3.4)에 둔다** — 무엇을 하는가와 언제 다 했는가는 같은 경계의 두 면이다.\n\n**R3. 지시 요구사항 전사 + 결정 표시.** 사용자 · Chief 지시의 요구사항을 PRD 에 **그대로 전사**해\n\"요구사항 → 충족\"을 추적한다. 사람이 정해야 할 지점은 `[결정 필요: A vs B — 근거]` 로 표시해 §2 로\n승격하고, 기술 방식 선택이면 §4 구현 결정(R9)으로 기록한다. 임의 선택해 묻어두지 않는다.\n\n**R4. As-Is\u002FTo-Be = 개념 + 형태 이중 표현.** 표 · 다이어그램(트리 · 플로우)으로 두 층을 모두 쓴다.\n- **개념적 변화** — 역할 · 의미 · 책임의 이동.\n- **형태(코드) 변화** — 경로 · 파일 · 시그니처 · 디렉토리 구조의 전후.\n\n**R5. 작업 체크리스트 = 리뷰 대상(초안, 확정 아님).** §3.1 · §4.5 의 체크리스트 · 손댈 파일은 *제안*이다.\n`requirements-analysis` §리뷰 게이트에서 담당 스페셜리스트가 ① 실행 가능성 ② **오버스펙**(버전 목표\n대비 과대) ③ 누락 · 부작용을 검토해 가감 · 확정한다. 리뷰 전 체크리스트는 binding 아님.\n\n**R6. AI 제품 PRD 분기 (결정론\u002F확률론 = 세 번째 축).** 먼저 묻는다 — **\"이 제품에 LLM\u002F에이전트가\n들어가나?\"** No 면 §6 그대로. Yes 면 §6 에 **AI 부록 4칸**을 강제한다 — 같은 입력에 출력이 달라지므로\n\"단일 행동\"이 아니라 **\"받아들일 만한 답변의 범위\"** 를 설계한다.\n\n| 칸 | 정의 | 비고 |\n|---|---|---|\n| ① 허용 답변 범위 | \"무엇이 일어나야\"가 아니라 **\"어떤 답이 받아들일 만한가\"** | 범위로 정의 |\n| ② Eval Plan | 입력 · 기대 출력 · 실제 출력 · 합격 여부 셋 **20~30 케이스로 시작**(운영 시 누적). 프롬프트 수정마다 **전체 재실행(회귀)** | \"프롬프트 수렁\" 탈출 수단 |\n| ③ 실패 정의 + 가드레일 | 무엇이 실패인가 + **Always do \u002F Ask first \u002F Never do** 3단 경계 | 자율성 · 통제 균형 |\n| ④ 3단계 평가 피라미드 | 규칙 기반(자동 · 저렴) → LLM-as-Judge(빠르나 편향) → 사람(느리나 최종) | 일상=①②, 중대 변경=③ |\n\n> 근거: 외부 4소스(원티드랩 PO \"정답 대신 시험지\", \"AI PRD는 무엇이 달라야\", \"PRD는 죽었다 Evals=Moat\",\n> \"AI PM 2026 로드맵\")가 **\"AI PRD = 허용 범위 + Eval\"** 로 수렴. 평가 기준 · 가드레일 · 데이터셋은 모델\n> 교체 후에도 남는 고유 자산이다. 내부 개발 PRD 도 AI 기능이면 Yes.\n\n**R7. 완성도 단계 척도.** HARD GATE 의 이진 충족과 별개로 성숙도를 메타 블록에 표기한다.\n\n| 점수 | 도달 조건 | 의미 |\n|---|---|---|\n| **30** | 목표 · 대상 · 메인 시나리오 | 리뷰 시작 가능 |\n| **50** | + 배경 · 맥락 · 중요 유즈케이스 · 결정 필요 항목 | 본격 검토 |\n| **80** | + 구현 결정(후보 · 채택 · 근거) · 리스크 · 검증 계획 | 착수 가능 |\n| **100** | 전 섹션 + HARD GATE + §7 결과 | frozen(`docs` 스킬 판정) |\n\n**R8. 인수 조건 = Given-When-Then.** \"AC\" · \"수용 기준\" 대신 **인수 조건**이라고 쓴다. §3.4 에 `C1…`\nID 를 붙여 Given-When-Then 으로 쓰고 테스트로 직역 가능하게 한다. 문서 위계 — **PRD**(무엇을 만드나) →\n**인수 조건**(언제 완성인가) → **Policy**(어떤 기준으로 일관성).\n\n```\nC1  Given  사용자가 비회원 상태\n    When   이메일로 가입 시도\n    Then   인증 메일이 발송된다\n```\n\n**R9. 구현 방법 = 담당 에이전트가 전문가 관점에서 후보를 비교해 채택.** §4 는 PM 이 혼자 정하지 않는다.\n각 작업을 맡을 에이전트가 **자기 분야 최고 수준의 전문가라면 어떻게 하겠는가**를 기준으로 후보를 내고,\n그중 하나를 채택한 **의사결정 과정**을 구현 결정(`I1…`) 형식으로 남긴다. PM 은 통합 · 조정한다.\n\n| 하위 절 | 주로 도출하는 담당 | 반드시 담을 것 |\n|---|---|---|\n| 4.1 아키텍처 · 구조 | backend-engineer (설계 단계) | 경계 · 의존 방향 · 확장\u002F교체 지점 · 선례(업계 표준 · 레퍼런스 구현) |\n| 4.2 설계 | 해당 구현 담당(backend-engineer · frontend-engineer · infra …) | 인터페이스 · 상태 · 오류\u002F재시도 · 동시성 · 테스트 가능성 |\n| 4.3 데이터 | data-engineer (분석이면 data-analyst) | 스키마 · 저장 위치 · 보존\u002F삭제 · 마이그레이션 · 민감도 |\n| 4.4 보안 · 권한 | infra (보안) | 위협 · 권한 경계 · 비밀 관리 · 감사 기록 |\n\n- 구현 결정마다 **후보 ≥2 · 채택안 · 선택 근거(근거 링크) · 후보별 기각 이유 · 반증 조건 · 부작용**.\n  후보가 사실상 하나뿐이면 \"검토한 대안 없음 — 이유\"를 쓴다.\n- 최고 전문가 관점은 \"가장 정교한\"이 아니라 **\"이 버전 목표에 가장 적합한\"** 이다 — 버전 목표를 넘는\n  설계는 R5 리뷰에서 오버스펙으로 깎는다.\n- 담당이 정해지지 않은 작업은 §4.5 에서 담당을 먼저 배정한 뒤 도출한다.\n\n**R10. 리스크 = 외부 위험 + 채택안의 부작용.** §5 는 바깥에서 오는 위험만이 아니라 **§4 에서 채택한\n방식이 만들어내는 부작용**도 다룬다. 구현 결정(`I#`)마다 다음을 점검해 해당하면 그 ID 를 출처로 행을\n만든다 — 다른 모듈 · 기존 사용자에 대한 영향 · 성능 · 비용 · 호환성\u002F마이그레이션 · 운영 부담 · 보안 표면 ·\n되돌리기 어려움. 부작용이 없다고 판단한 결정도 §4 의 \"부작용\"에 \"없음 — 이유\"를 남긴다.\n\n### 어휘 · 프레임 정렬\n\n- **Spec Kit 4게이트** — `requirements-analysis` 를 Specify → Plan → Tasks → Implement 어휘로 정렬.\n- **가치 문장 4요소** — §1 가치 문장을 **\"누가 · 왜 · 어떻게 · 어떤 가치\"** 구조로.\n- **산문 우선** — 텍스트 서술형 우선, 다이어그램은 보조(R4 형태 층).\n- **지시의 저주 회피** — 한 프롬프트에 요구사항이 많을수록 준수율이 급락. 작업 체크리스트는 다운스트림\n  스페셜리스트에 **1건씩** dispatch.\n\n## 저장 위치\n\n```\n\u003Crepo>\u002Fdocs\u002Fprd\u002F\u003Cversion>_\u003Cname>.md      ← PRD 본체 (repo 계층 · 릴리스 버전 1:1)\n\u003Corg>\u002Fdocs\u002Freports\u002F\u003Cname>_\u003CYYMMDD>.md    ← 리포트 (org 계층 · evidence_ref 대상)\n\u003Corg>\u002Fdocs\u002Fideation\u002F\u003Cname>_\u003CYYMMDD>.md   ← ideation (org 계층 · 발산)\n```\n\n분류 · 배치 · INDEX 는 `docs` 스킬, 저장소별 명명 · 버전 · 핫픽스 규칙은 그 저장소 architecture 문서.\n\n## HARD GATE: PRD ship 조건\n\n- [ ] §1~§7 순서 · 번호 그대로, 메타 블록 키 고정(K5)\n- [ ] §1 상위 목표 인용 · 이 버전 목표 · 맡는 조각(R1)\n- [ ] §2 결정 필요 항목 — blocking 항목 모두 ✅ + 결정 내용 · 결정자 · 일시(K2)\n- [ ] §3 포함 · 이번 비포함 · (영구 비범위) · 인수 조건 `C#` Given-When-Then(R2 · R8)\n- [ ] 지시 요구사항 전사(R3) · As-Is\u002FTo-Be 개념+형태(R4) · 작업 체크리스트 리뷰 통과(R5)\n- [ ] §4 구현 결정마다 후보 ≥2(또는 사유) · 채택 · 근거 링크 · 기각 이유 · 반증 조건 · 부작용(R9 · K3)\n- [ ] §5 리스크마다 보완책 · 잔여 리스크, 채택안 부작용이 `I#` 출처로 반영(R10)\n- [ ] §6 인수 조건마다 확인 수단 · (R6 Yes) AI 부록 4칸\n- [ ] §7 결과는 검증 실행 후 사실로 기입(K4) · R7 완성도 표기\n\n## Anti-Sycophancy\n\nPRD 본문에 다음 표현 금지:\n- \"검토 부탁드립니다 :)\"\n- \"흥미로운 기능\"\n- \"한번 생각해보시면 좋을\"\n\n대신:\n- \"권고: X. 반증 조건: Y.\"\n- \"결정 필요 항목: Z 의 trade-off (A vs B)\"\n\n## Reference\n\n- phuryn\u002Fpm-skills\u002Fpm-execution\u002Fcreate-prd (배경 · 대상 · 가치 · 지표 항목을 §1 · §6 에 흡수)\n- gstack `\u002Foffice-hours` design doc · Anti-Sycophancy · minimum approaches 2\n- ADR(Architecture Decision Record) 관행 — 구현 결정의 후보 · 채택 · 근거 · 결과 기록\n",{"name":5,"team":48,"tier":41,"used_by":49,"category":38,"triggers":51,"description":7,"dev_capability":44,"pm_conventions":55,"schema_version":57},"_skill",[50,37],"product-manager",{"keyword":52},[5,53,40,54],"요구사항 문서","기획서",{"hard_gate":56,"post_labeling":44,"anti_sycophancy":56,"minimum_approaches":57},true,2,"main","d2bf4d7228eb31fd3ca7a4272e53054a97fabc42","skills\u002Fprd","https:\u002F\u002Fgithub.com\u002FAdelie-Squad\u002Fsolosquad","https:\u002F\u002Fgithub.com\u002FAdelie-Squad","2026-11-14 02:43:05",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":56},[66,69,72],{"tool":67,"command":68},"npx","npx skills add Adelie-Squad\u002Fsolosquad --skill prd",{"tool":70,"command":71},"bunx","bunx skills add Adelie-Squad\u002Fsolosquad --skill prd",{"tool":73,"command":74},"pnpm","pnpm dlx skills add Adelie-Squad\u002Fsolosquad --skill prd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAdelie-Squad\u002Fsolosquad\u002Fblob\u002Fmain\u002Fskills\u002Fprd\u002FSKILL.md",[],[78,92,112,132,152,166],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":43},"01M6F9ZX66ETTM8NX73Z79MA21","xyz-hypothesis","검증 가능한 가설 프레임워크 — \"[X%] of [Y segment] will [Z behavior] within [T period], because [R]\". 입장+반증 조건 강제, 최소 2개 접근, V\u002FU\u002FV\u002FF 가정 분류. v1.3.5 에서 problem-definition P5 를 독립 skill 로 분리.","https:\u002F\u002Fgithub.com\u002FAdelie-Squad\u002Fsolosquad\u002Fblob\u002Fmain\u002Fskills\u002Fxyz-hypothesis\u002FSKILL.md",[],[85,86,41,87,88,28,33,89,90,31,37,91,39],"hypothesis","xyz hypothesis","definition","v1","segment","problem","behavior",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":103,"publishedAt":43},"01M6F9ZSHR17J5CH16AQAK0ER0","workflow-refinement","Workflow 종료 시 개선 제안. stage 의존성 \u002F handoff 효율 \u002F 평균 cycle time 분석. Chief 가 RETROSPECT 에서 호출.","https:\u002F\u002Fgithub.com\u002FAdelie-Squad\u002Fsolosquad\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow-refinement\u002FSKILL.md",[98],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[104,105,106,107,108,109,33,31,110,111,37,41],"workflow","refinement","workflow refinement","handoff","cycle","agile","stage","time",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":119,"publishedAt":43},"01M6F9ZKZJB8H3GWFJ95P6398V","workflow-manager","workflow(org 단위 조립물 — stage DAG 가 워크스페이스의 skill·agent 를 참조)의 대화형 매니저이자 작성 표준의 권위. 의도에서 workflow YAML 을 합성·검토·개선하도록 안내하고, 좋은 워크플로 노하우(본질 원칙=목표·근거·방법→결론·핸드오프 \u002F DAG 무순환 \u002F exit_criteria measurable \u002F 기획 3대 편향 가드)를 보유한다. 결정적 동작(new\u002Flist\u002Fshow\u002Fvalidate)은 solosquad workflow * 헬퍼로 위임. 사용 시점 — 워크플로를 새로 만들·고칠 때, 또는 다른 워크플로의 작성 품질을 판단할 때.","https:\u002F\u002Fgithub.com\u002FAdelie-Squad\u002Fsolosquad\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow-manager\u002FSKILL.md",[118],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},[120,28,104,33,121,122,123,37,31,110,124,125,126,127,41,128,39,129,130,131],"workflow manager","new","make","org","solosquad","show","exit","list","yaml","dag","validate","core",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":43},"01M6F9ZH962BA0SABW0DKR0FAF","wbs","마일스톤 → WBS (Work Breakdown Structure) 분해. PM 핵심 산출물. team OKR 의 KR 을 분기→주→일 단위 작업으로 변환. dependency graph + critical path 식별.","https:\u002F\u002Fgithub.com\u002FAdelie-Squad\u002Fsolosquad\u002Fblob\u002Fmain\u002Fskills\u002Fwbs\u002FSKILL.md",[],[134,38,139,140,141,28,33,31,142,143,144,145,146,147,148,149,41,150,151,39],"structure","breakdown","path","critical","decomposition","pm","dependency graph","dependency","okr","work","schedule","team","graph",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":159,"publishedAt":43},"01M6F9ZE85QYBBX4XMM0W71YN3","triage","Chief 의 과제 분류 도구. 사용자 입력을 4-way 분류 (discussion \u002F workflow \u002F cron \u002F goal) + Educational Nudge (불명확 시 KNOWLEDGE 가이드 선제시).","https:\u002F\u002Fgithub.com\u002FAdelie-Squad\u002Fsolosquad\u002Fblob\u002Fmain\u002Fskills\u002Ftriage\u002FSKILL.md",[158],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},[154,131,33,160,31,161,37,162,163,164,41,165,104],"Educational","classify","goal","nudge","knowledge","cron",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":173,"publishedAt":43},"01M6F9ZAFACH7XZ8KMFK9TKARX","skill-refinement","Skill 사용 후 개선 제안. ledger 분석으로 어느 skill 이 자주 실패 \u002F open_question 다발 \u002F 비효율인지 식별. Chief 가 retrospective 후 호출.","https:\u002F\u002Fgithub.com\u002FAdelie-Squad\u002Fsolosquad\u002Fblob\u002Fmain\u002Fskills\u002Fskill-refinement\u002FSKILL.md",[172],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},[105,174,33,175,31,37,176,41,177,109,178],"skill refinement","ledger","question","open","retrospective"]