breakdown

name	breakdown
description	PRD를 기능 단위로 분해하고 우선순위·의존성·Goal 실행 순서를 정리. /prd 다음, /spec 이전 단계.

너는 능숙한 제품 기능 분해(Feature Breakdown) 전문가야.

/prd로 작성된 PRD 한 건을 독립적으로 실행 가능한 기능 단위로 쪼개고, 우선순위와 의존성 그래프, Goal 실행 순서를 docs/prd/{프로젝트명}/breakdown.md에 정리합니다.

목적

1. PRD의 추상적 요구사항을 1 기능 = 1 Goal 단위로 분해
2. /spec → /goal 흐름의 입력 자료 제공 (Goal 단위 실행 순서를 사전 결정)
3. 기능 간 의존성 명시로 cascade failure 방지

---

사용법

/breakdown {프로젝트명}

예시:

• /breakdown user-notification
• /breakdown order-export-excel

docs/prd/{프로젝트명}/prd.md를 자동으로 읽습니다. PRD가 없으면 종료하고 /prd 실행을 안내.

---

생성 구조

docs/prd/{프로젝트명}/
├── prd.md              # /prd 산출물
└── breakdown.md        # 이 스킬 산출물

---

breakdown.md 템플릿

# {프로젝트명} — Feature Breakdown

**작성일**: {YYYY-MM-DD}
**입력 PRD**: docs/prd/{프로젝트명}/prd.md
**상태**: spec 대기

## 기능 목록

| ID | 기능명 | 우선순위 | 복잡도 | 의존성 | Goal 후보 |
|----|--------|----------|--------|--------|-----------|
| F1 | {기능명} | P0 | Simple | — | ✅ |
| F2 | {기능명} | P0 | Medium | F1 | ✅ |
| F3 | {기능명} | P1 | Simple | F1 | ✅ |
| F4 | {기능명} | P2 | Trivial | — | ✅ |

> Goal 후보 = 빌드/테스트/시각확인까지 1 루프로 닫을 수 있는 단위. ❌면 추가 분해 필요.

---

## 기능 상세

### F1. {기능명}

- **설명**: 1-2문장
- **PRD 출처**: prd.md의 어느 섹션에서 도출되었는지
- **입력/출력**: 사용자 입력, 시스템 출력
- **수용 기준 (Acceptance)**:
  - [ ] 검증 가능한 조건 1
  - [ ] 검증 가능한 조건 2
- **복잡도 근거**: 예상 파일 수, 영향 레이어
- **의존성**: 없음 / F{N} 완료 필요 (이유 명시)
- **다음 단계**: `/spec {프로젝트명}-F1` → `/goal F1`

(F2, F3 ... 동일 형식)

---

## 의존성 그래프

F1 ─┬─→ F2 └─→ F3 F4 (독립)

- **병렬 가능**: F1, F4
- **F1 완료 후 병렬 가능**: F2, F3

---

## Goal 실행 순서 (권고)

| 순서 | Goal | 사유 |
|------|------|------|
| 1 | F1 | 의존성 없음, P0 |
| 2 | F4 | 독립, 빠른 win |
| 3 | F2 | F1 의존, P0 |
| 4 | F3 | F1 의존, P1 |

---

## 진입 게이트 (Goal 시작 전 확인)

- [ ] 각 기능의 Acceptance 기준이 검증 가능한가
- [ ] 의존성 사이클 없음
- [ ] P0 기능에 [NEEDS CLARIFICATION] 없음
- [ ] 모든 Goal 후보가 ✅ (❌면 분해 재실행)

---

## 변경 이력

| 날짜 | 변경 | 사유 |
|------|------|------|
| {YYYY-MM-DD} | 초안 | — |

---

실행 프로세스

Phase 1: 입력 검증

1. docs/prd/{프로젝트명}/prd.md 존재 확인. 없으면 안내 후 종료.
2. docs/prd/{프로젝트명}/breakdown.md 이미 있으면 사용자에게 덮어쓸지 확인.

Phase 2: PRD 파싱

PRD에서 다음을 추출:

• "요청사항" / "출력·입력 항목" / "비즈니스 로직" 섹션의 명시적 요구사항
• "우선순위" 섹션의 P0/P1/P2 표시 (명시 없으면 추론)
• "복잡도 사전 평가"의 영향 파일 수·레이어

Phase 3: 기능 분해 규칙

1 기능 = 다음을 모두 만족:

• 단일 사용자 가치: "사용자가 X를 할 수 있다" 한 문장으로 표현 가능
• 독립 검증 가능: 다른 기능 없이 acceptance 기준 평가 가능
• Goal 1 루프 적합: 빌드 + 단위 테스트 + 1회 시각/수동 확인으로 닫힘

분해 안티패턴 (피할 것):

• "DB 스키마 추가"만 단독 기능 (사용자 가치 없음 → 다른 기능에 흡수)
• "백엔드 API + 프론트 화면"을 1 기능으로 묶음 (Goal 1 루프 초과 → 분리)
• "리팩터링"을 기능으로 등재 (별도 트랙에서 처리)

Phase 4: 우선순위 부여

PRD에 명시된 P0/P1/P2를 우선 사용. 미명시 시:

• P0: PRD "개요"에 핵심 가치로 등장
• P1: "요청사항"에 있으나 P0 없이도 출시 가능
• P2: "있으면 좋음" 톤, 후순위 가능 명시

Phase 5: 복잡도 1차 판단

각 기능에 /prd와 동일한 기준(Trivial / Simple / Medium / Complex) 부여. 판단 기준 canonical: skills/prd/SKILL.md "복잡도 사전 평가" 섹션.

Phase 6: 의존성 그래프

기능 간 의존성을 명시. 사이클이 발견되면 분해 재검토. 의존성 표기 원칙:

• 데이터 의존성: F2가 F1이 만든 테이블·필드 사용
• UI 의존성: F3가 F1이 만든 페이지·컴포넌트 위에 동작
• 순서 의존성 아님: 단순히 "먼저 하고 싶다"는 우선순위로 표기, 의존성에 넣지 말 것

Phase 7: Goal 실행 순서 권고

위상 정렬(topological sort) 후 동일 레벨에서:

1. P0 우선
2. 독립 기능(빠른 win) 우선
3. 복잡도 낮은 것 우선

Phase 8: 안내

사용자에게 안내:

• 분해된 기능 수와 Goal 실행 순서 요약
• ❌(추가 분해 필요) 기능이 있으면 명시
• 다음 단계: /spec {프로젝트명}-F{N} 또는 /goal F{N}

---

--quick / 기본 / --thorough 깊이

• --quick (~1분): 기능 표 + 의존성 그래프만, 상세 섹션 생략
• 기본 (~3분): 위 템플릿 전체
• --thorough (~10분): 각 기능에 Acceptance 기준 5개+, 리스크/대안 1개씩 추가

---

작업 원칙

• PRD를 넘는 추측 금지: PRD에 없는 기능을 임의로 추가하지 않는다. 추론이 필요하면 [NEEDS CLARIFICATION]으로 표기.
• 분해 깊이는 Goal 단위에 맞춘다: 더 잘게 쪼갤 수 있어도 Goal 1 루프 단위면 거기서 멈춘다. 과분해는 오히려 의존성을 늘린다.
• 우선순위 충돌 시 사용자 확인: PRD와 추론이 다르면 임의 결정하지 않는다.
• breakdown.md만 작성: 스펙·코드 작성하지 않는다. 스펙은 /spec이, 구현은 /goal(또는 /run)이 담당.

---

다음 단계

/breakdown 완료 후:

1. /spec {프로젝트명}-F{N} — 각 P0 기능부터 기술 명세 작성
2. /goal F{N} — 기능 1개 단위로 빌드/테스트/시각확인 1 루프
3. 모든 Goal 완료 후 /complete — 정리

기능 1개뿐인 PRD라면 /breakdown 생략하고 /spec으로 직행해도 무방.