plan-6-document

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 두 가지만 읽기 전용으로 참조한다.

1. .claude/docs/ui-layout-*.md의 프론트매터에서 Memory URL을 읽는다.
2. 이 단계에서 사용할 memory: glossary_url, principle_url
3. 각 URL을 notion-fetch로 읽어 내용을 확보한다.
   • glossary_url → 용어 사전, 금지 표기
   • principle_url → 제품 원칙 5개 + 위반 플래그 포맷
4. 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회 추가 질문

1. Step 1(브레인스토밍)의 "문제 정의"와 Step 2(draft)의 "기획 배경"을 한 단락으로 합성한다.
2. 본문 작성 전 터미널에서 사용자에게 1회 질문한다:

   "이 문제가 비즈니스에 미치는 영향과 해결 시 가치는 무엇인가요?"

3. 답변을 받아 유저 문제와 비즈니스 임팩트를 한 단락으로 연결한다.

어떤 유저(대상)가 (어떤 상황)에서 (어떤 어려움)을 겪고 있다.
이 문제는 (비즈니스 영향)으로 이어지고 있으며, 해결 시 (비즈니스 가치)가 발생한다.

관련 데이터

🟡 추후 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는 파일 업로드를 지원하지 않으므로 아래 절차를 따른다:

1. 메타 테이블 작성 후, 사용자에게 파일 첨부를 요청한다:

   "화면 와이어프레임 섹션에 HTML 파일을 첨부해 주세요. Finder에서 파일을 열어 드렸습니다. Notion 페이지의 해당 섹션 하단에 드래그앤드롭 해주세요."

2. open -R 명령으로 Finder에서 wireframe HTML 파일을 선택된 상태로 연다.
3. notion-fetch로 페이지를 다시 로드하여 <file> 태그가 해당 섹션에 존재하는지 확인.
4. 파일이 확인되면 다음 단계로 진행. 확인되지 않으면 다시 요청.
5. plan-6 완료 메시지는 파일 첨부가 확인된 후에만 출력한다.

MVP 요구사항

🤖 우선순위 자동 부여 → 사용자 확인

1. Step 2 핵심 기능 목록을 그대로 옮긴다 (F-XXX ID 보존).
2. 각 기능이 가설 검증에 필수인지 LLM이 판단하여 우선순위를 부여:
   • must: 이 기능 없이는 가설을 테스트할 수 없음
   • should: 가설 검증을 보조하지만 없어도 기본 검증은 가능
   • could: 가설과 직접 관련 없으나 사용자 경험 보조
3. 결과를 터미널에 표로 보여주고 사용자에게 한 번 확인한다.
4. 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)

작성 절차:

1. principle_url 메모리에서 제품 원칙 5개를 fetch한다.
2. 기획 내용을 원칙과 대조하여 관련 있는 원칙만 본문에 발췌하고, 각 원칙별로 신규/변경 정책을 서술한다.
3. 섹션 끝에 원칙 5개 전체에 대한 검토 체크리스트를 한 줄로 표시한다 — 관련 원칙은 ✅ 적용, 무관한 원칙은 ✅ 무관.
4. 원칙 위반 의심 항목은 본 섹션에 적지 않고 "5. 유저 시나리오 → 미결 항목 / 원칙 위반 플래그"로 라우팅한다.

**원칙 #N ({원칙명})**
- 신규 정책: ({내용})
- 변경 정책: ({기존} → {변경})

**검토 체크리스트**
> 검토 완료: ✅ 원칙 #1 (무관) / ✅ 원칙 #2 (적용) / ✅ 원칙 #3 (무관) / ✅ 원칙 #4 (적용) / ✅ 원칙 #5 (무관)

7. 커뮤니케이션 계획

📋 5개 파트 체크박스 — 기획 성격에 따라 불필요한 파트 제거

기본값으로 5개 파트를 모두 체크박스로 나열한다. plan-6는 기획 내용(국내/해외/B2C/B2B 등)을 분석하여:

• 명백히 무관한 파트는 자동 제거 (예: 국내 전용 기능이면 일본/미국팀 라인 제거)
• 판단이 모호하면 모두 남겨둠

- [ ] **경영진** — 공유 시점:
- [ ] **운영실 (국내)** — 공유 시점:
- [ ] **운영실 (일본)** — 공유 시점:
- [ ] **미국팀** — 공유 시점:
- [ ] **마케팅 / 디자인** — 공유 시점:

8. 차후 계획

🤖 고도화 방향 자동 제안 → 사용자 확인

작성 절차:

1. 가설 + MVP 요구사항을 기반으로 LLM이 2~3개의 고도화 방향 후보를 제안한다.
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 검증 완료 후:

1. 기존 Notion 페이지의 내용을 모두 지우고 최종 기획서로 교체한다 (notion-update-page 사용).
2. 페이지 제목을 [기획서-Plan] {기획 주제} - {YYYY-MM-DD}로 변경한다.
3. 로컬 md 파일(.claude/docs/plan-{기획주제}.md)에 기획서 전문 + 프론트매터(Memory URL 계승)를 저장한다.
4. 화면 와이어프레임 섹션이 있는 경우, 사용자가 HTML 파일을 첨부했는지 notion-fetch로 확인한 후에만 완료 메시지를 출력한다.
5. 터미널에 Notion 링크와 로컬 파일 경로를 안내한다.

✅ 기획서 작성 완료 (Step 6/6)

[Plan] 기획서가 Notion에 저장되었습니다: {Notion URL} 로컬 파일: .claude/docs/plan-{기획주제}.md