idea2planning

name	idea2planning
description	Use when converting a rough idea, new feature request, or improvement into structured product documents. Triggers when user runs /idea2planning or wants to generate a 1-pager, PRD, or ASCII wireframe from an idea.

idea2planning

Overview

아이디어를 입력받아 1-pager, PRD, ASCII 와이어프레임을 단계적으로 생성하는 스킬. 대상: PM, PD 주니어~시니어 / 막연한 아이디어로도 시작 가능.

시작: Entry Menu

스킬 시작 시 반드시 아래 메뉴를 먼저 제시한다. 다른 행동을 먼저 하지 말 것:

무엇을 만들어볼까요?

1) 1-pager     — "이 제품이 왜 필요한가"를 한 장으로 정리한 요약 문서
                 (문제 · 솔루션 · 타겟 유저 · 기대 효과)

2) PRD         — "무엇을 어떻게 만들어야 하는가"를 정리한 요구사항 문서
                 (기능 정의 · 유저 시나리오 · 제약 조건)

3) 와이어프레임 — 텍스트로 그리는 화면 구조 스케치
                 (레이아웃 · 주요 UI 요소 배치)

4) 처음부터 차근차근 (1→2→3 순서로)

5) 잘 모르겠어요, 아이디어부터 설명할게요

언어 처리

사용자 입력 언어를 감지하여 동일 언어로 문서 생성.

• 한국어 입력 → 한국어 문서
• English input → English document

옵션 5: 아이디어 먼저

1. 사용자 아이디어를 자유롭게 입력받는다
2. 아이디어 내용을 분석한다
3. 최적 시작 단계를 추천하고 이유를 설명한다:
   • 막연한 아이디어만 있음 → 1번(1-pager)부터 추천
   • 이미 1-pager/요약 문서가 있음 → 2번(PRD)부터 추천
   • PRD 수준 스펙이 이미 있음 → 3번(와이어프레임)부터 추천
4. 추천 단계로 바로 진행한다

문서 저장

각 산출물 완성 후, 다음 단계 진행 여부를 묻기 전에 반드시 저장 여부를 먼저 확인한다.

저장 플로우

1. 완성 직후 저장 여부 질문:

   "파일로 저장할까요? (md / pdf / 건너뛰기)"

2. md 선택 시:

   • Write 도구로 직접 저장
   • 저장 경로: ~/Documents/idea2planning/outputs/ (기본값)
   • 파일명: 1pager_[제목요약]_[YYMMDD].md 형식

3. pdf 선택 시:

   • pandoc 설치 여부 확인: pandoc --version
   • 설치되어 있으면: pandoc [input.md] -o [output.pdf] 실행
   • 설치 안 되어 있으면: md로 저장 후 안내

     "pandoc이 설치되어 있지 않아 md 파일로 저장했어요. PDF로 변환하려면 터미널에서 brew install pandoc 후 재시도해주세요."

4. 건너뛰기 선택 시: 저장 없이 다음 단계로 진행

파일명 규칙

산출물	파일명 예시
1-pager	1pager_홈배너개선_260517.md
PRD	prd_홈배너개선_260517.md
와이어프레임	wireframe_홈배너개선_260517.md

단계 전환

각 산출물 완성 후 저장 여부 확인 → 다음 단계 진행 여부를 묻는다:

• 1-pager 완성 → 저장 확인 → "PRD 작성으로 넘어갈까요?"
• PRD 완성 → 저장 확인 → "ASCII 와이어프레임으로 넘어갈까요?"
• 와이어프레임 완성 → 저장 확인 → 종료
• Yes → 다음 단계 진행 / No → 종료

---

Stage 1: 1-pager 생성

참조 파일 읽기 (작성 전 필수)

references/ 폴더에서 아래 파일들을 읽어 스타일·어조·섹션 깊이·품질 기준을 파악한다:

• 1pager_understanding.md — 작성 원칙 및 개념
• 1pager_template.md — 구조 기준
• 1pager_example*.md — 존재하는 모든 예시 파일 (현재 개수에 관계없이 전부 읽을 것)

정보 수집

아이디어/문제가 충분히 파악되지 않은 경우 한 번에 하나씩 질문:

• 어떤 문제를 해결하려 하나요?
• 주요 타겟 사용자는 누구인가요?
• 관련 데이터나 현황 수치가 있나요? (없으면 정성 근거로 대체 가능)

문서 구조

아래 순서로 각 섹션에 실제 내용을 채워 작성한다:

# [YY.MM.DD] 제목 (팀/조직명)

## 1. 프로젝트 한 줄 요약
## 2. 대상
   | 대상 | 상황/특징 |
## 3. 문제 정의
   ### 고객 문제         — 불릿 리스트
   ### 비즈니스 문제      — 불릿 리스트
   ### 데이터 기반 현황   — 항목·수치·인사이트 테이블
   ### Root Cause      — Case 1, 2, 3...
## 4. 목표
   | 항목 | 목표 수치 |
## 5. 현황 및 분석      — VOC 인용, 인터뷰, 시장 동향
## 6. 해결방안          — Phase 1, Phase 2... 단위
## 7. 리스크
   | 영향도 | 리스크 | 대응 방안 |
## 8. 중요도 및 긴급도  — 상/중/하 + 이유

작성 원칙

• Why 중심 (당위성·근거 중심, 스펙 상세화 X)
• 숫자로 설명 (정량 우선, 없으면 정성 근거)
• 고객 문제 / 비즈니스 문제 반드시 분리
• 해결방안은 Phase 단위
• 리스크 반드시 포함

---

Stage 2: PRD 생성

참조 파일 읽기 (작성 전 필수)

references/ 폴더에서 아래 파일들을 읽어 스타일·어조·섹션 깊이·품질 기준을 파악한다:

• prd_understanding.md — 작성 원칙 및 개념
• prd_template.md — 구조 기준
• prd_example*.md — 존재하는 모든 예시 파일 (현재 개수에 관계없이 전부 읽을 것)

정보 수집

PRD 작성 전 아래 항목을 한 번에 하나씩 반드시 확인한다:

• 대상 사용자 세그먼트와 제외 대상은?
• 핵심 기능 우선순위는?
• 제외 범위(Out of Scope)는?
• 오픈 목표 일정이나 단계적 출시 계획이 있나요?
• 관련된 유관부서나 이해관계자가 있나요? (마케팅, 법무, 운영 등)
• 예외 처리가 필요한 특수 상황이 있나요? (예: API 실패, 데이터 부족, 특정 사용자 제외 등)

문서 구조

# [YY.MM.DD] 프로젝트명 (팀/조직명)
> 작성일 / 작성자 / 상태: Draft / 버전: v0.1

## 0. 문서 개요
   ### 0-1. 프로젝트 요약
   ### 0-2. 배경
      - 현재 상황
      - 문제 정의 + 데이터 현황 테이블
      - 사용자 Voice (인터뷰/VOC 인용)

## 1. 목표 (Goal)
   ### 1-1. 프로젝트 목표 (사용자 / 비즈니스 / 운영)
   ### 1-2. 성공 기준
      | 지표 | 현재 | 목표 |
      정성 목표

## 2. KPI 및 측정지표
   ### 2-1. 핵심 KPI
      | KPI명 | 정의 | 계산식 | 목표 | 측정 주기 | 측정 도구 |
   ### 2-2. 보조 지표
   ### 2-3. 모니터링 지표 (유입·탐색·퍼널·리텐션)

## 3. 사용자 및 이해관계자
   ### 3-1. 대상 사용자 + 제외 대상
   ### 3-2. 이해관계자
      | 조직 | 역할 |

## 4. 정책 정의
   ### 4-1. 기본 정책 (가입 조건·지역·이용 제한)
   ### 4-2. 상태값 정의
      | 상태 | 설명 |
   ### 4-3. 예외 정책
      | 상황 | 처리 |

## 5. 서비스 구조
   ### 5-1. 서비스 흐름 (텍스트 다이어그램)
   ### 5-2. 유저 플로우 (단계별 행동)
   ### 5-3. 주요 화면
      | 화면 | 목적 |

## 6. 상세 요구사항
   ### 6-1. 기능 요구사항
      | ID | 기능 | 설명 | 우선순위 |
   ### 6-2. 운영 요구사항
   ### 6-3. 데이터 요구사항
      | 항목 | 설명 |

## 7. UX/UI 고려사항 (UX 원칙 + 로딩/실패/빈 상태 처리)
## 8. 기술 고려사항 (구조·인증·캐시·성능 목표)
## 9. 실험 및 검증 (AB Test 계획 + 검증 방법)
## 10. 리스크 및 대응
    | 리스크 | 대응 |
## 11. 일정 및 운영계획
    | 단계 | 기간 |
## Appendix (용어 정의·변경 이력)

작성 원칙

• 애매한 표현 금지 → 구체적 조건·수치로
• 예외상황 정의 필수 (결제 실패·중복 요청·API timeout 등)
• KPI와 기능 연결 (이 기능이 어떤 지표를 개선하는지 명시)
• 상태값(State) 명확히 정의
• 개발자가 API/DB 설계 시작 가능한 수준까지 구체적으로

---

Stage 3: ASCII 와이어프레임 생성

참조 파일 읽기 (작성 전 필수)

references/ 폴더에서 아래 파일들을 읽어 스타일·구조·품질 기준을 파악한다:

• wireframe_understanding.md — 작성 원칙 및 개념
• wireframe_template.md — 구조 기준 및 Type A/B/C 형식
• wireframe_example*.md — 존재하는 모든 예시 파일 (없으면 생략)

핵심 원칙

정답 1개가 아닌 **최소 3가지 방향(Type A/B/C)**을 동시에 제안한다. 각 안의 정보 구조·CTA 방식·인터랙션 방향이 명확히 달라야 한다.

정보 수집

필요 시 한 번에 하나씩 질문:

• 어떤 화면(들)을 그릴까요?
• 핵심 CTA는 무엇인가요?
• 모바일/웹 중 어느 플랫폼 기준인가요? (기본값: 모바일)

출력 형식

각 화면에 대해 아래 구조로 작성:

# 화면명

## 화면 목적     — 단일 핵심 목적 (탐색·구매·가입·리텐션 등)
## 공통 요구사항 — 반드시 포함할 기능·정책·운영 요소

## Type A — 현실적인 안
컨셉: 현재 구조 기반, 빠른 적용, 운영 안정성 높음
핵심 UX 방향: 익숙한 패턴 / CTA 명확화 / 탐색 효율 강화

Wireframe:
┌─────────────────────┐
│ ...실제 내용...      │
└─────────────────────┘

특징 / 장점 / 단점

## Type B — 디자인 강조안
컨셉: 브랜드 몰입감·비주얼 중심
핵심 UX 방향: 대형 비주얼 / 스크롤 몰입 / 감성 중심

Wireframe: ...

특징 / 장점 / 단점

## Type C — 실험적/미래형 안
컨셉: AI·자동화·실시간 개인화 중심
핵심 UX 방향: AI 인터랙션 / 동적 UI / 상황 기반 변화

Wireframe: ...

특징 / 장점 / 단점

추가 권장 항목 (필요 시):

• 상태 정의: Default / Loading / Empty / Error / Disabled
• 인터랙션 설명: 등장 애니메이션·스크롤 변화·Sticky 동작

작성 원칙

• 디자인보다 구조에 집중 (레이아웃·정보 우선순위·CTA 위치)
• 실제 서비스처럼 (실제 카드 개수·콘텐츠 길이·에러 상황 고려)
• 한 화면에 핵심 목적 하나
• 3가지 안의 차이 명확히 (정보 구조·CTA 방식·인터랙션 방향)
• 모바일 기준 우선 작성