Mock planning

Mock Planning (mock 기획 → mock 개발)

The Mandate

mock 은 요구사항을 구체화한 다음에만 만든다. 사용자가 "mock 만들어줘"라고 해도, 곧바로 UI 코드부터 짜지 않는다. 먼저 이 스킬로 무엇을·누구를 위해·왜 만드는지 확정하고, 그 다음 프로젝트의 프론트엔드 프레임워크로 실제 프론트 코드에 mock 을 개발한다.

<HARD-RULE> 1. 구체화가 끝나고 사용자가 스펙을 확정하기 전에는 절대 mock 코드를 만들지 않는다. 2. 모든 질문의 선택지는 **AI 가 만든 구체적 후보**여야 한다. "무엇을 원하세요?" 같은 빈 질문·제네릭 옵션 금지. 후보는 반드시 코드베이스 탐색에 근거한다. 3. 모든 선택은 `AskUserQuestion` 도구로 받는다 (자유 입력 "Other" 는 도구가 자동 추가 — 옵션에 직접 넣지 말 것). </HARD-RULE>

Step 0 — 코드베이스 탐색 (후보의 근거 확보)

질문을 만들기 전에, 후보를 근거 있게 제시하려고 먼저 프로젝트를 읽는다.

1. 프레임워크 탐지 — 나중 mock 개발에 쓸 스택 확인:
   • Cargo.toml 에 dioxus → Dioxus (RSX). dioxus 스킬 연계.
   • package.json 의 react / vue / next / svelte → 해당 프레임워크. frontend-design 스킬 연계.
   • 없으면 HTML/CSS 로 폴백.
2. 라우터·페이지 탐색 — 기존 페이지/라우트를 grep 해서 엔트리·페이지 후보의 근거를 만든다:
   • Dioxus: Route, #[route(, Router, rsx! 를 grep.
   • React/Vue: routes, <Route, createRouter, pages/, app/ 디렉터리.
3. 이 탐색 결과로 실제 존재하는 페이지 이름을 확보해 두었다가, 아래 모든 후보 생성의 재료로 쓴다.

Step 1 — 추가인가 수정인가

AskUserQuestion 단일선택 1문항:

• 페이지 추가 → Branch A
• 페이지 수정 → Branch B

---

Branch A — 페이지 추가

A-1. 엔트리 페이지 (멀티선택)

이 페이지로 진입하는 경로. Step 0 에서 찾은 실제 페이지들 중 진입 가능성이 높은 2~4개를 후보로 제시(멀티). 나머지는 Other.

A-2. 기획할 페이지 목록 (멀티선택)

이번에 새로 기획할 페이지들. 요청 주제 + 엔트리 흐름에서 자연스럽게 필요한 페이지들을 2~4개 후보로 제시(멀티). 예: 목록 → 상세 → 편집. 나머지 Other.

A-3. 페이지별 상세 기획 (각 페이지 루프)

A-2 에서 확정된 페이지마다 아래를 받는다. 후보는 그 페이지 성격에 맞게 매번 새로 생성한다.

콜 1 (멀티선택 2문항):

1. 대상 고객 — 이 페이지를 쓰는 사람이 누군지. 도메인·기존 코드에 맞는 구체 후보 (예: "신규 방문자", "펀드 심사역", "관리자"). 멀티.
2. 전달 정보 — 이 페이지에서 보여주려는 정보. 구체 후보 (예: "포트폴리오 수익률", "회사 개요", "투자 단계"). 멀티.

콜 2 (멀티선택 1문항): 3. 고객 니즈 — 그 정보로 고객이 얻으려는 것. 콜 1 의 고객·정보를 근거로 후보 생성.

• <NEED-RULE>단순 "정보 열람"은 니즈가 아니다. 정보를 봄으로써 고객이 무엇을 하거나 결정하게 되는지 구체적 결과여야 한다.</NEED-RULE>
• 나쁜 예: "수익률을 본다". 좋은 예: "수익률을 보고 추가 출자 여부를 결정한다", "경쟁사 대비 우위를 확인해 투자 확신을 얻는다".
• 후보는 이 "좋은 예" 형태로만 만든다.

콜 3 (단일선택, 정보마다 1문항): 4. 정보 출처 — 콜 1 에서 고른 각 정보가 어디서 오는지. 정보 1개 = 질문 1개, 한 콜에 최대 4개. 후보(단일): 내부 API, DB 조회, 사용자 입력, 외부 서비스/3rd-party. 계산·파생이면 Other.

배칭: AskUserQuestion 은 콜당 최대 4문항, 문항당 최대 4옵션. 정보가 5개 이상이면 출처 질문을 여러 콜로 나눈다.

---

Branch B — 페이지 수정

B-1. 수정할 페이지 (멀티선택)

Step 0 에서 찾은 실제 페이지들을 후보로 제시. 수정 대상 선택. 멀티.

B-2. 현재 문제점 (단일선택)

각 대상 페이지의 현재 문제를 AI 가 코드/UX 관점에서 추정해 구체 후보로 제시 (예: "핵심 지표가 스크롤 아래 묻힘", "CTA 가 불명확", "정보 위계 없음"). 단일 + Other.

B-3. 해결 방향 (단일선택)

B-2 문제에 대응하는 해결안을 구체 후보로 제시 (예: "상단에 요약 카드 추가", "1차 액션 버튼 강조", "정보 그룹핑 재배치"). 단일 + Other.

---

Step 2 — 스펙 통합·확정

받은 답으로 구조화 스펙을 만들어 사용자에게 보여주고 확정을 받는다.

추가:

## <페이지명>
- 엔트리: ...
- 대상 고객: ...
- 전달 정보: ... (출처: ...)
- 고객 니즈: <구체 결과>

수정:

## <페이지명>
- 문제점: ...
- 해결 방향: ...

"이대로 mock 만들까요?" 확정 전엔 다음 단계로 넘어가지 않는다.

Step 3 — mock 개발

확정 스펙에 근거해 Step 0 에서 탐지한 프레임워크로 프론트 코드에 직접 mock 을 만든다.

• Dioxus → dioxus 스킬 규칙대로 RSX 컴포넌트/라우트.
• React·Vue 등 → frontend-design 스킬로 해당 프레임워크 컴포넌트.
• 프레임워크 없음 → HTML/CSS 폴백.

mock 은 확정된 대상 고객·정보·니즈를 화면에 실제로 반영해야 한다 (니즈를 이루게 하는 정보 위계·액션이 보이도록).

Anti-Patterns

• ❌ 요청 받자마자 UI 코드부터 짜기 → 먼저 Step 0~2.
• ❌ 후보 없이 "어떤 정보 보여줄까요?" 열린 질문 → 항상 근거 있는 후보 제시.
• ❌ 니즈를 "정보 열람"으로 두기 → 구체 결과/의사결정으로 리프레이밍.
• ❌ 정보 출처 안 정하고 넘어가기 → 정보마다 출처 확정.