bmad:plan-technical-review

Technical review of PRD/Tech Spec before build — feasibility, risk, scope analysis with 3 parallel reviewers

항목	내용
Invoke	/bmad:plan-technical-review
Category	workflow
Complexity	medium

/bmad:plan-technical-review#

PRD/Tech Spec 문서의 기술적 실현 가능성, 리스크, 범위를 3개 병렬 리뷰어로 검증한다. Planning → Design 전환 전에 독립적으로 실행하거나, 파이프라인에서 자동 호출된다.

Triggers#

Planning 스테이지 완료 후 Design 진행 전 기술 검증이 필요할 때
PRD/Tech Spec의 기술적 리스크를 사전에 평가하고 싶을 때
Plan이 단일 PR로 적절한지 범위를 검증하고 싶을 때

Usage#

# 최근 plan 문서 자동 탐색
/bmad:plan-technical-review

# 특정 문서 지정
/bmad:plan-technical-review docs/prd-community.md

# Tech Spec 리뷰
/bmad:plan-technical-review docs/tech-spec-community.md

Parameters#

Parameter	Required	Description	Example
`plan_path`	⚠️	Plan 문서 경로 (없으면 최근 7일 내 문서 자동 탐색)	`docs/prd-community.md`

Options#

Option	Default	Description
`--skip-scope`	false	Scope 분석 건너뛰기 (소규모 변경 시)
`--verbose`	false	상세 분석 결과 출력

Execution Flow#

Phase 1: Plan Document Loading#

문서 탐색: docs/prd-*.md 또는 docs/tech-spec-*.md 중 최근 7일 내 파일 검색
- 1개 매치: 자동 사용
- 복수 매치: 사용자 선택 요청
- 0개 매치: /project:plan 먼저 실행 안내
문서 파싱: 제목, 요구사항, 기술 고려사항, AC, 의존성 추출

Phase 2: Parallel Review (3 Reviewers)#

3개 리뷰어가 동시에 실행되어 각각의 관점에서 plan을 분석한다.

Reviewer 1: Feasibility (기술적 실현 가능성)

검증 항목:
- [ ] 기술 스택 호환성: 현재 프로젝트의 패키지/프레임워크로 구현 가능한가?
- [ ] API 의존성: 외부 API가 필요한 경우 사용 가능한가? 비용은?
- [ ] 데이터 모델: 기존 DB 스키마와 충돌 없이 확장 가능한가?
- [ ] 성능 영향: 예상 사용량에서 성능 저하 없는가?
- [ ] 기존 코드 재사용: 유사 기능이 이미 존재하는가? (Grep 기반 탐색)

Output: FEASIBLE / FEASIBLE_WITH_RISKS / NOT_FEASIBLE

Reviewer 2: Risk (리스크 분석)

검증 항목:
- [ ] 보안 리스크: 인증/인가, 데이터 노출, 입력 검증 이슈
- [ ] 의존성 리스크: 외부 라이브러리 버전 충돌, deprecated API 사용
- [ ] 마이그레이션 리스크: 기존 데이터/스키마 변경 필요성
- [ ] 통합 리스크: 다른 모듈/서비스와의 통합 포인트
- [ ] 롤백 리스크: 배포 후 문제 시 롤백 가능한가?

Output per risk: HIGH / MEDIUM / LOW + 대응 방안

Reviewer 3: Scope (범위 분석)

검증 항목:
- [ ] 예상 변경 파일 수: 단일 PR 적합 범위인가? (guideline: ≤30 files)
- [ ] 레이어 수: 몇 개 레이어를 건드리는가? (Data, Domain, Presentation, Backend)
- [ ] 기능 분리 가능성: 논리적으로 독립 배포 가능한 단위가 있는가?
- [ ] 의존성 순서: 선행 작업이 필요한 부분이 있는가?

Split 판단 기준:

조건	결과
≤30 files, ≤2 layers	NO_SPLIT — 단일 PR 적합
30-60 files 또는 3 layers	CONSIDER_SPLIT — 분할 검토
>60 files 또는 4+ layers 또는 독립 기능 존재	RECOMMEND_SPLIT — 분할 권장

Split 권장 시 출력:

## Recommended Split

### Part 1: {title} (foundation)
- Files: {estimated count}
- Scope: {description}
- Dependencies: none

### Part 2: {title} (depends on Part 1)
- Files: {estimated count}
- Scope: {description}
- Dependencies: Part 1

Plan 파일명: docs/prd-{slug}-part-1.md, docs/prd-{slug}-part-2.md

Phase 3: Consolidation#

3개 리뷰 결과를 통합하여 최종 판정:

╔════════════════════════════════════════════════════════════════╗
║  Plan Technical Review: {PASS | NEEDS_ATTENTION | BLOCKED}    ║
╠════════════════════════════════════════════════════════════════╣
║                                                                ║
║  Feasibility:  {FEASIBLE | WITH_RISKS | NOT_FEASIBLE}         ║
║  Risk Level:   {LOW | MEDIUM | HIGH}                          ║
║  Scope:        {NO_SPLIT | CONSIDER_SPLIT | RECOMMEND_SPLIT}  ║
║                                                                ║
║  Key Findings:                                                 ║
║    {finding 1}                                                 ║
║    {finding 2}                                                 ║
║                                                                ║
║  Recommendations:                                              ║
║    {recommendation 1}                                          ║
║    {recommendation 2}                                          ║
║                                                                ║
╚════════════════════════════════════════════════════════════════╝

최종 판정 기준:

조건	판정
Feasible + Low Risk + No Split	PASS
With Risks 또는 Medium Risk 또는 Consider Split	NEEDS_ATTENTION — 사용자 확인 후 진행
Not Feasible 또는 High Risk	BLOCKED — 수정 후 재검토 필요

Phase 4: Handoff#

리뷰 완료 후 옵션 제시:

1. Clear context and build → /clear 후 /project:design
2. Start design → /project:design 바로 실행
3. Refine plan → 지적사항 반영 후 plan 수정
4. Split plan → 분할된 plan 파일 생성
5. Done → 리뷰 결과만 확인, 추가 작업 없음

Key Rules#

Non-blocking by default: NEEDS_ATTENTION은 사용자 확인 후 진행 가능 (BLOCKED만 차단)
Evidence-based: Grep/Glob으로 기존 코드를 실제 확인하여 판단
No false positives: 불확실한 리스크는 MEDIUM으로 분류, HIGH는 명확한 근거 필요
Scope > 분할 강제 금지: 무리한 분할보다 큰 단일 PR이 나을 수 있음. 의심스러우면 NO_SPLIT
독립 실행 가능: 파이프라인 없이도 독립적으로 /bmad:plan-technical-review 호출 가능

/project:plan — Plan 문서 생성
/project:design — 다음 스테이지 (Design)
/bmad:review --persona architect — 아키텍처 단독 리뷰
/spec:evaluate — 스펙 평가 (Specification 단계)