plan

name	plan
description	기획 단계 AI 협업 — 19단계 서비스 기획 워크플로우 (MVP정의 → 고객분석 → 시장조사 → 고객경험 → 문제가설 → 솔루션 → 비즈니스모델 → 이벤트스토밍 → PRD → 유저스토리 → UI/UX → 프로토타입 → 플로우 스크립트)
type	orchestrator
user-invocable	true

Plan

[NPD Plan 활성화]

목표

PO·서비스기획자·도메인전문가·아키텍트·AI엔지니어가 협업하여 6단계 19스텝의 완전한 서비스 기획을 수행함. MVP 정의부터 프로토타입까지 체계적으로 산출물을 생성하며, 각 단계의 산출물이 다음 단계의 컨텍스트로 누적 연결됨.

활성화 조건

사용자가 /npd:plan 호출 시 또는 "기획 시작", "기획해줘", "서비스 기획" 키워드 감지 시.

주의사항: 중간 단계부터 시작할 때도 각 단계별 승인 여부를 선택하는 Phase 0은 항상 수행하여 진행 모드를 설정해야 합니다.

선행 조건

• /npd:create 완료 (프로젝트 디렉토리 및 AGENTS.md 존재)

작업 환경 변수 로드

AGENTS.md 파일에서 ## 환경변수 섹션의 환경변수 로딩. 로딩 실패 시 사용자에게 /npd:create를 먼저 수행하라고 안내하고 종료.

에이전트 호출 규칙

에이전트	FQN
product-owner	npd:product-owner:product-owner
service-planner	npd:service-planner:service-planner
architect	npd:architect:architect
ai-engineer	npd:ai-engineer:ai-engineer
domain-expert	npd:domain-expert:domain-expert
backend-developer	npd:backend-developer:backend-developer
frontend-developer	npd:frontend-developer:frontend-developer
qa-engineer	npd:qa-engineer:qa-engineer
devops-engineer	npd:devops-engineer:devops-engineer

프롬프트 조립

• {NPD_PLUGIN_DIR}/resources/guides/combine-prompt.md에 따라 AGENT.md + agentcard.yaml + tools.yaml 합치기
• Agent(subagent_type=FQN, model=tier_mapping 결과, prompt=조립된 프롬프트) 호출
• tier → 모델 매핑은 {NPD_PLUGIN_DIR}/gateway/runtime-mapping.yaml 참조

서브 에이전트 호출

워크플로우 단계에 Agent: {agent-name}이 명시된 경우, 메인 에이전트는 해당 단계를 직접 수행하지 않고, {NPD_PLUGIN_DIR}/resources/guides/call-subagent.md에 따라 서브 에이젼트 호출

진행상황 업데이트 및 재개

{PROJECT_DIR}/AGENTS.md에 각 Phase의 Step 완료 시 저장. 최종 완료 시 Done으로 표기.

## 워크플로우 진행상황
### plan
- 진행 모드: {선택값}
- 마지막 완료 Phase/Step: Phase 1/Step 0

{PROJECT_DIR}/AGENTS.md의 ## 워크플로우 진행상황 > ### plan에 진행상황 정보가 있는 경우 마지막 완료 Step 이후부터 자동 재개.

산출물 작성 지침

• 기획 산출물은 IT용어 사용 금지
• 기획 산출물은 최대한 쉬운 용어로 작성. 필요 시 비유와 예시 사용
• 기획 산출물은 전문용어 사용 시 반드시 쉬운 설명 추가
• 기획 산출물에 약어 사용 시 풀네임과 설명 추가

워크플로우

개요

1단계: 정의 (MVP정의 + 고객분석 + 시장조사)
   ↓
2단계: 문제 발견 (고객경험단계 + 고객경험조사 + 여정맵 + 문제가설 + 방향성)
   ↓
3단계: 솔루션 (아이디어발상 + 솔루션선정)
   ↓
4단계: 비즈니스 모델 (비즈니스모델 + 발표자료)
   ↓
5단계: 제품 설계 (이벤트스토밍 + PRD + 유저스토리 + UI/UX설계)
   ↓
6단계: 프로토타입 + 플로우 스크립트

Phase 0: 진행 모드 선택

기획 워크플로우 시작 전, 각 단계별 승인 여부를 선택합니다.

{"title":"진행 모드 선택","questions":[ {"question":"각 단계 완료 후 승인을 받고 진행할까요, 자동으로 진행할까요?","type":"radio","options":["단계별 승인","자동 진행"]} ]}

• 단계별 승인 선택 시 → 각 스텝 완료 후 아래 ASK_USER로 승인 요청을 표시하고 응답에 따라 분기:
  • 승인 → 다음 스텝 진행
  • 재작업 요청 → 사용자 피드백을 받아 현재 스텝 재수행
  • 중단 → 현재까지 산출물 보존 후 스킬 종료
• 자동 진행 선택 시 → 승인 없이 연속 실행

승인 요청 ASK_USER 형식:

{"title":"단계 승인","questions":[ {"question":"{완료된 스텝명} 단계가 완료되었습니다. 결과 파일({생성된 파일 경로})을 검토하고 {다음 스텝명} 단계로 계속 진행할 지 승인해 주십시오.","type":"radio","options":["승인","재작업 요청","중단"]} ]}

• (중요) 자동 진행 시 사용자에게 진행에 필요한 정보를 한꺼번에 요청. AskUserQuestion 사용하지 않고 대화창으로 질문

Phase 1: 정의 (Define)

Step 1. MVP 주제 정의 → Agent: product-owner

• PREV_ACTION:
  • 참고 정보를 사용자에게 문의
  {"title":"참고정보 요청","questions":[ {"question":"MVP 주제를 정의하기 위해 참고할 정보가 있으면 파일 경로를 입력하세요.
  없으면 없음이라고 입력하세요.","type":"text"}
  • 참고정보 파일 입력 시 내용을 요약하여 에이젼트 product-owner에 전달
• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/01-mvp-definition-guide.md
• TASK: AGENTS.md의 MVP 비즈니스 도메인을 기반으로 MVP 후보를 시장 잠재력·사용자 pain points·실현 가능성·경쟁 우위 4가지 팩터로 평가하여 최종 MVP 주제를 확정
• EXPECTED OUTCOME: docs/plan/define/MVP정의.md — MVP 주제 정의, 선정 이유(4가지 팩터 평가표), 목표 비즈니스 도메인
• POST-ACTION:
  • 사용자에게 MVP후보와 추천 주제를 제공하고 사용자에게 선택 시킴. AskUserQuestion을 사용하지 말고 화면에 선택지를 표시. 선택한 주제에 대해 아래 수행
  • 사용자가 선택한 주제로 docs/plan/define/MVP정의.md 파일 업데이트
  • 프로젝트 AGENTS.md의 ## 목표 섹션에 확정된 MVP 주제에 기반하여 팀 목표를 기술
  • 프로젝트 AGENTS.md의 ## MVP > MVP 주제 섹션에 확정된 MVP 주제를 기술
  • {NPD_PLUGIN_DIR}/resources/guides/plan/domain-context-guide.md의 가이드에 따라 {PROJECT_DIR}/.npd/domain-context.yaml에 도메인 특화 정보 생성
  • 프로젝트 AGENTS.md의 멤버 중 domain-expert의 성향과 경력을 {PROJECT_DIR}/.npd/domain-context.yaml을 참고하여 재작성
  • 프로젝트 AGENTS.md의 '클로니'의 책임과 경력을 MVP 주제와 관련된 책임과 경력으로 재작성
  • 프로젝트 AGENTS.md의 팀원을 MVP 주제와 관련된 팀원으로 재작성
  • {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

Step 2. 고객 분석 → Agent: service-planner

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/02-customer-analysis-guide.md
• TASK: JTBD 프레임워크로 타겟 고객 유형을 정의하고 사용자 세그먼트(3-5개)별 인구통계·행동 패턴·현재 상황, 주요 Job과 원하는 결과를 도출
• EXPECTED OUTCOME: docs/plan/define/고객분석.md — 타겟 고객 유형(JTBD 형식), 사용자 세그먼트 3-5개, Job to be Done
• POST-ACTION:
  • 프로젝트 AGENTS.md의 ## MVP 주제 섹션 다음에 ## 고객유형 섹션을 추가하고, 선정된 고객유형과 최우선 고객 세그먼트를 기록
  • {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

Step 3. 시장 조사 → Agent: domain-expert

도메인 컨텍스트 주입: domain-expert 호출 시 프로젝트의 {PROJECT_DIR}/.npd/domain-context.yaml을 읽어 프롬프트에 포함하여 도메인 특화 자문을 수행합니다.

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/03-market-research-guide.md
• TASK: MVP 주제와 타겟 고객에 대해 시장 규모(TAM/SAM/SOM), 경쟁 환경(3-5개 경쟁사), 고객 트렌드, 규제 환경, SWOT 분석, 시장 진입 전략을 포함한 철저한 시장 조사를 수행
• EXPECTED OUTCOME: docs/plan/define/시장조사.md — 시장 규모·성장, 경쟁 환경, 고객 트렌드, 규제 환경, SWOT, 시장 진입 전략
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

---

Phase 2: 문제 발견 및 방향성 (Discover)

Step 1. 고객경험 단계 정의 → Agent: service-planner

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/04-customer-journey-stages-guide.md
• TASK: MVP 주제와 고객유형을 기반으로 현재 고객이 겪는 경험 단계(5-7개)를 문제 인식부터 해결/관리까지 순차적으로 정의
• EXPECTED OUTCOME: docs/plan/define/고객경험단계.md — 고객경험 단계(화살표 연결), 단계별 설명(주요 행동·긍정/부정 느낌·Pain Points), 단계 도출 근거
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

Step 2. 고객 경험 조사 → Agent: service-planner × 3 병렬

조사 규모 설정: Step 2 시작 전, 고객 경험 조사의 규모를 사용자로부터 입력받습니다.

{"title":"고객 경험 조사 규모 설정","questions":[ {"question":"고객경험 인터뷰 대상자 수를 입력해 주세요. (기본값: 5명)","type":"text","placeholder":"5"}, {"question":"관찰 조사 횟수를 입력해 주세요. (기본값: 5회)","type":"text","placeholder":"5"}, {"question":"체험 테스트 횟수를 입력해 주세요. (기본값: 5회)","type":"text","placeholder":"5"} ]}

사용자가 입력한 값을 각각 {인터뷰수}, {관찰수}, {체험수}로 사용합니다. 미입력 시 기본값 5를 적용합니다.

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/05-customer-experience-guide.md
• 실행 방식: 3가지 조사를 서브에이전트로 병렬 수행한 후, 인터뷰 결과 취합을 순차 수행합니다.

Step 2-1. 관찰 조사 (병렬) → Agent: service-planner

• TASK: 고객경험 단계를 기준으로 {관찰수}회의 관찰 조사를 수행하여 고객 행동 데이터를 생성
• EXPECTED OUTCOME: docs/plan/define/관찰결과.md — 관찰 {관찰수}회 결과(고객경험 단계별 관찰 행동·어려움·Pain Point·니즈·행동 패턴)

Step 2-2. 체험 조사 (병렬) → Agent: service-planner

• TASK: 고객경험 단계를 기준으로 {체험수}회의 체험 테스트를 수행하여 사용자 경험 데이터를 생성
• EXPECTED OUTCOME: docs/plan/define/체험결과.md — 체험 {체험수}회 결과(고객경험 단계별 경험 내용·긍정/부정 측면·만족도)

Step 2-3. 고객경험 인터뷰 (병렬) → Agent: service-planner

• TASK: 고객경험 단계를 기준으로 {인터뷰수}명 대상 심층 인터뷰를 수행하여 개별 인터뷰 결과를 생성
• EXPECTED OUTCOME: docs/plan/define/고객경험인터뷰결과.md — 인터뷰 {인터뷰수}명 개별 결과(고객경험 단계별 행동·생각·긍정적/부정적 느낌)

Step 2-4. 인터뷰 결과 취합 (2-D 완료 후 순차) → Agent: service-planner

• TASK: Step 2-3에서 생성된 개별 인터뷰 결과를 종합 분석하여 핵심 인사이트를 도출
• EXPECTED OUTCOME: docs/plan/define/고객경험인터뷰결과취합.md — 인터뷰 종합 분석(핵심 인사이트·Pain Points·Needs·기대 가치)
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

실행 지침: Step 2-1, 2-2, 2-3을 Agent(run_in_background=true)로 동시에 실행합니다. 3개 모두 완료되면 2-D를 순차 실행합니다. 모든 서브스텝이 완료되어야 Step 2 완료로 간주합니다.

Step 3. 고객 여정 맵 작성 → Agent: service-planner

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/06-journey-mapping-guide.md
• TASK: 고객경험 단계를 X축으로, 경험 조사 데이터를 기반으로 페르소나 정의·단계별 행동/생각/감정/터치포인트/Pain Points/Gain Points·감정 곡선·핵심 인사이트·기회 영역이 포함된 User Journey Map을 작성
• EXPECTED OUTCOME: docs/plan/define/유저저니맵.md — 페르소나·여정 맵 상세·감정 곡선·핵심 인사이트·기회 영역 / docs/plan/define/유저저니맵.svg — 시각화된 여정 맵
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

Step 4. 문제 가설 정의 → 전체 팀 협업 (발산-수렴-선택 패턴)

도메인 컨텍스트 주입: domain-expert 호출 시 프로젝트의 {PROJECT_DIR}/.npd/domain-context.yaml을 읽어 프롬프트에 포함합니다.

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/07-problem-hypothesis-guide.md
• 실행 방식: 5개 서브스텝을 순차/병렬 조합으로 수행합니다.

Step 4-1. 문제가설 정의 (발산-수렴-선택)

4-1a. 발산 — 5WHY 수행 (병렬) → Agent: product-owner, service-planner, domain-expert, architect, ai-engineer

• TASK: 각 팀원이 자신의 전문 관점에서 현상문제 3개를 도출하고 각각 5WHY로 근본원인을 분석
• EXPECTED OUTCOME: 팀원별 5WHY 분석 결과 (팀원당 문제 3개 × 5WHY)
• CONTEXT: docs/plan/define/고객분석.md, docs/plan/define/유저저니맵.md, 고객 경험 조사 데이터 전체
• 실행: 5개 에이전트를 Agent(run_in_background=true)로 동시 실행

4-1b. 수렴 — 유사 항목 합치기 (순차) → Agent: service-planner

• TASK: 4-1a에서 도출된 5명의 5WHY 결과를 취합하고 유사한 문제와 근본원인을 그룹핑하여 다층적 근본원인 관점으로 재구조화
• EXPECTED OUTCOME: 수렴된 문제가설 후보 목록 (그룹핑된 문제 + 근본원인 + 출처 팀원 표기)
• CONTEXT: 4-1a 결과

4-1c. 선택 — 최종 문제가설 확정 (순차) → Agent: product-owner

• TASK: 수렴된 후보 중 핵심 문제 3개와 근본원인을 영향력·빈도·심각도 관점에서 선정하여 최종 문제가설로 확정
• EXPECTED OUTCOME: docs/plan/define/문제가설.md — 문제 3개, 5WHY 분석, 다층적 근본원인 검토, 핵심 근본원인 선정
• CONTEXT: 4-1b 결과

Step 4-2. 문제 검증 인터뷰 (병렬) → Agent: product-owner, service-planner, domain-expert, architect, ai-engineer

인터뷰 규모 설정: Step 4-2 시작 전, 문제검증 인터뷰 대상자 수를 사용자로부터 입력받습니다.

{"title":"문제검증 인터뷰 규모 설정","questions":[ {"question":"문제검증 인터뷰 대상자 수를 입력해 주세요. (기본값: 5명)","type":"text","placeholder":"5"} ]}

사용자가 입력한 값을 {문제검증인터뷰수}로 사용합니다. 미입력 시 기본값 5를 적용합니다.

• TASK: 확정된 문제가설을 기반으로 {문제검증인터뷰수}명 대상 문제검증 인터뷰를 에이전트 5명이 분담하여 병렬 수행
• EXPECTED OUTCOME: docs/plan/define/문제검증인터뷰결과.md — {문제검증인터뷰수}명 개별 인터뷰 결과(중요도·불편도·근본원인 동의여부)
• 실행: 5개 에이전트를 Agent(run_in_background=true)로 동시 실행, 각 에이전트가 분담된 인터뷰 수만큼 수행 후 결과를 하나의 파일로 병합

Step 4-3. 인터뷰 결과 취합 (순차) → Agent: service-planner

• TASK: 수집된 전체 인터뷰 결과를 종합 분석하여 문제별 중요도/불편도 평균, 근본원인 동의율, 핵심 인사이트를 도출
• EXPECTED OUTCOME: docs/plan/define/문제검증인터뷰결과취합.md — 인터뷰 결과 종합 취합(문제별 통계·근본원인 검증·핵심 인사이트)

Step 4-4. 문제가설 피보팅 (순차) → Agent: product-owner

• TASK: 인터뷰 결과 취합을 반영하여 중요도/불편도가 낮거나 동의율이 낮은 항목을 조정하고 새로 발견된 문제를 반영하여 문제가설을 수정
• EXPECTED OUTCOME: docs/plan/define/문제가설.md — 피보팅된 문제가설(기존 파일 덮어쓰기), 변경 사항과 피보팅 근거를 파일 상단에 명시

Step 4-5. 비즈니스 가치 도출 (발산-수렴-선택)

4-5a. 발산 — 가치 도출 (병렬) → Agent: product-owner, service-planner, domain-expert, architect, ai-engineer

• TASK: 피보팅된 문제가설의 근본원인 해소 시 고객·회사 각각의 비즈니스 가치를 자신의 전문 관점에서 도출
• EXPECTED OUTCOME: 팀원별 비즈니스 가치 후보 (고객 측면 + 회사 측면)
• CONTEXT: docs/plan/define/문제가설.md (피보팅 버전), docs/plan/define/문제검증인터뷰결과취합.md
• 실행: 5개 에이전트를 Agent(run_in_background=true)로 동시 실행

4-5b. 수렴 — 유사 항목 합치기 (순차) → Agent: service-planner

• TASK: 5명의 비즈니스 가치 후보를 취합하고 유사한 가치를 그룹핑하여 정리
• EXPECTED OUTCOME: 수렴된 비즈니스 가치 후보 목록 (고객 측면 + 회사 측면, 출처 팀원 표기)
• CONTEXT: 4-5a 결과

4-5c. 선택 — 최종 비즈니스 가치 확정 (순차) → Agent: product-owner

• TASK: 수렴된 후보 중 고객·회사 각각 가장 중요한 비즈니스 가치 3개 이하를 측정 가능한 지표와 연결하여 선정
• EXPECTED OUTCOME: docs/plan/define/비즈니스가치.md — 고객/회사 측면 비즈니스 가치(각 3개 이하, 선정 근거 포함)
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

전체 산출물: 문제가설.md (피보팅 최종본), 문제검증인터뷰결과.md, 문제검증인터뷰결과취합.md, 비즈니스가치.md

Step 5. 방향성 정의 → Agent: product-owner

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/08-direction-setting-guide.md
• TASK: 검증된 문제들을 영향력·빈도·심각도·근본성·해결가능성 5가지 기준으로 평가하여 킹핀 문제를 선정하고, '<고객유형>는 <목적>을 위하여 <원하는 것>이 필요하다.' 형식의 Needs Statement로 방향성을 정의
• EXPECTED OUTCOME: docs/plan/think/킹핀문제.md — 검증된 문제 리스트·인과관계·5가지 기준 평가·킹핀 문제 선정 / docs/plan/think/문제해결방향성.md — Needs Statement·상세 설명(고객유형·목적·원하는 것)
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

---

Phase 3: 솔루션 (Solution)

Step 1. 아이디어 발상 → Agent: product-owner, service-planner(리드), domain-expert, architect, ai-engineer, backend-developer, frontend-developer, qa-engineer, devops-engineer

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/09-ideation-guide.md
• TASK: 모든 팀원(9명)이 SCAMPER·Steal & Synthesize 기법으로 각자 Big Idea 3개, Little Win Idea 2개, Crazy Idea 1개를 도출(병렬)한 후, service-planner가 유사도 평가표(기능 70%/경험 30%)를 작성하여 유사도 0.7 이상 아이디어를 합쳐 솔루션 후보를 수렴
• EXPECTED OUTCOME: docs/plan/think/솔루션탐색.md — 팀원별 아이디어 표 / docs/plan/think/솔루션후보.md — 수렴된 솔루션 후보(각 후보 상세 설명)
• 실행: 솔루션 탐색은 9개 에이전트를 Agent(run_in_background=true)로 동시 실행, 솔루션 수렴은 service-planner가 순차 수행
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

Step 2. 솔루션 선정 → Agent: product-owner(리드), service-planner, domain-expert, architect, ai-engineer, backend-developer, frontend-developer, qa-engineer, devops-engineer

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/10-solution-selection-guide.md
• TASK: 모든 팀원(9명)이 비즈니스 가치(B) 3표·실현 가능성(F) 3표를 투표(병렬)한 후, product-owner가 결과를 집계하고 X축=실현가능성/Y축=비즈니스 영향도의 2x2 매트릭스로 시각화하여 핵심 솔루션 3개 이하를 선정
• EXPECTED OUTCOME: docs/plan/think/솔루션평가.md — 투표 결과 집계표 / docs/plan/think/솔루션우선순위평가.svg — 우선순위 매트릭스 SVG / docs/plan/think/핵심솔루션.md — 선정된 핵심 솔루션(3개 이하, 상세 설명)
• 실행: 투표는 9개 에이전트를 Agent(run_in_background=true)로 동시 실행, 집계 및 선정은 product-owner가 순차 수행
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

---

Phase 4: 비즈니스 모델 (Business Model)

Step 1. 비즈니스 모델 설계 → Agent: product-owner

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/11-business-modeling-guide.md
• TASK: Lean Canvas 프레임워크로 9개 영역(Problem·Customer Segments·UVP·Solution·Channels·Revenue Streams·Cost Structure·Key Metrics·Unfair Advantage)과 경쟁 분석·GTM 전략·3개년 재무 계획(손익계산서·BEP)을 포함한 비즈니스 모델을 설계
• EXPECTED OUTCOME: docs/plan/think/비즈니스모델.md — Lean Canvas 9영역 전체·가격 전략·수익 전망·비용 구조·Key Metrics·경쟁 매트릭스·GTM 전략·재무 계획
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

Step 2. 발표자료 스크립트 → Agent: service-planner

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/12-presentation-guide.md
• TASK: 비즈니스 모델을 기반으로 린캔버스 9영역·경쟁 분석·GTM 전략·재무 계획을 10-15장으로 구성하고 장표별 핵심 메시지 3개 이하·비주얼 제안을 포함한 발표자료 스크립트를 작성
• EXPECTED OUTCOME: docs/plan/think/서비스기획서스크립트.md — 10-15장 슬라이드 스크립트(각 장표 핵심 메시지 3개 이하, 장표 간 --- 구분, 비주얼 제안 포함)
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

---

Phase 5: 제품 설계 (Product Design)

Step 1. 이벤트 스토밍 → Agent: architect(리드), product-owner, service-planner, domain-expert, ai-engineer, backend-developer, frontend-developer, qa-engineer, devops-engineer

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/13-event-storming-guide.md
• 실행 방식: 3단계(초안-리뷰-반영)로 수행합니다.

Step 1-1. 초안 작성 (순차) → Agent: architect

• TASK: DDD Event Storming 기법으로 핵심 솔루션의 시스템 이벤트 흐름을 분석하고, 주요 유저플로우 식별·연결도·시퀀스 다이어그램·마이크로서비스 정의를 PlantUML로 작성
• EXPECTED OUTCOME: docs/plan/think/es/userflow.puml — 유저플로우 연결도 / docs/plan/think/es/{순번}-{유저플로우명}.puml — 각 유저플로우 시퀀스 다이어그램

Step 1-2. 팀 리뷰 (병렬) → Agent: product-owner, service-planner, domain-expert, ai-engineer, backend-developer, frontend-developer, qa-engineer, devops-engineer

• TASK: Step 1-1에서 작성된 이벤트 스토밍 초안을 각자의 전문성 관점에서 리뷰하고 의견을 제시
  • product-owner: 비즈니스 가치·MVP 범위 관점에서 누락된 유저플로우나 이벤트 확인
  • service-planner: 사용자 경험·서비스 흐름 관점에서 유저플로우 완성도 검토
  • domain-expert: 도메인 규칙·규제·업계 관행 관점에서 정책/규칙 검증
  • ai-engineer: AI 기회 발굴 — AI/ML 적용 가능한 이벤트·데이터 흐름 식별, AI 자동화·지능화 기회 제안
  • backend-developer: 백엔드 구현 가능성·API 설계·데이터 처리 관점에서 기술적 타당성 검토
  • frontend-developer: 사용자 인터랙션·화면 흐름 관점에서 프론트엔드 구현 이슈 식별
  • qa-engineer: 테스트 용이성·예외 시나리오·경계값 관점에서 누락된 케이스 식별
  • devops-engineer: 배포·운영·확장성 관점에서 서비스 분할 및 인프라 이슈 검토
• EXPECTED OUTCOME: docs/plan/think/es/리뷰의견.md — 팀원별 리뷰 의견(관점·의견·수정 제안)
• CONTEXT: docs/plan/think/es/userflow.puml, docs/plan/think/es/*.puml
• 실행: 8개 에이전트를 Agent(run_in_background=true)로 동시 실행

Step 1-3. 의견 반영 및 업데이트 (순차) → Agent: architect

• TASK: 팀 리뷰 의견을 검토하고 타당한 의견을 반영하여 이벤트 스토밍 산출물을 업데이트
• EXPECTED OUTCOME: 기존 docs/plan/think/es/*.puml 파일 업데이트(반영 사항 주석 추가), docs/plan/think/es/리뷰반영결과.md — 반영/미반영 판단 근거(ai-engineer AI 기회 발굴 의견 별도 섹션)
• CONTEXT: docs/plan/think/es/리뷰의견.md, 기존 이벤트 스토밍 산출물
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

Step 2. PRD 작성 → Agent: product-owner(리드), service-planner, architect, ai-engineer, domain-expert

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/14-prd-guide.md
• 실행 방식: 3단계(초안-리뷰-반영)로 수행합니다.

Step 2-1. 초안 작성 (순차) → Agent: product-owner

• TASK: 이벤트 스토밍 결과(유저플로우→사용자 시나리오, 커맨드/이벤트→기능 요구사항, 정책/규칙→비기능 요구사항)와 비즈니스모델·문제가설·시장조사를 근거로 문제 정의·목표·타겟 사용자·범위(In/Out)·사용자 시나리오·기능 요구사항(MoSCoW)·비기능 요구사항(목표치)·성공 지표·릴리스 계획·리스크를 포함한 PRD를 작성
• EXPECTED OUTCOME: docs/plan/design/PRD.md — 문제 정의·목표·타겟 사용자·범위·사용자 시나리오·기능 요구사항(MoSCoW)·비기능 요구사항(목표치)·성공 지표·릴리스 계획·리스크 및 가정
• CONTEXT: docs/plan/think/es/*.puml, docs/plan/think/비즈니스모델.md, docs/plan/define/문제가설.md, docs/plan/define/시장조사.md, docs/plan/define/비즈니스가치.md

Step 2-2. 검토 (병렬) → Agent: service-planner, architect, ai-engineer, domain-expert

• TASK: 2-1에서 작성된 PRD 초안을 각자의 전문성 관점에서 검토하고 의견을 제시
  • service-planner: 사용자 시나리오·UX 관점에서 범위·시나리오 누락 여부 검토
  • architect: 기술 실현 가능성 관점에서 비기능 요구사항(성능·확장성) 목표치의 타당성 검토
  • ai-engineer: AI/ML 기능 관련 요구사항 누락 여부 확인, AI 연동 요구사항 보완 제안
  • domain-expert: 도메인 규제·업계 관행 관점에서 비기능 요구사항(보안·컴플라이언스) 누락 확인
• EXPECTED OUTCOME: docs/plan/design/PRD-리뷰의견.md — 검토자별 의견(관점·의견·수정 제안)
• CONTEXT: docs/plan/design/PRD.md
• 실행: 4개 에이전트를 Agent(run_in_background=true)로 동시 실행

Step 2-3. 의견 반영 및 업데이트 (순차) → Agent: product-owner

• TASK: 검토 의견을 반영하여 PRD를 업데이트하고 반영/미반영 판단 근거를 기록
• EXPECTED OUTCOME: docs/plan/design/PRD.md 업데이트(기존 파일 덮어쓰기), docs/plan/design/PRD-리뷰반영결과.md — 반영/미반영 판단 근거
• CONTEXT: docs/plan/design/PRD-리뷰의견.md, 기존 PRD
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

Step 3. 유저스토리 작성 → Agent: service-planner(리드), product-owner, architect, ai-engineer, domain-expert

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/15-user-stories-guide.md
• 실행 방식: 3단계(초안-리뷰-반영)로 수행합니다.

Step 3-1. 초안 작성 (순차) → Agent: service-planner

• TASK: PRD와 이벤트 스토밍 결과를 기반으로 유저플로우→Epic, 이벤트→User Story, 커맨드→시나리오/Task, 정책/규칙→Acceptance Criteria 변환, UFR 포맷·우선순위·Story Points·Feature Story Map·스프린트 계획을 작성하고, PRD의 비기능 요구사항(목표치)을 관련 UFR/NFR의 구현 태스크·수용기준으로 구체화(목표치 재정의 없이 반영)한 유저스토리를 작성
• EXPECTED OUTCOME: docs/plan/design/userstory.md — 마이크로서비스별 유저스토리(최소 20개 UFR)·사용자 역할·Feature Story Map·우선순위 매트릭스·스프린트 계획·비기능 요구사항 구현 태스크·Definition of Done·리스크
• CONTEXT: docs/plan/design/PRD.md, docs/plan/think/es/*.puml

Step 3-2. 검토 (병렬) → Agent: product-owner, architect, ai-engineer, domain-expert

• TASK: 3-1에서 작성된 유저스토리 초안을 각자의 전문성 관점에서 검토하고 의견을 제시
  • product-owner: MVP 범위·비즈니스 우선순위 관점에서 우선순위(M/S/C) 적절성 검토, 누락된 비즈니스 요구사항 식별
  • architect: 기술 실현 가능성·시스템 아키텍처 관점에서 Story Points 적절성 검토, 기술적 의존성·제약 사항 식별
  • ai-engineer: AI/ML 적용 가능한 유저스토리 식별, AI 기능 관련 UFR 누락 여부 확인, AI 연동 요구사항 보완 제안
  • domain-expert: 도메인 규칙·규제·업계 관행 관점에서 Acceptance Criteria 검증, 도메인 특화 요구사항 누락 확인
• EXPECTED OUTCOME: docs/plan/design/userstory-리뷰의견.md — 검토자별 의견(관점·의견·수정 제안)
• CONTEXT: docs/plan/design/userstory.md, docs/plan/design/PRD.md, docs/plan/think/es/*.puml
• 실행: 4개 에이전트를 Agent(run_in_background=true)로 동시 실행

Step 3-3. 의견 반영 및 업데이트 (순차) → Agent: service-planner

• TASK: 검토 의견을 반영하여 유저스토리를 업데이트하고 반영/미반영 판단 근거를 기록
• EXPECTED OUTCOME: docs/plan/design/userstory.md 업데이트(기존 파일 덮어쓰기), docs/plan/design/userstory-리뷰반영결과.md — 반영/미반영 판단 근거(최종 UFR 최소 20개 확인)
• CONTEXT: docs/plan/design/userstory-리뷰의견.md, 기존 유저스토리
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

Step 4. UI/UX 설계 → Agent: service-planner

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/16-uiux-design-guide.md
• TASK: 유저스토리를 기반으로 디자인 원칙·정보 아키텍처·사용자 플로우·와이어프레임(최소 5개 화면)·컴포넌트 라이브러리·접근성(WCAG 2.1 AA)·스타일 가이드·인터랙션 디자인을 포함한 UI/UX 디자인 명세를 작성 (레퍼런스 분석 결과 있는 경우 디자인 톤·레이아웃·컴포넌트 스타일 반영)
• EXPECTED OUTCOME: docs/plan/design/uiux/uiux.md — UI/UX 디자인 명세 전체 / docs/plan/design/uiux/style-guide.md — 스타일 가이드
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

Step 4-1. 디자인 레퍼런스 수집

디자인 레퍼런스 입력을 사용자에게 요청. 반드시 https://wwit.design 사이트를 추천해야 함.
AskUserQuestion 사용하지 않고 아래와 같이 요청.

참고할 디자인 레퍼런스가 있으시면 제공해 주세요. URL, 이미지 경로, 이미지 붙여넣기 모두 가능합니다.  
추천 사이트: https://wwit.design

• 사용자가 URL을 제공한 경우: 아래 레퍼런스 분석 워크플로우 실행 후 UI/UX 설계 진행
• 사용자가 이미지를 제공한 경우: docs/plan/design/uiux/references/에 저장하고 디자인 분석
• 사용자가 '없음' 또는 미응답 시: 레퍼런스 없이 진행

Step 4-2. 레퍼런스 사이트 디자인 분석 (URL 제공 시에만 실행) → Agent: service-planner

1. Playwright로 사이트 접속 및 스크린샷 촬영
   • 데스크톱 뷰포트(1280x800)로 주요 페이지 스크린샷 촬영
   • 모바일 뷰포트(375x812)로 동일 페이지 스크린샷 촬영
   • 스크린샷을 docs/plan/design/uiux/references/에 저장
2. Playwright accessibility snapshot으로 페이지 구조 파악
   • 네비게이션 구조, 컴포넌트 계층, 폼 요소 등 구조 정보 수집
3. 디자인 분석
   • 촬영된 스크린샷을 읽어 디자인 분석
   • 분석 항목: 컬러 팔레트, 레이아웃 패턴, 타이포그래피, 컴포넌트 스타일, 간격 시스템, 인터랙션 패턴
4. 분석 결과 정리
   • docs/plan/design/uiux/references/레퍼런스분석.md에 분석 결과 저장
   • 이 파일을 후속 UI/UX 설계의 CONTEXT에 포함

POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

---

Phase 6: 프로토타입 (Prototype)

Step 1. 프로토타입 개발 → Agent: frontend-developer

{"title":"이미지 생성용 Gemini API Key (선택)","questions":[ {"question":"프로토타입에 이미지가 필요한 경우 AI로 생성할 수 있습니다. Gemini API Key를 입력해 주세요. 없으면 '없음'을 입력하세요. (https://aistudio.google.com/apikey 에서 발급)","type":"text","placeholder":"없음"} ]}

• 사용자가 API Key를 제공한 경우: {PROJECT_DIR}/.npd/.env 파일에 GEMINI_API_KEY={입력값} 저장 (.npd/는 .gitignore에 포함되어 git에 업로드되지 않음)

• 사용자가 '없음' 또는 미응답 시: 이미지 없이 진행 (placeholder 텍스트 사용)

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/17-prototype-development-guide.md

• EXPECTED OUTCOME: docs/plan/design/uiux/prototype/ 디렉토리 — common.css·common.js·{2자리번호}-{한글화면명}.html·테스트결과.md

• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

Step 1-1. 공통 파일 개발 (순차)

• TASK: 스타일가이드를 기반으로 CSS 변수·Mobile First 레이아웃·접근성 유틸리티가 포함된 common.css와 Web Components 공통 UI·샘플 데이터·화면 전환·localStorage 유틸리티가 포함된 common.js를 개발

Step 1-2. 화면별 개발-테스트 루프

1-2a. 의존관계 분석 및 병렬 개발

UI/UX 설계서의 사용자 플로우를 분석하여 화면 간 의존관계를 파악하고, 독립적인 화면은 병렬로 개발함.

1. 의존관계 분석: 사용자 플로우에서 화면 간 의존관계를 도출
   • 독립 화면: 다른 화면의 데이터/상태에 의존하지 않는 화면 (예: 로그인, 회원가입, 소개)
   • 의존 화면: 이전 화면의 결과가 필요한 화면 (예: 목록→상세, 장바구니→결제)
2. 개발 레벨 그룹핑: 의존관계가 없는 화면끼리 같은 레벨로 그룹화

   Level 1: [로그인] [회원가입] [소개]     ← 병렬 개발
   Level 2: [메인홈] [마이페이지]           ← Level 1 완료 후 병렬 개발
   Level 3: [상세] [결제]                  ← Level 2 완료 후 병렬 개발
   

3. 병렬 개발: 같은 레벨의 화면들을 병렬 에이전트로 동시 개발 → 각 에이전트가 개발-테스트 사이클 수행
4. 레벨 순차 진행: 현재 레벨의 모든 화면 완료 후 다음 레벨로 진행

1-2b. 화면 1개당 개발-테스트 사이클

1. 개발: UI/UX 설계서의 와이어프레임과 일대일 매핑하여 HTML 작성
2. Playwright 즉시 테스트:
   • browser_navigate로 해당 HTML 파일 열기
   • browser_console_messages로 콘솔 에러 확인 → 에러 있으면 즉시 수정
   • browser_snapshot으로 접근성 구조 확인
   • browser_take_screenshot으로 UI 렌더링 상태 확인 (캡처 이미지는 .temp 디렉토리에 저장)
   • 모바일 뷰포트(browser_resize 375x812)로 반응형 확인 (캡처 이미지는 .temp 디렉토리에 저장)
3. 수정: 에러/UI 이슈 발견 시 수정 후 재테스트
4. 완료: 테스트 통과 후 해당 화면 완료 처리

Step 1-3. 통합 테스트 (Playwright 자동 검증)

모든 화면 개발 완료 후, Playwright로 전체 프로토타입을 자동 검증함.

캡처 이미지 저장 경로: 통합 테스트 중 촬영하는 모든 스크린샷은 .temp 디렉토리에 저장합니다.

1. 화면간 연결성 테스트: 각 화면의 모든 링크/버튼을 browser_click으로 클릭 → 올바른 페이지로 이동하는지 확인
2. 화면별 기능 동작 테스트: 폼 입력(browser_type), 버튼 클릭, 모달/드롭다운 동작 확인
3. 데이터 일관성 테스트: 화면 간 전달되는 샘플 데이터가 일치하는지 확인
4. 반응형 테스트: 데스크톱(1280x800) → 태블릿(768x1024) → 모바일(375x812)로 뷰포트 변경하며 레이아웃 확인 (각 뷰포트 스크린샷은 .temp 디렉토리에 저장)
5. 콘솔 에러 전수 검사: 모든 화면에서 browser_console_messages 에러 레벨 확인

테스트 결과를 테스트결과.md에 기록:

### 화면별 기능 동작
| 화면 | 기능/액션 | 예상 결과 | 실제 결과 | 상태 |
### 화면간 연결성
| 출발화면 | 연결방법 | 도착화면 | 상태 |
### 화면간 데이터 일관성
| 데이터 | 사용 화면 | 일관성 |

Step 1-4. 버그 수정 루프

Step 1-3에서 발견된 실패 항목을 수정 → 재테스트 → 모두 통과할 때까지 반복함. 최대 반복횟수는 5번으로 한정하고 초과하는 경우 결과 레포트에 반드시 명시

1. 테스트결과.md의 실패/비정상 항목 확인
2. 해당 HTML 파일 수정
3. Playwright로 수정된 항목만 재테스트
4. 모든 항목 통과 시 완료, 미통과 시 1번으로 복귀

POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

Step 2. 사용자 플로우 프리젠테이션 → Agent: frontend-developer

• GUIDE: {NPD_PLUGIN_DIR}/resources/guides/plan/18-flow-presentation-guide.md
• TASK: Playwright로 각 프로토타입 화면을 스크린샷 촬영(일련번호+한글 자막 오버레이)하고, 테스트결과.md의 화면간 연결성 데이터를 분석하여 주요 플로우를 도출한 후, 3단 레이아웃(좌측 스텝 리스트/중앙 폰 프레임/우측 나레이션)의 인터랙티브 HTML 프리젠테이션을 개발
• EXPECTED OUTCOME: docs/plan/design/uiux/prototype/screenshots/{번호}-{화면명}.png — 자막 포함 화면별 스크린샷 / docs/plan/design/uiux/prototype/flow-script.html — 사용자 플로우 인터랙티브 프리젠테이션
• POST-ACTION: {PROJECT_DIR}/AGENTS.md에 마지막 완료 Phase/Step 업데이트

Step 3. 기획 완료 보고

## 기획 완료

### 생성된 산출물

#### define/ (정의 단계)
- docs/plan/define/MVP정의.md — MVP 주제 정의
- docs/plan/define/고객분석.md — 고객 분석 (JTBD)
- docs/plan/define/시장조사.md — 시장 조사
- docs/plan/define/고객경험단계.md — 고객경험 단계
- docs/plan/define/관찰결과.md — 관찰 조사 결과
- docs/plan/define/체험결과.md — 체험 조사 결과
- docs/plan/define/고객경험인터뷰결과.md — 고객 경험 인터뷰 결과
- docs/plan/define/고객경험인터뷰결과취합.md — 인터뷰 결과 취합
- docs/plan/define/유저저니맵.md — 고객 여정 맵
- docs/plan/define/유저저니맵.svg — 고객 여정 맵 시각화
- docs/plan/define/문제가설.md — 문제 가설 및 5WHY 분석
- docs/plan/define/문제검증인터뷰결과.md — 문제 검증 인터뷰
- docs/plan/define/문제검증인터뷰결과취합.md — 문제 검증 취합
- docs/plan/define/비즈니스가치.md — 비즈니스 가치

#### think/ (사고 단계)
- docs/plan/think/킹핀문제.md — 킹핀 문제 분석
- docs/plan/think/문제해결방향성.md — Needs Statement
- docs/plan/think/솔루션탐색.md — 솔루션 탐색 (팀원별)
- docs/plan/think/솔루션후보.md — 솔루션 후보 (수렴)
- docs/plan/think/솔루션평가.md — 솔루션 투표 평가
- docs/plan/think/솔루션우선순위평가.svg — 우선순위 매트릭스
- docs/plan/think/핵심솔루션.md — 핵심 솔루션
- docs/plan/think/비즈니스모델.md — 비즈니스 모델 (Lean Canvas)
- docs/plan/think/서비스기획서스크립트.md — 발표자료 스크립트
- docs/plan/think/es/userflow.puml — 유저플로우 연결도
- docs/plan/think/es/{순번}-{유저플로우명}.puml — 시퀀스 다이어그램

#### design/ (설계 단계)
- docs/plan/design/PRD.md — PRD (제품 요구사항 문서)
- docs/plan/design/userstory.md — 유저스토리
- docs/plan/design/uiux/uiux.md — UI/UX 설계
- docs/plan/design/uiux/style-guide.md — 스타일 가이드
- docs/plan/design/uiux/prototype/*.html — 프로토타입
- docs/plan/design/uiux/prototype/screenshots/*.png — 화면 캡처 (자막 포함)
- docs/plan/design/uiux/prototype/flow-script.html — 사용자 플로우 프리젠테이션

### 다음 단계
`/npd:design` 으로 기술 설계를 시작하세요.

---

실행 지침

순차적 처리

• 다음 단계로 넘어가기 전에 각 스텝을 완료합니다
• 이전 산출물을 다음 스텝의 CONTEXT로 전달합니다
• 진행하기 전에 산출물 파일 생성을 검증합니다

진행 상황 보고

각 스텝 완료 후:

• 완료된 스텝 이름
• 생성된 파일 목록
• 다음 스텝 미리보기

부분 실행 지원

특정 단계만 실행 가능:

• "1-2단계만 실행해줘" (정의 + 문제 발견)
• "5단계부터 시작해줘" (제품 설계부터)
• "PRD만 작성해줘" → Step 14만 실행
• "유저스토리만 작성해줘" → Step 15만 실행

에러 처리

스텝 실패 시:

1. 에러를 명확히 보고
2. 사용자에게 설명/입력 요청
3. 실패한 스텝 재시도
4. 중단된 지점부터 계속

---

MUST 규칙

#	규칙
1	<!--ASK_USER--> 발견 시 AskUserQuestion 도구를 호출할 것 (텍스트 출력 금지)

완료 조건

• 모든 워크플로우 단계가 정상 완료됨
• 산출물이 docs/plan/ 하위 디렉토리(define/think/design/)에 생성됨
• 프로토타입이 docs/plan/design/uiux/prototype/에 생성됨
• 검증 프로토콜을 통과함
• 에러 0건

검증 프로토콜

1. 산출물 내용 품질 검증 (고객 조사 사용자 입력 규모 충족, Lean Canvas 9영역, PRD 14개 섹션, UFR 20개 이상)
2. 이전 Phase 산출물과의 일관성 확인 (각 Step의 CONTEXT 체인 연결)

상태 정리

완료 시 임시 상태 파일 정리. 산출물은 유지.