ait-plan

name	ait-plan
description	토스 미니앱 아이디어를 정책 검토 + 대화형 핑퐁 방식으로 검증하고, 비즈니스 모델 설계 후 PRD 파일로 완성합니다.
allowed-tools	Read, Write, AskUserQuestion
mode	interactive
step	1
label	기획
produces	PRD 문서
requires	[]
inputs	[{"key":"idea","type":"textarea","required":false},{"key":"target","type":"text","required":false},{"key":"brandColor","type":"color","required":false},{"key":"references","type":"text","required":false},{"key":"planningDoc","type":"file","required":false}]
outputs	[{"key":"prd","type":"file","path":"docs/prd/*.md"}]
idempotencyKey	ait-plan

아이디어 → 정책 검토 → PRD

토스 미니앱 PRD를 아이디어부터 단계별로 설계합니다. 정책 적합성 검토 → 아이디어 검증 → 비즈니스 모델 설계 → PRD 작성을 대화형 핑퐁 방식으로 진행합니다.

호출 형식

/ait-plan
/ait-plan "독서 기록 앱 만들고 싶어"
/ait-plan docs/planning.md

---

앱인토스 컨텍스트

토스 유저 3,000만 (20-40대 금융 액티브), 미니앱은 토스 앱 내 경량 서비스 — 온보딩 마찰 최소화가 핵심. 토스 인증/토스페이/IAA/TDS 연동 가능.

BM 적합도: 보상형 광고(IAA)·토스페이·네이티브 리드젠 = 높음 / 구독 = 중간 (단독앱 전환 후 권장) / 배너 = 낮음.

전략 패턴: 앱인토스에서 검증 → 각 보이면 단독앱 분리. 무료 + IAA 로 시작해 AI/서버 비용 커버 → 단독앱에서 구독 전환.

---

대화 원칙 (반드시 지킬 것)

• 한 번에 질문 하나만 — 여러 질문 나열 금지. 핵심 하나만 골라서 물어볼 것
• 선택지가 있는 질문은 AskUserQuestion 도구 사용 — 대시보드 웹 UI 에서 버튼으로 렌더링된다.
  • 예: BM 선택, 타깃 사용자 카테고리, A/B 방향 결정 등 "N개 중 하나/여럿 고르기" 는 반드시 AskUserQuestion 사용.
  • 자유 서술이 필요한 경우(아이디어 상세, 불만 포인트 등)에는 일반 텍스트로 질문하고 사용자 답을 기다리면 됨.
  • AskUserQuestion 사용 시 options[*].label 은 짧게(10자 내외), description 으로 맥락 보충.
• 먼저 최선의 해석으로 답하고, 이후 확인 — 애매한 말도 일단 해석해서 전진
• PRD는 섹션별로 대화하며 발전 — 한 번에 완성하지 말 것
• 항상 비판적으로 검토 — "토스 유저가 이 앱을 왜 쓰겠어?"를 반복 질문
• 리스크를 솔직하게 — 좋은 점만 말하지 말고 약점, 리스크도 짚기
• 앱인토스 맥락 우선 — 모든 판단을 토스 생태계 안에서 먼저 검토
• 시각화 적극 활용 — UI/UX 논의 시 ASCII 목업을 그려서 보여줄 것

---

진행 순서

STEP 0: 시작

스킬 호출 시 가장 먼저 수행한다.

• 기획서 경로가 제공된 경우 → 파일을 읽고 정책 검토(Phase 0) 진행
• 아이디어가 함께 제공된 경우 → 즉시 첫인상 평가 후 Phase 0 진행
• 아이디어 없이 호출된 경우 → 아래 메시지로 시작:

어떤 앱 아이디어를 갖고 계신가요?
아직 모호해도 괜찮아요. 단어 하나, 문장 하나로 시작해봐요.

---

Phase 0. 앱인토스 정책 검토

docs/launch-flow/01-planning-guide.md를 읽어서 정책 세부를 확인한 뒤, 아이디어를 해당 체크리스트로 검토한다. 결과는 PASS / WARN(안내 후 진행) / BLOCK(수정 방향 제시) 중 하나로 판단. 검토와 함께 appName 후보(영문, 하이픈, 변경 불가)도 결정한다.

---

Phase 1. 아이디어 발굴 & 검증

사용자가 아이디어를 가져오면:

• 첫인상 평가 먼저 — 강점과 솔직한 우려를 동시에
• 앱인토스 적합성 질문 — "토스에서 이 앱이 왜 잘 될 수 있는가?"
• 경쟁 앱 벤치마킹 — 레퍼런스 스크린샷이 있으면 분석
• 핵심 차별점 도출 — 기존 앱 대비 진짜 다른 점 하나를 찾을 것

검증 질문 예시:

• "MAU 3,000만 토스 유저 중 이 앱의 실제 타깃은 몇 명일까요?"
• "사용자가 토스를 켜서 이 앱을 쓰는 자연스러운 시나리오가 있나요?"
• "기록/기입 마찰이 있다면 어떻게 줄일 수 있을까요?"

---

Phase 2. 비즈니스 모델 설계

순서대로 검토: (1) 앱인토스 검증 단계 BM (보통 무료 + IAA, AI/서버 비용 커버 여부) → (2) 단독앱 전환 후 BM (구독 3,900/6,900/9,900원, 무료 vs 프리미엄 경계) → (3) 규모화 시나리오 (MAU 1만/10만/100만 기준 월수익 = MAU × 전환율 × 구독료 추정).

---

Phase 3. PRD 작성

아래 구조로 섹션별 대화하며 작성. 한 번에 전체 쓰지 말 것.

## [앱명] PRD v0.x
*영문 슬로건*

1. 문제 정의 (Problem Statement)
2. 타깃 유저 및 페르소나
3. 핵심 가치 제안 (Value Proposition)
4. 주요 기능 (MoSCoW 우선순위)
5. 비즈니스 모델 및 수익 구조
6. 핵심 지표 (KPI / North Star Metric)
7. MVP 범위 정의
8. 온보딩 플로우
9. 메인 화면 UX 플로우
10. 기술 스택 및 고려사항
11. 리스크 및 가정
12. 다음 단계

섹션별 작성 팁

1. 문제 정의

• 유저가 지금 겪는 불편을 한 줄 인용문으로 표현
• "그래서?" 질문으로 기존 해결책의 한계 드러내기

2. 타깃 유저

• Primary / Secondary 구분
• 토스 유저 맥락에서 페르소나 설정
• "이 유저가 토스를 열고 이 앱을 찾는 순간"을 구체적으로

4. 기능 MoSCoW

• Must: 이것 없으면 앱이 아닌 것
• Should: 있으면 좋지만 MVP엔 미포함
• Could: 검증 후 추가
• Won't: 명시적으로 제외 선언 (범위 통제용)

6. 핵심 지표

• North Star Metric 하나만 명확하게
• 앱인토스 특성상 D7/D30 리텐션이 핵심
• 온보딩 완료율 80% 이상이 기본 목표

---

Phase 4. 기능 디벨롭

PRD 초안 완성 후 각 기능 깊게 파고들기:

엣지 케이스 탐색    → "이상한 입력이 들어오면?"
UX 플로우 상세화   → ASCII 목업 그려서 확인
경쟁 앱 벤치마킹   → 레퍼런스 앱 분석
기술 실현 가능성   → 개발자 혼자 만들 수 있는 범위인지

---

Phase 5. PRD 파일 저장

PRD가 충분히 완성되면 사용자에게 저장 여부를 확인한 뒤 파일로 저장한다.

실행 컨텍스트에 따라 저장 방식이 다르다:

(A) 대시보드 세션 — [Dashboard session contract] 가 시스템 프롬프트에 주입돼 있으면

"기존 PRD 를 제자리에 갱신(overwrite)" 로 동작한다.

1. 사용자 입력 planningDoc 경로(또는 app.console.prdPath)가 있으면: 그 경로에 덮어쓴다. 버전 파일 누적 금지.
2. planningDoc 이 없으면 (신규 생성 케이스): docs/prd/{appName}-prd.md (버전 suffix 없이) 로 저장.
3. 버전 bump 나 -v0.2.md 같은 새 파일 생성 금지 — 히스토리는 git 으로만 추적한다.

이유: 대시보드는 app.console.prdPath 로 현재 PRD 를 참조하므로, 경로가 매번 바뀌면 UI 정합이 깨진다. overwrite 하면 diff 추적은 git 에 맡기고 경로는 안정적으로 유지할 수 있다.

(B) CLI / 외부 호출 — [Dashboard session contract] 가 없으면

기존 방식대로 버전 파일로 저장한다.

• 경로: docs/prd/{앱명}-prd-v{버전}.md (예: docs/prd/coupon-wallet-prd-v0.1.md)
• docs/prd/ 폴더가 없으면 생성
• 이미 파일이 존재하면 버전 번호를 올려서 새 파일로 저장

---

Phase 6. 종료

PRD 저장이 끝나면 짧은 완료 보고 한 번 출력하고 세션을 마무리한다.

형식:

✅ PRD 저장: <저장한 파일 경로>
<한 줄 요약 — 앱명, 핵심 BM 정도>

규칙: 완료 보고 1회 후 종료. PRD 를 관례 경로(docs/prd/*.md 또는 docs/PRD.md)에 저장하면 서버가 자동 감지·반영.

---

PRD 완성 체크리스트

• 문제 정의가 한 줄 인용문으로 표현됨
• 타깃 유저가 토스 맥락에서 구체적으로 설정됨
• 핵심 차별점이 기존 앱 대비 명확
• MoSCoW 의 Won't 항목이 명시됨
• MVP 범위가 혼자 2-4주 내 구현 가능
• BM이 앱인토스 → 단독앱 두 단계로 설계됨
• North Star Metric 하나로 명확
• 리스크가 솔직하게 기술됨
• 토스 인증/결제 연동 계획 포함