/cc-product:gate — 단계 통과 검사(품질 검문소)#
| 항목 | 내용 |
|---|---|
| 실행 명령 | /cc-product:gate |
| 분류 | 워크플로우 |
| 난이도 | ●●○ 보통 |
한마디로#
각 작업 단계를 다음으로 넘기기 전에 "통과해도 되는지" 점검하는 검문소입니다. 공항 보안 검색대처럼, 조건을 다 통과해야만 다음 게이트로 들어갈 수 있어요.
누가·언제 쓰나요#
- 지금 어느 게이트가 막혀 있는지 상태만 확인하고 싶을 때
- 게이트에서 한 번 떨어진 뒤, 지적사항을 고치고 다시 검사받고 싶을 때
- 특정 단계의 통과 조건을 콕 집어 확인하고 싶을 때
무엇을 해주나요#
네 단계(분석 / 기획 / 설계 / 구현)의 통과 조건을 점검하고, 결과를 한눈에 보이는 표 형태로 알려줍니다.
- 통과하면 "PASSED"와 함께 다음 단계로 넘어가도 된다고 안내
- 떨어지면 "FAILED"와 함께 무엇이 문제인지, 어떻게 고쳐야 하는지, 어떤 명령으로 재검사하는지까지 알려줌
--all을 쓰면 전체 게이트의 통과/대기/실패 현황을 한 장으로 요약
어떻게 쓰나요#
# 특정 단계 게이트 검사하기
/cc-product:gate --phase analysis
/cc-product:gate --phase planning
/cc-product:gate --phase solutioning
/cc-product:gate --phase implementation
# 지적사항을 고친 뒤 다시 검사받기
/cc-product:gate --phase solutioning --retry
# 전체 게이트 현황 한눈에 보기
/cc-product:gate --all--phase또는--all중 하나는 반드시 필요합니다.- 더 자세한 결과를 보고 싶으면
--verbose를 덧붙이세요.
안에서 무슨 일이 벌어지나요#
각 단계마다 정해진 점검 항목을 하나씩 확인합니다.
- 분석 게이트 — 요구사항이 명확하고 측정 가능한지, 이슈 하나로 적당한 크기인지, 테스트로 검증할 수 있는지 확인합니다.
- 기획 게이트 — 요청 규모에 맞는 이슈 계층(Initiative/Project/Epic/Feature/Bug/Task)이 만들어졌는지, 작업 크기(스토리 포인트)가 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
/cc-product:gate --phase analysis
/cc-product:gate --phase planning
/cc-product:gate --phase solutioning
/cc-product:gate --phase implementationRe-verification Request#
# Re-verify after applying feedback
/cc-product:gate --phase solutioning --retryCheck All Gates#
# Check overall gate status
/cc-product:gate --allOptions#
| 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:
- issue_hierarchy_structure:
description: " Is the hierarchy structure appropriate for the request scale (Initiative/Project/Epic/Feature/Bug/Task)? "
- 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 # recommendedImplementation 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: ║
║ /cc-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: /cc-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 requiredRelated Commands#
/cc-product:bmad- Full BMAD workflow/cc-product:review- Persona-specific review/cc-product:bmad-status- Status check
Related Documents#
.claude/orchestrators/phase-gates.md- Detailed gate definitions.claude/personas/- Per-persona review criteria