write-spec

name	write-spec
description	아이디어 한 줄이나 문제 정의를 받아 기획서/PRD 초안을 만든다. 목표·비목표·타깃·성공지표·요구사항·스코프·리스크를 구조화하고, 각 결정의 '왜'를 함께 적는다. "기획서 써줘 / PRD 초안 / 스펙 잡아줘 / 이 기능 정리해줘" 요청 시.

작업 흐름(항상): 왜(목적·의도) → 무엇을 → 어떻게 → 기존 컨텍스트·리서치 → 기획 → 시각화 → 호출·실행 → 🔁회고·보완. 자세히 [[method]].

기획서·PRD 초안 작성 (반자동)

빈 문서 공포를 없앤다. AI가 뼈대와 초안, 사람 PM이 채우고 결정. 그대로 제출용이 아니라 검토용 초안이다.

1. 최소 정보 확보 (한 번에 하나씩)

아이디어가 막연하면 다음 3개만 먼저 확인한다(질문 폭탄 금지):

1. 무슨 문제를 푸나(누가 언제 겪는 불편)?
2. 누구를 위한 것인가?
3. 성공을 무엇으로 판단하나? 알 수 없으면 비워두지 말고 "가정"으로 채우되 가정임을 표시한다.

2. 데이터 원칙

• 시장·유저·지표 수치는 확인된 것만 인용. 없으면 "확인 필요(무엇을 보면 되는지)".
• 컨텍스트 문서/커넥터에 있는 실제 프로덕트 정보를 반영한다: cat "${PM_COPILOT_HOME:-$HOME/.pm-copilot}/data/context.md".

3. PRD 구조 (각 항목에 '왜'를 붙인다)

1. 한 줄 요약(TL;DR) — 무엇을 왜 만드나.
2. 배경 / 문제 — 근거(데이터·유저 목소리) 또는 "가정".
3. 목표(Goals) / 비목표(Non-goals) — 비목표를 명시해 스코프를 지킨다. 왜 이건 지금 안 하나.
4. 타깃 사용자 / 핵심 시나리오 — 대표 유저 스토리 2~3개.
5. 성공지표 — 노스스타 + 가드레일 지표(악화되면 안 되는 것). 왜 이 지표인가.
6. 요구사항 — 반드시(Must)/있으면(Should)/제외(Won't). 각 Must에 이유.
7. 스코프 & 단계 — MVP로 뭘 먼저 검증하나. 더 싸게 검증할 방법(가짜문·수동 MVP)도 제안.
8. 리스크 · 오픈 퀘스천 — 기술/법무/개인정보/의존성 + 아직 답 없는 질문.
9. 마일스톤(개략) — 확정 일정이 아니라 순서/의존성.

4. 자기검토로 연결 (권장)

초안을 만든 뒤, ask-sunbae 스킬로 곧바로 다각도 검토를 제안한다: "지금 이 초안, 사수한테 검사받아볼까요? 특히 성공지표·리스크를 봐드릴게요."

5. 저장/공유 (선택)

• 로컬 저장: data/specs/ 아래에 마크다운으로 저장(사용자가 원할 때).
• 노션/Confluence에 올리려면 커넥터로 초안 페이지 생성 제안 → 승인 후 작성(자동 게시 금지).

원칙 (교육/코칭)

• 정답만 던지지 말고, 왜 이 구조인지를 짧게 설명해 사람 PM이 다음엔 스스로 쓰게 돕는다.
• 근거 없는 자신감 금지. 약한 부분은 "여기가 약하다, 이걸 확인하면 강해진다"고 정직하게.

🎨 Figma 연동 (커넥터 figma 연결 시)

• 기존 Figma 디자인·기획서를 열람해 PRD의 근거·현황으로 쓴다(get_design_context).
• 불일치 시: 최신순이 기준이되, 기획자는 보통 Figma 편집 권한이 없으니 — 디자인이 최신이면 PRD를 현행화, 기획서가 최신이면 Figma를 고치지 말고 불일치를 디자이너에게 전달. 화면 단위는 [[screen-spec]]로.