plan-reviewer

name

plan-reviewer

description

기획 문서의 논리적 완성도를 검토하고 놓치기 쉬운 부분을 찾아주는 skill입니다. Use this skill when: - User requests plan review with `/plan-review [target]` command - User shares planning document (Notion URL, markdown, or text) and asks for review - User mentions "기획 검토", "기획서 리뷰", "논리 검토", "빠진 거 없나" - User asks "이거 맞아?", "논리적으로 문제없어?", "놓친 거 있어?" The skill performs comprehensive review covering: - Logical consistency (논리적 일관성) - Missing cases and edge cases (누락된 케이스) - Dependency issues (의존성 문제) - User scenario gaps (사용자 시나리오 빈틈) - Technical feasibility (기술적 실현 가능성)

Plan Reviewer

Overview

이 skill은 기획 문서를 다각도로 검토하여 논리적 빈틈과 놓치기 쉬운 부분을 찾아줍니다.

핵심 가치

1. 객관적 시각 제공: 기획자가 놓치기 쉬운 blind spot 발견
2. 구조적 검토: 체계적인 체크리스트 기반 분석
3. 실행 가능한 피드백: 구체적이고 적용 가능한 개선안 제시

Trigger Methods

Explicit Command

/plan-review [target]

Examples:

• /plan-review - 대화 중 공유된 기획 내용 검토
• /plan-review https://notion.so/... - Notion 기획 문서 검토
• /plan-review 위 기획서 - 이전에 공유된 기획서 검토

Auto-Detection Keywords

다음 키워드 감지 시 자동 트리거:

• "기획 검토해줘", "기획서 리뷰해줘"
• "논리적으로 맞아?", "빠진 거 없어?"
• "이거 문제없어?", "검토 좀 해줘"
• "놓친 거 있을까?", "확인해줘"

Input Types

1. Notion URL

https://www.notion.so/workspace/Page-Title-abc123def456...

처리 방식:

1. URL에서 Page ID 추출 (마지막 32자리 hex)
2. Notion MCP로 페이지 조회
3. 내용 파싱 후 분석

2. Markdown/Text

대화창에 직접 입력되거나 파일로 제공된 마크다운 또는 텍스트

3. 이전 대화 컨텍스트

대화 중 공유된 기획 내용을 참조하여 검토

---

Workflow

Phase 1: 기획 문서 수집

1. 입력 타입 판별

   • Notion URL인 경우 → Notion MCP로 조회
   • 텍스트/마크다운인 경우 → 직접 파싱
   • 컨텍스트 참조인 경우 → 이전 대화에서 추출

2. 문서 구조 파악

   • 기획 유형 식별 (기능 기획, 서비스 기획, 프로젝트 기획 등)
   • 주요 섹션 추출
   • 핵심 요소 정리

Phase 2: 다차원 분석

동시에 여러 관점에서 분석 수행:

// 병렬 분석 실행
const parallelAnalysis = [
  // 1. 논리적 일관성 검토
  analyzeLogicalConsistency(document),

  // 2. 누락 케이스 분석
  analyzeMissingCases(document),

  // 3. 의존성 검토
  analyzeDependencies(document),

  // 4. 사용자 시나리오 검증
  analyzeUserScenarios(document),

  // 5. 기술적 실현 가능성
  analyzeTechnicalFeasibility(document)
];

2.1 논리적 일관성 검토 (Logical Consistency)

검토 항목:

• 모순 탐지: A를 하면 B가 된다는데, 다른 곳에서는 A를 하면 C가 된다고 함
• 순환 참조: A → B → C → A 같은 순환 의존
• 인과관계 검증: 원인과 결과가 논리적으로 연결되는지
• 전제 조건 확인: 암묵적 가정이 명시되어 있는지
• 용어 일관성: 같은 개념에 다른 용어 사용 여부

질문 예시:

- "등록 완료 시 알림이 간다"는데, 누구에게 어떤 알림이 가나요?
- "관리자만 삭제 가능"인데, 관리자의 정의가 어디에도 없습니다.
- A 화면에서는 "상태"라고 하고 B 화면에서는 "진행단계"라고 합니다. 같은 건가요?

2.2 누락 케이스 분석 (Missing Cases)

검토 항목:

• 엣지 케이스: 경계값, 빈 값, 최대/최소값
• 예외 상황: 에러, 타임아웃, 권한 부족
• 동시성 이슈: 여러 사용자가 동시에 같은 작업
• 상태 전이 빈틈: 모든 상태에서 모든 액션이 정의되었는지
• 데이터 유효성: 잘못된 입력에 대한 처리

질문 예시:

- 수량이 0이면 어떻게 되나요?
- 입력 중에 네트워크가 끊기면?
- 두 사람이 동시에 같은 항목을 수정하면?
- "진행중" 상태에서 "삭제"는 가능한가요?

2.3 의존성 검토 (Dependencies)

검토 항목:

• 선행 조건: 이 기능을 쓰려면 먼저 필요한 것
• 후행 영향: 이 변경이 다른 기능에 미치는 영향
• 외부 의존: 외부 시스템, API, 서비스 의존
• 데이터 의존: 필요한 데이터가 어디서 오는지
• 권한 의존: 필요한 권한과 역할

질문 예시:

- 이 기능을 쓰려면 거래처가 먼저 등록되어 있어야 하나요?
- 제품을 삭제하면 이 제품을 참조하는 주문은 어떻게 되나요?
- 결제 API가 다운되면 주문 프로세스는 어떻게 진행되나요?

2.4 사용자 시나리오 검증 (User Scenarios)

검토 항목:

• Happy Path: 정상 흐름이 완전한지
• Unhappy Path: 실패/취소/되돌리기 흐름
• 사용자 실수: 잘못된 입력, 중복 클릭, 뒤로가기
• 중단 시나리오: 중간에 그만두면?
• 재진입 시나리오: 다시 돌아오면?

질문 예시:

- 사용자가 폼 작성 중에 다른 페이지로 갔다가 돌아오면?
- 저장 버튼을 연타하면?
- 입력을 잘못해서 처음부터 다시 하고 싶으면?
- 모바일에서도 이 흐름이 동일한가요?

2.5 기술적 실현 가능성 (Technical Feasibility)

검토 항목:

• 성능 우려: 대량 데이터, 복잡한 계산
• 보안 고려: 민감 정보, 권한 체크
• 확장성: 데이터/사용자 증가 시
• 기술 부채: 임시방편적 설계
• 구현 복잡도: 과도하게 복잡한 요구사항

백엔드 설계 규약 체크 (bitda-back 아키텍처 기준):

• 멀티테넌트 격리: 데이터 모델에 organizationId가 포함되어 있는지
• 삭제 방식: 소프트 딜리트(deleted_at) vs 하드 딜리트가 명시되지 않으면 구현자가 임의 결정
• 목록 API 페이지네이션: page/size 파라미터 미명시 시 전체 조회로 구현될 위험
• UNIQUE 제약: 중복 방지 조건([중복] 규칙)이 없으면 DB 레벨 제약 누락
• 도메인 이벤트: 다른 모듈(재고, 회계 등)에 영향 주는 액션에 이벤트 정의 누락 시 연동 버그
• 비즈니스 규칙 분류: [검증]/[상태]/[중복]/[이벤트] 태그 없이 산문으로만 작성 시 구현 누락 위험

질문 예시:

- 10만 건의 데이터를 한 번에 조회하면 성능은 괜찮을까요?
- 비밀번호를 평문으로 저장하면 안 됩니다.
- 사용자가 1000명으로 늘어나면 이 구조가 버틸까요?
- 이 데이터는 삭제 시 DB에서 완전히 지워지나요, 아니면 deleted_at만 찍히나요?
- 목록 API가 있는데 page/size 파라미터 명세가 없습니다. 전체 조회인가요?
- 이 등록 액션이 재고 모듈에 영향을 주는데, 도메인 이벤트 정의가 없습니다.

2.6 UI 패턴 일관성 (UI Pattern Consistency) - Shift Left

목적: ui-improver/ui-supervisor에서 반복 발견되는 UI 불일치를 기획 단계에서 사전 검증

검토 항목:

• 컴포넌트 재사용: 기존 공유 컴포넌트(PageTitle, FormSheet, DateRangeFilter 등)가 기획서에 명시되어 있는지
• 동일 도메인 참조: 같은 앱/도메인의 기존 페이지와 테이블 스타일, 뱃지, 필터 구성이 일관되는지
• 과다 UI 요소: 데이터 규모 대비 요약 카드, 필터, 검색창이 과도하게 기획된 것은 아닌지
• 뱃지 패턴: 상태 표시에 기존 StatusBadge/LiquorTypeBadge를 사용하도록 명시했는지

질문 예시:

- 동일 도메인(예: 재고관리)의 다른 페이지는 테이블에 border-r 세로선이 있는데, 이 페이지도 동일해야 하지 않나요?
- 기획서에 요약 카드 4개가 있는데, 데이터가 20건 미만이라면 정말 필요한가요?
- 주종 표시에 일반 Badge를 쓰고 있는데, 기존 LiquorTypeBadge 컴포넌트를 사용해야 하지 않나요?
- 커스텀 시간 입력을 기획했는데, 기존 TimeInput 컴포넌트가 이미 있습니다.

Phase 3: 결과 종합 및 제안

분석 결과를 우선순위와 함께 정리:

## 기획 검토 결과

### 요약
- 검토 대상: [기획서명]
- 전체 발견 사항: [N]개
- 심각도별: Critical [X]개, Major [Y]개, Minor [Z]개

### Critical (즉시 해결 필요)
| # | 구분 | 발견 사항 | 제안 |
|---|------|----------|------|
| 1 | 논리 모순 | [설명] | [해결책] |

### Major (해결 권장)
| # | 구분 | 발견 사항 | 제안 |
|---|------|----------|------|
| 1 | 누락 케이스 | [설명] | [추가 필요 내용] |

### Minor (개선 고려)
| # | 구분 | 발견 사항 | 제안 |
|---|------|----------|------|
| 1 | 명확성 | [설명] | [개선안] |

### 확인 필요 (질문)
의도가 불분명하여 확인이 필요한 사항:
1. [질문 1]
2. [질문 2]

### 잘 된 점
- [칭찬할 부분 1]
- [칭찬할 부분 2]

---

Analysis Dimensions

심각도 기준

심각도	기준	예시
Critical	기능 불가능 또는 심각한 문제 초래	논리 모순, 데이터 손실 가능성
Major	주요 기능에 영향, 사용자 불편	엣지 케이스 미처리, 에러 처리 누락
Minor	기능은 되지만 개선 필요	용어 불일치, 명확성 부족

기획 유형별 중점 검토 항목

기획 유형	중점 검토
기능 기획	사용자 시나리오, 엣지 케이스, UI/UX 흐름
서비스 기획	비즈니스 로직, 정책, 예외 처리
시스템 기획	기술 실현성, 성능, 보안
프로젝트 기획	의존성, 일정, 리소스

---

Output Formats

1. 상세 리포트 (기본)

전체 분석 결과를 테이블과 함께 상세하게 제공

2. 요약 리포트

## 핵심 발견 사항 (TOP 5)

1. 🔴 [Critical 이슈] - [한 줄 설명]
2. 🟠 [Major 이슈] - [한 줄 설명]
3. 🟠 [Major 이슈] - [한 줄 설명]
4. 🟡 [Minor 이슈] - [한 줄 설명]
5. ❓ [확인 필요] - [한 줄 질문]

3. 체크리스트 형식

## 검토 체크리스트

### 논리적 일관성
- [x] 모순 없음
- [ ] ⚠️ 용어 불일치 발견 (상세: ...)
- [x] 인과관계 명확

### 누락 케이스
- [ ] 🔴 에러 처리 누락 (상세: ...)
- [ ] ⚠️ 경계값 미정의 (상세: ...)
- [x] 빈 값 처리 정의됨

4. 질문 중심 형식

확인이 필요한 사항을 질문으로 정리:

## 기획 확인 질문

### 비즈니스 로직
1. "등록 시 알림"이 언급되었는데, 구체적으로:
   - 누구에게 알림이 가나요?
   - 어떤 채널(이메일/앱푸시/SMS)로?
   - 알림 내용은?

### 예외 상황
2. 결제 실패 시 처리가 명시되지 않았습니다:
   - 재시도 가능한가요?
   - 몇 번까지?
   - 최종 실패 시 어떻게?

### 데이터
3. "이전 데이터 마이그레이션" 언급이 있는데:
   - 어떤 데이터가 대상인가요?
   - 매핑 규칙은?
   - 마이그레이션 실패 시?

---

Examples

Example 1: 간단한 기획 검토

User: 다음 기획 검토해줘.
      - 사용자가 상품을 장바구니에 담는다
      - 결제 버튼을 누르면 결제가 진행된다
      - 결제 완료되면 주문이 생성된다

Response:
## 기획 검토 결과

### 요약
검토 대상: 장바구니-결제 프로세스
발견 사항: 8개 (Critical 2, Major 4, Minor 2)

### Critical
| # | 구분 | 발견 사항 | 제안 |
|---|------|----------|------|
| 1 | 누락 | 결제 실패 시 처리 없음 | 결제 실패 → 에러 메시지 → 재시도 옵션 추가 |
| 2 | 누락 | 재고 확인 단계 없음 | 결제 전 재고 확인 로직 추가 |

### Major
| # | 구분 | 발견 사항 | 제안 |
|---|------|----------|------|
| 1 | 의존성 | 로그인 여부 언급 없음 | 비회원 구매 가능 여부 명시 |
| 2 | 시나리오 | 장바구니 수정 흐름 없음 | 수량 변경, 삭제 기능 추가 |
| 3 | 시나리오 | 주문 후 흐름 없음 | 주문 확인 페이지, 주문 내역 조회 추가 |
| 4 | 엣지케이스 | 장바구니 빈 상태 처리 없음 | 빈 장바구니 시 결제 버튼 비활성화 |

### Minor
| # | 구분 | 발견 사항 | 제안 |
|---|------|----------|------|
| 1 | 명확성 | "결제 진행"이 모호함 | PG 연동 상세 흐름 필요 |
| 2 | 명확성 | "주문 생성" 후 알림 없음 | 주문 완료 알림 추가 권장 |

### 확인 필요
1. 부분 결제(포인트+카드)가 가능한가요?
2. 장바구니 유효기간이 있나요?
3. 동일 상품 중복 담기가 가능한가요?

Example 2: Notion 기획서 검토

User: /plan-review https://www.notion.so/workspace/Feature-abc123...

Response:
## Notion 기획서 검토

[Notion MCP로 문서 조회 중...]

### 문서 정보
- 제목: [FEAT] 재고 실사 기능
- 버전: 1.2
- 진행 단계: 기획 디벨롭

### 분석 결과
[상세 분석 내용...]

### 권장 조치
1. 🔴 "실사 중 재고 이동" 케이스 추가 필요
2. 🟠 실사 취소 시 롤백 로직 명시 필요
3. 🟠 대량 품목(1000개+) 실사 시 페이지네이션 필요

Example 3: 대화형 기획 검토

User: 방금 얘기한 회원 등급 시스템 기획이 논리적으로 맞는지 봐줘

Response:
## 회원 등급 시스템 검토

이전 대화에서 공유된 내용 기반으로 검토합니다.

### 정리된 기획 내용
- 등급: 브론즈 → 실버 → 골드 → 플래티넘
- 승급 조건: 월 구매액 기준
- 혜택: 등급별 할인율 차등

### 발견 사항

#### Critical
1. **강등 조건 없음**: 승급만 있고 강등 기준이 없습니다.
   - 제안: 3개월 연속 조건 미달 시 강등 로직 추가

#### Major
2. **경계값 문제**: "월 10만원 이상 시 실버"인데, 정확히 10만원은?
   - 제안: "10만원 이상" 또는 "10만원 초과" 명확히

3. **혜택 중복**: 기존 프로모션 할인과 등급 할인 중복 적용 여부
   - 제안: 할인 적용 우선순위 정책 필요

### 확인 필요
1. 등급은 매월 1일에 갱신되나요, 실시간인가요?
2. 신규 가입자 첫 등급은?
3. 탈퇴 후 재가입 시 등급 초기화?

---

Error Handling

상황	처리
기획 내용 없음	기획 내용 입력 요청
Notion 접근 실패	에러 메시지 + URL 재확인 요청
분석 불가능한 형식	구조화된 형식으로 재입력 요청
기획 범위 과대	섹션별로 나눠서 검토 제안

---

Tips for Better Reviews

기획서 작성자에게

1. 구조화: 섹션을 명확히 구분
2. 명시성: 암묵적 가정도 적어두기
3. 완결성: Happy path뿐 아니라 예외도 기술
4. 용어 정의: 도메인 용어는 정의 포함

검토 요청 시

1. 맥락 제공: 배경, 제약사항 공유
2. 중점 영역 지정: 특히 봐줬으면 하는 부분 명시
3. 관련 문서 링크: 연관된 다른 기획 참조