한마디로 (비개발자용)#
cc-product은 제품 하나를 처음 아이디어부터 출시까지 데려가는 "조립 라인 관리자"예요. 공장에서 원재료가 여러 작업대를 순서대로 거쳐 완성품이 되듯, 이 도구는 프로젝트를 7개의 단계(발견 → 명세 → 기획 → 설계 → 작업 묶음 만들기 → 개발 → 출시)를 차례로 통과시킵니다. 각 단계 사이에는 "품질 검문소(Gate)"가 있어서, 기준을 통과해야 다음 단계로 넘어갈 수 있어요. 이미 만들어 둔 여러 전문 도구들을 위에서 지휘하기만 할 뿐, 그 도구들을 직접 고치지는 않습니다.
핵심 용어 사전 (비개발자용)#
| 용어 | 쉬운 설명 |
|---|---|
| orchestration (오케스트레이션) | 여러 도구를 지휘자처럼 위에서 조율해 순서대로 일을 시키는 것. 직접 일을 바꾸지 않고 흐름만 지휘합니다. |
| slug (슬러그) | 프로젝트를 구분하는 짧은 이름표(예: community). 파일 이름 등에 붙어 어느 프로젝트 것인지 알려줍니다. |
| BMAD Level (BMAD 레벨) | 일의 규모를 0~4로 나눈 등급. 숫자가 작으면 간단한 수정, 크면 새 프로젝트라 거치는 단계 수가 달라집니다. |
| gate (게이트, 검문소) | 다음 단계로 넘어가도 되는지 확인하는 품질 검문소. 기준을 통과해야 진행됩니다. |
| artifact (아티팩트, 산출물) | 각 단계가 끝나면 남는 결과물 문서나 파일(예: 기획서, 설계도). |
| persona (페르소나) | 특정 역할(예: 설계자, UX 디자이너) 입장에서 일하도록 설정한 가상의 전문가 캐릭터. |
| Seed spec (시드 스펙) | 흔들리지 않게 고정해 둔 핵심 명세서. 이후 작업이 기준으로 삼는 '씨앗' 같은 기본 설계입니다. |
| Socratic interview (소크라테스식 인터뷰) | 질문을 꼬리에 꼬리를 물고 던져 숨은 가정을 끄집어내는 대화 방식. |
| ambiguity score (모호성 점수) | 명세가 얼마나 애매한지를 숫자로 잰 값. 낮을수록 명확하다는 뜻입니다. |
| contrarian (반대자) | 일부러 반대 입장에서 허점을 찌르며 검토하는 역할. |
| simplifier (단순화 담당) | 불필요하게 복잡한 부분을 덜어내 단순하게 만드는 역할. |
| PRD (제품 요구사항 명세서) | Product Requirements Document. 무엇을 왜 만들지 정리한 제품 기획 문서. |
| BDD (행위 주도 개발) | Behavior-Driven Development. "이런 상황에서 이렇게 동작해야 한다"는 식으로 사람이 읽기 쉬운 문장으로 기대 동작을 적는 방식. |
| Acceptance Criteria (인수 기준) | "이 조건들을 만족하면 완성으로 인정한다"고 미리 정해 둔 합격 기준. |
| Epic (에픽) | 여러 작업으로 쪼개지는 큰 단위의 일감 묶음. |
| Story (스토리) | 에픽을 잘게 나눈 하나하나의 작은 작업 단위. |
| ZenHub (젠허브) | 일감(에픽·스토리)을 만들고 진행 상황을 추적하는 프로젝트 관리 도구. |
| GTM (시장 진입 전략) | Go-to-Market. 제품을 어떻게 알리고 시장에 내놓을지에 대한 출시 전략. |
Overview#
cc-product is an orchestration plugin that manages the Cocode team's project lifecycle through a 7-stage pipeline. It coordinates existing plugins (cc-product, cc-spec-clarity, cc-product, cc-dev-cycle) from above without modifying them.
Pipeline Flow#
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Discovery │───▶│Specification│───▶│ Planning │───▶│ Design │
│ (Analysis) │ │(Spec Verify)│ │ (Planning) │ │ (Design) │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
│ │ │
Specification Analysis Gate Solutioning Gate
Gate │ │
│ ┌─────────────┐ ┌─────────────┐
│ │ Launch │◀───│ Development │
│ │ (Launch) │ │(Development)│
│ └─────────────┘ └─────────────┘
│ │
┌─────────────┐ │ Implementation
│Epic Creation│───────────┘ Gate
│ (Creation) │
└─────────────┘
│
Planning Gate
Getting Started#
New Project#
/product " project description "
This command:
- Generates project slug
- Automatically determines BMAD level
- Sequentially executes 7 stages (skippable stages auto-determined)
Individual Stage Entry#
Each stage can be executed independently:
/product:discover " feature description "
/product:specify " feature description "
/product:plan
/product:design
/product:epic
/product:develop --epic 42
/product:launch
Previous stage artifacts are automatically referenced if available.
Stage Details#
Stage 1: Discovery (Analysis)#
Performs user research, competitive analysis, and ideation.
- Source: cc-product, cc-product, cc-product
- Artifacts:
docs/discovery-{slug}.md - Skip: Level 0-1
Stage 2: Specification (Spec Verification)#
Exposes hidden assumptions through Socratic interviews, then creates Seed specs and ambiguity evaluation to secure implementation-quality specifications.
-
Source: cc-spec-clarity (
/spec:interview,/spec:seed,/spec:ambiguity,/spec:evaluate) - Agents: contrarian (contrarian review), simplifier (complexity reduction) — parallel execution
- Gate: Specification Gate
-
Artifacts:
docs/seed-spec-{slug}.md,docs/socratic-discovery-{slug}.md,docs/decision-log-{slug}.md,docs/spec-evaluation-{slug}.md - Skip: Level 0-1
Stage 3: Planning#
Writes product briefs, PRD/technical specifications, and defines BDD Acceptance Criteria.
- Source: cc-product, cc-product
- Gate: Analysis Gate
-
Artifacts:
docs/prd-{slug}.md,docs/tech-spec-{slug}.md,docs/bdd-{slug}.md
Stage 4: Design#
Designs architecture and UX, then performs parallel review.
- Source: cc-product (Architect + UX Designer personas)
- Gate: Solutioning Gate
-
Artifacts:
docs/architecture-{slug}.md,docs/ux-spec-{slug}.md - Skip: Level 0
Stage 5: Epic Creation#
Creates ZenHub Epics and Stories based on design artifacts.
- Source: cc-dev-cycle, cc-product
- Gate: Planning Gate
- Artifacts: ZenHub Epic + linked Stories
- Skip: Level 0
Stage 6: Development#
Iterates through Stories within an Epic, executing the 13-step development cycle for each.
- Source: cc-dev-cycle, cc-product
- Gate: Implementation Gate (per Story)
- Artifacts: Implementation code + PR
-
Parallel mode:
--paralleloption for parallel development of independent Stories via Agent Teams
Stage 7: Launch#
Establishes GTM strategy, messaging, and analytics plan.
- Source: cc-product, cc-product
-
Artifacts:
docs/gtm-{slug}.md,docs/analytics-plan-{slug}.md - Skip: Level 0-1
BMAD Level Guide#
Level 0: Hotfix (Simple Bug Fix)#
Planning → Development
Skips Discovery, Specification, Design, Epic Creation, and Launch.
Level 1: Minor Feature (Small-scale Feature Addition)#
Planning → Design → Epic Creation → Development
Skips Discovery, Specification, and Launch.
Level 2-3: Feature / Major Feature#
Discovery → Specification → Planning → Design → Epic Creation → Development → Launch
Executes the full pipeline.
Level 4: New Project#
Discovery (deep) → Specification → Planning → Design → Epic Creation → Development → Launch
Executes Discovery in deep mode.
Gates#
Each gate is a quality checkpoint.
Specification Gate (Specification → Planning)#
- Ambiguity score ≤ 0.2
- Convergence ≥ 0.95
- Contrarian unresolved Critical: 0
- Consensus: 3/3 unanimous
Analysis Gate (Planning → Design)#
- Requirement clarity
- Scope appropriateness
- Acceptance Criteria testability
Solutioning Gate (Design → Epic Creation)#
- Architect: Clean Architecture, DI, API, security
- UX Designer: CoUI, layout, interaction, accessibility
Planning Gate (Epic Creation → Development)#
- Epic/Story structure
- Story points
- Labeling
- Dependencies
Implementation Gate (Development, per Story)#
- Lint passed
- Tests passed
- Code review passed
- Branch naming convention
State Management#
Pipeline state is stored in .pipeline/{slug}.yaml.
# Check status
/product:status
# Specific project
/product:status community
# All projects
/product:status --all
Artifact Management#
All artifacts are stored in the project's docs/ directory:
| Stage | Artifacts |
|---|---|
| Discovery | docs/discovery-{slug}.md |
| Specification |
docs/seed-spec-{slug}.md
,
docs/socratic-discovery-{slug}.md
,
docs/decision-log-{slug}.md
,
docs/spec-evaluation-{slug}.md
|
| Planning |
docs/prd-{slug}.md
,
docs/tech-spec-{slug}.md
,
docs/bdd-{slug}.md
|
| Design | docs/architecture-{slug}.md, docs/ux-spec-{slug}.md |
| Epic Creation | ZenHub Epic + Stories (issue numbers) |
| Development | Implementation code + PR |
| Launch | docs/gtm-{slug}.md, docs/analytics-plan-{slug}.md |
Suspend and Resume#
The pipeline can be suspended and resumed at any time:
# Check status after suspension
/product:status community
# Resume from Design stage
/product --from design " community feature "
The state file records the last position, so previous artifacts are automatically referenced.
Dependent Plugins#
| Plugin | Stages Used | Role |
|---|---|---|
| cc-product | 1, 3-6 | Methodology, gates, personas |
| cc-spec-clarity | 2 | Spec clarity verification, Specification Gate |
| cc-product | 1 | User research |
| cc-product | 1, 3 | Product strategy |
| cc-product | 7 | Go-to-Market |
| cc-product | 7 | Data analytics |
| cc-dev-cycle | 5-6 | Development cycle |