| name | plan-6-document |
| description | [Plan] 기획자용 기획서 작성 스킬. "기획서 작성해주세요", "기획서 써주세요", "플랜 문서 작성" 등의 요청 시 트리거. Step 1-5의 결과를 종합하여 가설 기반 기획서 [Plan]을 작성하고 Notion에 저장한다. 스킬 내장 writing-style 규칙과 Notion Memory(glossary/principle)를 적용하여 스타일·용어·원칙 일관성을 보장한다. AI Driven Development 파이프라인의 6단계(최종). |
| compatibility | notion-update-page MCP 툴 필요. 이전 대화에 Step 1-5 결과가 존재해야 함 |
기획서 작성 (AI Driven Development Step 6/6)
이 스킬은 AI Driven Development 파이프라인의 최종 단계이다.
Step 1(브레인스토밍) + Step 2(기획 초안) + Step 3(Edge Case) + Step 4(UI Layout) + Step 5(Wireframe, 있는 경우)의 결과를 종합하여
가설 기반 [Plan] 기획서를 작성한다.
전제 조건
아래 로컬 파일이 모두 존재해야 한다:
- Step 1:
.claude/docs/brainstorm-*.md (브레인스토밍 결과)
- Step 2:
.claude/docs/draft-*.md (기획 초안 — 가설 / 사용자 정의 포함)
- Step 3:
.claude/docs/edge-case-*.md (Edge Case 처리 결과)
- Step 4:
.claude/docs/ui-layout-*.md (UI Layout)
- Step 5:
.claude/docs/wireframe-*.html (HTML 와이어프레임, 있는 경우)
Step 1~4 중 하나라도 없으면 사용자에게 이전 단계를 먼저 완료하도록 안내한다. Step 5 산출물이 없어도 기획서 작성은 진행 가능하며, 이 경우 "5. 유저 시나리오 → 화면 와이어프레임" 하위 섹션은 생략한다.
각 로컬 md 파일의 Notion 링크를 통해 상세 내용도 notion-fetch로 로드한다.
Memory Bootstrap (공통)
writing-style 규칙은 이 스킬 본문(아래 "작성 규칙" 및 "writing-style 검증" 섹션)에 내장되어 있어 외부 URL fetch가 필요 없다. Notion Memory는 glossary와 principle 두 가지만 읽기 전용으로 참조한다.
.claude/docs/ui-layout-*.md의 프론트매터에서 Memory URL을 읽는다.- 이 단계에서 사용할 memory:
glossary_url, principle_url
- 각 URL을
notion-fetch로 읽어 내용을 확보한다.
glossary_url → 용어 사전, 금지 표기principle_url → 제품 원칙 5개 + 위반 플래그 포맷
- URL이 누락된 memory는 해당 적용을 스킵하고 사용자에게 보고한다.
출력 전략
| 채널 | 용도 | 내용 |
|---|
| 터미널 | 대화 전용 | 진행 상황 안내, 1회 추가 질문, 사용자 확인 단계 |
| Notion | 최종 기획서 | 기존 내용을 모두 지우고 정리된 최종 기획서만 작성 |
| 로컬 md | 최종 기획서 보관 | 최종 기획서 전문 + Memory URL 프론트매터 계승 |
Notion 저장 — 클린업 후 최종 기획서만 남기기
Step 1에서 확보한 Notion 페이지를 사용한다.
기존에 Step 1~4에서 누적 작성된 내용을 모두 지우고, 최종 [Plan] 기획서만 깨끗하게 작성한다.
notion-update-page로 페이지 내용을 교체한다.
페이지 제목을 [기획서-Plan] {기획 주제} - {YYYY-MM-DD}로 변경한다.
로컬 md 파일
-
저장 경로: 프로젝트 루트의 .claude/docs/plan-{기획주제}.md
-
프론트매터는 plan-4의 값을 그대로 계승하여 기록한다:
---
project_name: {계승}
glossary_url: {URL}
flowchart_url: {URL}
principle_url: {URL}
constraint_url: {URL}
---
-
본문: 기획서 전문 (Notion에 작성한 것과 동일) + Notion 최종 기획서 링크
-
이전 Step의 로컬 md 파일(brainstorm, draft, edge-case, ui-layout)은 삭제하지 않는다 — 히스토리 참조용으로 유지.
터미널 출력 규칙
- 기획서 작성 과정: "기획서 작성 중..." 등 진행 상황만 안내.
- 1회 질문(비즈니스 임팩트), MVP 우선순위 확인, 차후 계획 후보 확인은 터미널에서 진행.
- 완료 시: Notion 링크와 로컬 파일 경로만 터미널에 출력.
- 기획서 본문은 터미널에 출력하지 않는다.
작성 규칙 (Memory 기반)
- 용어 (
glossary 적용): 모든 용어는 로드된 glossary 기준을 따른다. 금지 표기를 발견하면 권장 표기로 자동 치환한다. glossary에 없는 새 용어를 도입해야 하면 사용자에게 확인한다.
- ID 체계 (스킬 내장 writing-style 적용): 본문 전체에서 아래 ID 형식을 엄격 준수한다. 아래 목록이 곧 writing-style의 ID 표이며, 외부 페이지는 참조하지 않는다.
- F-XXX: MVP 요구사항 (기능)
- S-XXX: 화면 (와이어프레임 메타에서 참조)
- EC-XXX: 엣지 케이스
- Q-XXX: 미결 항목 / 원칙 위반 플래그
- SC-XXX: 유저 핵심 경험 다이어그램의 시나리오 노드
- 위 목록에 없는 접두사를 사용해야 하면 사용자에게 즉시 문의.
- 톤/표현 치환 (스킬 내장 writing-style 적용): 본문 톤은 다음 규정을 따른다 — 서술형 "~한다" 사용, 존댓말 금지, "사용자" 선호. 사용자가 별도로 금지/선호 표현 표를 제공한 경우에만 추가 치환을 수행한다.
- 구조화된 Markdown: 모든 섹션은 구조화된 Markdown(테이블·체크리스트·코드 블록)으로 작성한다.
[Plan] 기획자용 기획서 양식
문서 목적: 기획자가 디자이너, 개발자와 가설을 공유하고 검증 기준을 합의하기 위한 기획서.
가설 기반(hypothesis-driven) 양식으로 작성한다.
1. 배경과 문제 정의
문제 정의
자동 합성 + 1회 추가 질문
- Step 1(브레인스토밍)의 "문제 정의"와 Step 2(draft)의 "기획 배경"을 한 단락으로 합성한다.
- 본문 작성 전 터미널에서 사용자에게 1회 질문한다:
"이 문제가 비즈니스에 미치는 영향과 해결 시 가치는 무엇인가요?"
- 답변을 받아 유저 문제와 비즈니스 임팩트를 한 단락으로 연결한다.
어떤 유저(대상)가 (어떤 상황)에서 (어떤 어려움)을 겪고 있다.
이 문제는 (비즈니스 영향)으로 이어지고 있으며, 해결 시 (비즈니스 가치)가 발생한다.
관련 데이터
🟡 추후 PM 작성 — 빈 양식만 남긴다.
> 🟡 PM이 baseline → target 갭 데이터를 직접 채워 넣습니다.
2. 사용자 정의
📥 plan-2(draft)에서 사전 수집 — Step 2의 "사용자 정의" 항목을 그대로 표로 옮긴다.
| 대상 유저 | 행동 특성 | etc. |
|---|
| (Step 2 수집) | (Step 2 수집) | (Step 2 수집) |
Step 2에 사용자 정의가 없으면 사용자에게 plan-2를 먼저 보강하도록 안내한다.
3. 가설
📥 plan-2(draft)에서 사전 수집 — Step 2의 "가설" 항목을 그대로 옮긴다.
만약 (대상)가(이) (특정 행동)을 한다면, (기대 하는 결과)할 것이다.
가설이 여러 개인 경우 우선순위를 함께 표시한다.
4. 지표
성공 지표
🟡 추후 PM 작성 — 빈 양식만 남긴다.
> 🟡 PM이 baseline / target / 측정 방법을 직접 채워 넣습니다.
가드레일 메트릭
🟡 추후 PM 작성 — 빈 양식만 남긴다.
> 🟡 PM이 부작용 감지 지표를 직접 채워 넣습니다.
5. 유저 시나리오
유저 핵심 경험
🔄 자동 생성 (mermaid flowchart TD)
입력 소스:
- Step 2
flowchart_url memory (기존 프로세스 흐름 참조)
- Step 2(draft)의 사용자 시나리오 텍스트 (노드 추출)
- Step 3 엣지 케이스 (분기 진입점)
생성 규칙:
- 노드 라벨에 SC-XXX / EC-XXX ID를 명시한다 (다른 섹션과 상호 참조 가능).
- 엣지 케이스 진입점은 분기 노드(
-->|조건| EC-XXX)로 표기한다.
- 엣지 케이스 본문은 다이어그램에 풀어쓰지 않고 ID로만 연결한다(상세는 "엣지 케이스" 섹션).
flowchart TD
SC-001[진입] --> SC-002{분기}
SC-002 -->|정상| SC-003[핵심 경험]
SC-002 -->|예외| EC-001[엣지 케이스 처리]
SC-003 --> SC-004[결과 확인]
화면 와이어프레임
📎 사용자 직접 첨부 (Step 5 산출물 있을 때만)
.claude/docs/wireframe-*.html 파일이 존재하면 이 하위 섹션을 작성한다. 없으면 생략한다.
| 항목 | 내용 |
|---|
| 파일명 | wireframe-{기획주제}.html |
| 포함 화면 | (S-XXX 목록과 화면명) |
| 옵션 수 | (예: 3개 — 1 Safe + 2 Exploratory) |
| 추천 옵션 | (예: Option 2 — 이유) |
| 열람 방법 | 첨부 파일 다운로드 후 브라우저에서 열기 |
HTML 파일 첨부 프로세스:
Notion API는 파일 업로드를 지원하지 않으므로 아래 절차를 따른다:
- 메타 테이블 작성 후, 사용자에게 파일 첨부를 요청한다:
"화면 와이어프레임 섹션에 HTML 파일을 첨부해 주세요.
Finder에서 파일을 열어 드렸습니다. Notion 페이지의 해당 섹션 하단에 드래그앤드롭 해주세요."
open -R 명령으로 Finder에서 wireframe HTML 파일을 선택된 상태로 연다.notion-fetch로 페이지를 다시 로드하여 <file> 태그가 해당 섹션에 존재하는지 확인.- 파일이 확인되면 다음 단계로 진행. 확인되지 않으면 다시 요청.
- plan-6 완료 메시지는 파일 첨부가 확인된 후에만 출력한다.
MVP 요구사항
🤖 우선순위 자동 부여 → 사용자 확인
- Step 2 핵심 기능 목록을 그대로 옮긴다 (F-XXX ID 보존).
- 각 기능이 가설 검증에 필수인지 LLM이 판단하여 우선순위를 부여:
must: 이 기능 없이는 가설을 테스트할 수 없음should: 가설 검증을 보조하지만 없어도 기본 검증은 가능could: 가설과 직접 관련 없으나 사용자 경험 보조
- 결과를 터미널에 표로 보여주고 사용자에게 한 번 확인한다.
could로 분류된 항목은 "이번 시도에서 다루지 않는 것"으로 이동을 제안한다.
| ID | 요구 사항 | 우선 순위 |
|---|
| F-001 | (Step 2 기능명) | must / should / could |
이번 시도에서 다루지 않는 것
📋 그대로 옮김 — Step 2 "범위 제외" + Step 1 "Out of Scope"를 합쳐서 옮긴다.
| 제외 Scope |
|---|
| (예: 앨범 공유 기능 — 별도 기획으로 분리 예정) |
엣지 케이스 Edge Case
📋 그대로 옮김 — Step 3 결과를 그대로 옮긴다. EC-ID 보존.
| ID | Edge Case | 대응 방법 |
|---|
| EC-001 | (Step 3 상황) | (Step 3 결정) |
미결 항목 / 원칙 위반 플래그
🤖 자동 등록 + 사용자 추가
자동 등록 규칙:
- "Memory 기반 최종 검증" 단계에서 발견된 원칙 위반 의심 항목을 Q-XXX로 자동 등록한다.
- 자동 등록 항목의 기본값: 담당 =
기획, 상태 = open, 항목 = ⚠️ 원칙 #N ({원칙명}) 위반 의심 — ({근거}).
사용자 추가:
- 그 외 일반 미결 항목은 사용자가 plan-6 실행 중에 추가하거나 비워둔다.
| ID | 항목 | 담당 | 상태 | 기한 |
|---|
| Q-001 | ⚠️ 원칙 #N ({원칙명}) 위반 의심 — ({근거}) | 기획 | open | |
6. 정책 정의
🤖 자동 작성 (하이브리드 B+C)
작성 절차:
principle_url 메모리에서 제품 원칙 5개를 fetch한다.- 기획 내용을 원칙과 대조하여 관련 있는 원칙만 본문에 발췌하고, 각 원칙별로 신규/변경 정책을 서술한다.
- 섹션 끝에 원칙 5개 전체에 대한 검토 체크리스트를 한 줄로 표시한다 — 관련 원칙은
✅ 적용, 무관한 원칙은 ✅ 무관.
- 원칙 위반 의심 항목은 본 섹션에 적지 않고 "5. 유저 시나리오 → 미결 항목 / 원칙 위반 플래그"로 라우팅한다.
**원칙 #N ({원칙명})**
- 신규 정책: ({내용})
- 변경 정책: ({기존} → {변경})
**검토 체크리스트**
> 검토 완료: ✅ 원칙 #1 (무관) / ✅ 원칙 #2 (적용) / ✅ 원칙 #3 (무관) / ✅ 원칙 #4 (적용) / ✅ 원칙 #5 (무관)
7. 커뮤니케이션 계획
📋 5개 파트 체크박스 — 기획 성격에 따라 불필요한 파트 제거
기본값으로 5개 파트를 모두 체크박스로 나열한다. plan-6는 기획 내용(국내/해외/B2C/B2B 등)을 분석하여:
- 명백히 무관한 파트는 자동 제거 (예: 국내 전용 기능이면 일본/미국팀 라인 제거)
- 판단이 모호하면 모두 남겨둠
- [ ] **경영진** — 공유 시점:
- [ ] **운영실 (국내)** — 공유 시점:
- [ ] **운영실 (일본)** — 공유 시점:
- [ ] **미국팀** — 공유 시점:
- [ ] **마케팅 / 디자인** — 공유 시점:
8. 차후 계획
🤖 고도화 방향 자동 제안 → 사용자 확인
작성 절차:
- 가설 + MVP 요구사항을 기반으로 LLM이 2~3개의 고도화 방향 후보를 제안한다.
- 터미널에서 사용자에게 후보를 보여주고 한 줄로 정리할 방향을 선택받는다.
- 실패 시 처리는 고정값
기능 제거로 작성한다.
- **성공 시**: {고도화 방향 제시}
- **실패 시**: 기능 제거
Memory 기반 최종 검증 (작성 후 실행)
기획서 초안을 완성한 직후, 아래 3단계 검증을 수행한 후에만 Notion에 저장한다.
A. writing-style 검증 (스킬 내장 규칙)
- ID 체계: 본문 전체에서 F/S/EC/Q/SC-XXX 형식 준수 확인. 위 목록에 없는 접두사를 발견하면 사용자에게 즉시 문의.
- 톤/표현 치환: 스킬 내장 톤 규정(서술형 "~한다", 존댓말 금지, "사용자" 선호)을 적용한다. 사용자가 별도 표를 제공한 경우에만 추가 치환을 수행하고, 치환 이력은 별도 메모로 관리한다.
B. glossary 검증
- 기획서 본문의 모든 도메인 용어를 glossary와 대조.
- "금지 표기" 발견 시 권장 표기로 자동 치환.
- glossary에 없는 새 용어를 발견하면 사용자에게 "이 용어를 glossary에 추가할지, 기존 용어로 치환할지" 확인.
C. principle 위반 최종 스캔
- 기획서 전체를 principle의 5대 원칙과 대조.
- 위반 의심 항목이 있으면 "5. 유저 시나리오 → 미결 항목 / 원칙 위반 플래그"에 Q-XXX로 자동 추가한다.
- 원칙 페이지에 "위반 플래그 형식"이 정의되어 있으면 해당 포맷을 우선 사용한다.
- 사용자에게 플래그 목록을 보고하고 해결 방안을 논의한다. 사용자가 "우회 가능" 결정을 내리면 해당 Q-XXX의 상태를
resolved로 갱신.
검증 A/B/C 완료 후 Notion 저장으로 진행한다.
Notion 저장 및 완료
기획서 작성 + Memory 검증 완료 후:
- 기존 Notion 페이지의 내용을 모두 지우고 최종 기획서로 교체한다 (
notion-update-page 사용).
- 페이지 제목을
[기획서-Plan] {기획 주제} - {YYYY-MM-DD}로 변경한다.
- 로컬 md 파일(
.claude/docs/plan-{기획주제}.md)에 기획서 전문 + 프론트매터(Memory URL 계승)를 저장한다.
- 화면 와이어프레임 섹션이 있는 경우, 사용자가 HTML 파일을 첨부했는지
notion-fetch로 확인한 후에만 완료 메시지를 출력한다.
- 터미널에 Notion 링크와 로컬 파일 경로를 안내한다.
✅ 기획서 작성 완료 (Step 6/6)
[Plan] 기획서가 Notion에 저장되었습니다: {Notion URL}
로컬 파일: .claude/docs/plan-{기획주제}.md
