dev-goraebap/lean-prd

Lean PRD 스킬

Lean PRD는 한 페이지에 담기는 가벼운 기획서다. 풀스펙 PRD와 달리 NFR·일정·이해관계자 표 같은 무거운 섹션을 빼고, **"왜 만드는가 + 이 버전의 범위 + 다음에 할 것"**만 남긴다. 개인 프로젝트·사내 도구·상용 서비스에 모두 쓰인다.

레퍼런스

references/에 유형별 완성 예제 3종이 있다. 인터뷰에서 유형이 정해지면 해당 레퍼런스만 로드해 톤·어휘·예시 밀도를 맞춘다.

| 유형 | 파일 | 특징 | |------|------|------| | 개인 프로젝트 | references/example-personal.md | 정성 목표 허용, 가벼운 어휘 | | 사내 프로젝트 | references/example-internal.md | 팀 생산성·운영 지표 중심 | | 상용 서비스 | references/example-product.md | 사용자 지표·비즈니스 목표 중심 |

---

1. 언제 트리거하는가

다음 유형의 요청에 스킬을 발동한다.

• "PRD 만들어줘", "기획서 초안 써줘", "프로젝트 기획서"
• "lean PRD", "린 기획서", "product brief"
• "이 아이디어 문서로 정리해줘", "프로젝트 개요 문서"
• 기존 .md 기획서를 주면서 "섹션 채워줘" / "톤 바꿔줘"

사용자가 이미 기획 초안을 손으로 쓰고 있으면 기존 내용을 덮지 말고 비어 있는 섹션만 인터뷰로 채운다.

---

2. 섹션 구조 (7개 고정)

| # | 섹션 | 용도 | 분량 가이드 | |---|------|------|------------| | 1 | Overview | 이 프로젝트가 한 눈에 뭔지 | 2~3문장 | | 2 | Background | 왜 만드는가 (맥락·pain·동기) | 2~3문장 | | 3 | Goals | 이 버전에서 달성할 것 | 불릿 3~5개 | | 4 | Non-goals | 이번에도 나중에도 안 할 것 | 불릿 2~4개 | | 5 | Scope | 이 버전의 핵심 기능 목록 | 불릿, 가능하면 하위 문서 링크 | | 6 | Later | 지금은 아니지만 나중에 할 것 | 불릿, 버전 힌트 선택 | | 7 | Constraints / Open Questions | 제약·미정 사안 | 불릿, 없으면 생략 가능 |

2-1. Non-goals vs Later를 절대 섞지 말 것

두 섹션을 혼동하면 다음 버전에서 "안 하기로 했는데 왜 지금 해?" 혼선이 생긴다. 다음 원칙을 강제한다.

| | Non-goals | Later | |---|-----------|-------| | 의미 | 의도적 영구 배제 | 단지 지금 버전 제외 | | 시간축 | 이 제품의 정체성상 안 함 | 로드맵 후보 | | 예시 | "다국어 지원은 하지 않음" | "소셜 로그인은 v2에서 검토" |

인터뷰 중 사용자가 "나중엔 할 수도 있어"라고 말하면 반드시 Later로 옮긴다. Non-goals는 "영영 안 할 것"만.

---

3. 인터뷰 절차

스킬은 두 개의 짧은 인터뷰를 먼저 수행한 뒤 섹션을 채운다. 인터뷰를 건너뛰면 톤이 어긋나 재작성 비용이 커지므로 생략하지 않는다.

3-1. 유형 확인 (인터뷰 1)

질문 — "이 프로젝트는 어떤 성격이에요?
         (1) 개인 프로젝트 — 혼자 쓰거나 취미
         (2) 사내 프로젝트 — 팀·회사 내부 도구
         (3) 상용 서비스 — 외부 사용자에게 제공"

답에 따라 한 개의 레퍼런스만 로드한다. 복수 해당이면 주 용도를 택한다. 판단이 애매할 때는 개인/사내를 먼저 두고 나중에 전환한다(§5 참조).

3-2. 지표 관리 스타일 확인 (인터뷰 2)

질문 — "Goals 섹션을 어떻게 관리할까요?
         (A) 기간·수치를 박고 엄격히 추적 (예: '3개월 내 DAU 1000')
         (B) 정성 목표 허용, 프리한 스타일 (예: '수동 배포 작업 제거')"

• A 선택: Goals의 각 불릿에 수치 + 기한 포함하도록 유도한다. 누락되면 인터뷰 중 자연스럽게 되묻는다.
• B 선택: 정성 목표 허용. 수치·기한 누락을 경고하지 않는다.

두 스타일을 섞어도 된다 — 기한이 있는 Goal 2개 + 정성 Goal 1개처럼.

3-3. 섹션 채우기

두 인터뷰 결과를 바탕으로 7개 섹션을 순서대로 대화하며 채운다. 각 섹션에서 다음 원칙을 지킨다.

1. 한 번에 하나씩 묻기 — 7개 질문을 한꺼번에 쏟지 않는다. 답을 듣고 다음 섹션.
2. 짧게 요약해 다시 보여주기 — 사용자 답변을 2~3문장으로 정리해 "이렇게 적을게요" 확인.
3. Scope → Later 순 — Scope 먼저 정해야 "이번 버전 바깥"이 드러난다.
4. Non-goals는 마지막에 — Scope·Later가 정해진 뒤 "이것들이 아닌데 혹시 배제 선언할 게?"로 유도한다.

인터뷰가 끝나면 전체 초안을 한 번에 보여주고 사용자 확인을 받는다.

---

4. 작성 규칙

4-1. 어휘 통일

| 쓰지 말 것 | 대체어 | |-----------|--------| | Product | Project (상용 서비스일 때만 Product 허용) | | Customer | User (상용일 때만 Customer 허용) | | Launch | Ship 또는 Release | | Problem (섹션명) | Background |

"Product"·"Customer" 같은 단어는 세일즈 톤을 유발한다. 개인·사내 프로젝트에서는 반드시 중립 용어로 치환한다.

4-2. Goals 작성

• 스타일 A(엄격): 3개월 내 주문 실패율 2% 이하 / 2026-Q3까지 응답 시간 p95 < 200ms
• 스타일 B(프리): 수동 배포 작업을 완전히 제거 / 신규 팀원 온보딩을 하루 안에

두 스타일 모두 동사로 시작하고 검증 가능한 형태를 권장하되, B에서는 강제하지 않는다.

4-3. Scope에 하위 문서 링크 자리 만들기

Scope의 각 불릿은 나중에 시퀀스 다이어그램·기능 명세 같은 하위 문서가 붙을 자리다. 현재 이 저장소에 해당 스킬이 없어도 링크 플레이스홀더를 비워둔다.

## Scope
- 주문 생성 — <!-- link: SEQ-001 -->
- 결제 승인 — <!-- link: SEQ-002 -->

나중에 시퀀스 스킬이 붙으면 주석을 실제 링크로 교체한다.

4-4. 분량 제어

총 분량은 화면 한 스크롤(대략 60~120 라인)을 넘지 않게 유지한다. 초과 조짐이 보이면:

• 긴 설명은 "Related Docs" 링크로 뺀다
• 기능 나열은 Scope에 불릿만 두고 상세는 하위 문서로 위임한다

---

5. 유형 전환

프로젝트는 "개인 → 사내 → 상용"처럼 진화할 수 있다. 사용자가 전환을 요청하면:

| 전환 | 스킬이 하는 일 | |------|----------------| | 개인 → 사내 | "User"를 "팀원·운영자"로, Goals에 팀 단위 지표 제안 | | 사내 → 상용 | "Project"→"Product" 허용, Background에 시장·사용자 맥락 추가 제안 | | 상용 → 사내 | "Customer"를 "User"로, 비즈니스 지표 → 운영 지표로 재프레이밍 | | 모든 역방향 | 어휘 중립화, 세일즈 톤 제거 |

전환 시 기존 Goals·Non-goals는 건드리지 않고 추가 제안만 한다. 사용자가 수락한 것만 반영한다.

---

6. 출력 스펙

6-1. 파일명

{project-slug}-lean-prd.md

예: blog-bot-lean-prd.md, deploy-cli-lean-prd.md, order-service-lean-prd.md

6-2. 저장 위치

사용자가 경로를 지정하면 그곳에, 지정하지 않으면 질문한다:

"Lean PRD 파일을 어디에 저장할까요?
 (예: ./docs/, ./, 프로젝트 루트)"

폴더가 없으면 생성한다.

6-3. frontmatter

---
name: 주문 서비스
type: product          # personal | internal | product
goals_style: strict    # strict | free
status: draft          # draft | active | archived
version: v1
---

type·goals_style은 §3 인터뷰 결과를 기록하는 자리다. 유형 전환 시 이 필드만 바꾸면 스킬이 톤을 재조정한다.

---

7. 생성 → 리뷰 → 개선 워크플로우

1. 초안 생성 — 인터뷰 후 7개 섹션을 채운 .md 파일을 지정 경로에 쓴다.
2. 리뷰 반영 — 사용자가 "Goals에 기한 빼줘" / "Non-goals에 X 추가" 같은 수정을 요청하면 해당 섹션만 수정한다.
3. 유형 전환 — §5 규칙을 따른다.
4. 아카이브 — 프로젝트가 완료되면 status: archived로 표시한다. 삭제하지 않는다.