product:gate

Manual BMAD phase gate verification

항목	내용
Invoke	/gate
Category	workflow
Complexity	moderate

/product:gate — 단계 통과 검사(품질 검문소)#

한마디로#

각 작업 단계를 다음으로 넘기기 전에 "통과해도 되는지" 점검하는 검문소입니다. 공항 보안 검색대처럼, 조건을 다 통과해야만 다음 게이트로 들어갈 수 있어요.

누가·언제 쓰나요#

지금 어느 게이트가 막혀 있는지 상태만 확인하고 싶을 때
게이트에서 한 번 떨어진 뒤, 지적사항을 고치고 다시 검사받고 싶을 때
특정 단계의 통과 조건을 콕 집어 확인하고 싶을 때

무엇을 해주나요#

네 단계(분석 / 기획 / 설계 / 구현)의 통과 조건을 점검하고, 결과를 한눈에 보이는 표 형태로 알려줍니다.

통과하면 "PASSED"와 함께 다음 단계로 넘어가도 된다고 안내
떨어지면 "FAILED"와 함께 무엇이 문제인지, 어떻게 고쳐야 하는지, 어떤 명령으로 재검사하는지까지 알려줌
--all을 쓰면 전체 게이트의 통과/대기/실패 현황을 한 장으로 요약

어떻게 쓰나요#

# 특정 단계 게이트 검사하기
/product:gate --phase analysis
/product:gate --phase planning
/product:gate --phase solutioning
/product:gate --phase implementation

# 지적사항을 고친 뒤 다시 검사받기
/product:gate --phase solutioning --retry

# 전체 게이트 현황 한눈에 보기
/product:gate --all

--phase 또는 --all 중 하나는 반드시 필요합니다.
더 자세한 결과를 보고 싶으면 --verbose를 덧붙이세요.

안에서 무슨 일이 벌어지나요#

각 단계마다 정해진 점검 항목을 하나씩 확인합니다.

분석 게이트 — 요구사항이 명확하고 측정 가능한지, 이슈 하나로 적당한 크기인지, 테스트로 검증할 수 있는지 확인합니다.
기획 게이트 — Epic·Story 구조가 적절한지, 작업 크기(스토리 포인트)가 1~8 범위인지, 라벨과 의존성이 정리됐는지 봅니다.
설계 게이트 — 아키텍트 관점(구조·보안 등)과 UX 관점(레이아웃·상호작용·접근성 등)을 나눠 검토합니다.
구현 게이트 — 브랜치 이름 규칙, 코드 검사(lint) 통과, PR 준비 상태를 확인합니다.

모든 게이트는 필수입니다. 떨어지면 다음 단계로 넘어갈 수 없고, 피드백을 반영해 다시 검사받아야 합니다. (긴급 모드는 관리자 승인이 있어야만 예외로 허용됩니다.)

⚙️ 상세 옵션·실행 명세 (개발자 / AI 에이전트용)

Triggers#

Manual gate status check
Re-verification after gate failure
Checking specific gate conditions

Usage#

Basic Usage#

# Verify a specific phase gate
/product:gate --phase analysis
/product:gate --phase planning
/product:gate --phase solutioning
/product:gate --phase implementation

Re-verification Request#

# Re-verify after applying feedback
/product:gate --phase solutioning --retry

Check All Gates#

# Check overall gate status
/product:gate --all

Options#

Option	Required	Description
`--phase`	⚠️*	Phase to verify
`--all`	⚠️*	Check all gates
`--retry`	❌	Re-verification mode
`--verbose`	❌	Detailed result output

*Either --phase or --all is required

Gate Verification Items#

Analysis Gate#

checks:
  - requirement_clarity:
      description:  " Are requirements specific and measurable? " 
   - scope_appropriateness:
      description:  " Is it an appropriate size for a single issue? " 
   - ac_testability:
      description:  " Are AC automatable for testing? "

Planning Gate#

checks:
  - epic_story_structure:
      description:  " Is the hierarchy structure appropriate? " 
   - story_point:
      description:  " Is it within 1-8 SP range? " 
       threshold: { min: 1, max: 8, split_required: 13 }
  - labeling:
      description:  " Are Type and Scope labels present? " 
   - dependencies:
      description:  " Are blockers resolvable? "

Solutioning Gate#

checks:
  architect:
    - clean_architecture
    - pure_di_wiring  # No getIt/injectable, direct BlocProvider creation
    - api_design  # when backend changes
    - security
  ux_designer:
    - coui_compliance  # recommended when the Co < X >   design system is in use; see cc-coui skill. Not a hard block.
    - layout
    - interaction
    - accessibility  # recommended

Implementation Gate#

sub_gates:
  - step_4_branch:
      pattern:  " ^(feature|fix|refactor|chore)/[0-9]+ " 
   - step_8_5_lint:
      commands: [ " dart analyze " ,  " dcm analyze " ]
  - step_9_pr:
      checks: [branch_format, issue_linked, commits_exist, lint_passed]

Output Format#

Gate Passed#

╔════════════════════════════════════════════════════════════════╗
║  Analysis Gate: ✅ PASSED                                      ║
╠════════════════════════════════════════════════════════════════╣
║                                                                ║
║  ✅ Requirements clarity: PASS                                       ║
║     - 3 functional requirements identified                                    ║
║     - Success criteria clear                                           ║
║                                                                ║
║  ✅ Scope appropriateness: PASS                                         ║
║     - Expected complexity: Medium (3-5 SP)                               ║
║     - Appropriate for a single issue                                         ║
║                                                                ║
║  ✅ Acceptance Criteria Testability: PASS                        ║
║     - 3 Acceptance Criteria defined                            ║
║     - All convertible to BDD scenarios                            ║
║                                                                ║
║  → Ready to proceed to Planning phase                                 ║
║                                                                ║
╚════════════════════════════════════════════════════════════════╝

Gate Failed#

╔════════════════════════════════════════════════════════════════╗
║  Solutioning Gate: ❌ FAILED                                   ║
╠════════════════════════════════════════════════════════════════╣
║                                                                ║
║  🏗️ Architect review: ❌ FAILED                                  ║
║  ├── ✅ Clean Architecture                                     ║
║  ├── ❌ Dependency wiring: getIt usage found (Pure DI violation)         ║
║  ├── ✅ API Design (N/A)                                       ║
║  └── ✅ Security                                               ║
║                                                                ║
║  🎨 UX Designer review: ✅ PASSED                                ║
║  ├── ✅ CoUI compliance                                              ║
║  ├── ✅ Layout                                               ║
║  ├── ✅ Interaction                                               ║
║  └── ⚠️ Accessibility (recommended)                                          ║
║                                                                ║
║  Gate result: FAILED (Architect review failed)                     ║
║                                                                ║
║  Required actions:                                                  ║
║  1. Change to direct creation in BlocProvider:                        ║
║     create: (_) = >   AuthorBloc()                                ║
║                                                                ║
║  Re-verification command:                                                  ║
║  /product:gate --phase solutioning --retry                        ║
║                                                                ║
║  ⚠️ Cannot proceed to Implementation phase.                ║
║                                                                ║
╚════════════════════════════════════════════════════════════════╝

Overall Gate Status#

╔════════════════════════════════════════════════════════════════╗
║  BMAD Gate Status (All)                                       ║
╠════════════════════════════════════════════════════════════════╣
║                                                                ║
║  Analysis Gate:       ✅ PASSED                                ║
║  Planning Gate:       ✅ PASSED                                ║
║  Solutioning Gate:    ❌ FAILED (Architect - Pure DI violation)     ║
║  Implementation Gate: ⏳ PENDING                               ║
║                                                                ║
║  Current blocker: Solutioning Gate                                 ║
║  Next action: /product:gate --phase solutioning --retry            ║
║                                                                ║
╚════════════════════════════════════════════════════════════════╝

Mandatory Gate Policy#

⚠️ Important: All gates are mandatory.

On gate failure:
├── Cannot proceed to next phase
├── Feedback provided
└── Re-verification required

Exception:
├── Emergency mode (--emergency)
│   └── Admin approval required
└── Post-review required

/product:bmad - Full BMAD workflow
/product:review - Persona-specific review
/product:bmad-status - Status check

.claude/orchestrators/phase-gates.md - Detailed gate definitions
.claude/personas/ - Per-persona review criteria