LogoSkills

product

조사→명세→기획→설계→준비→개발→출시 전 단계를 순서대로 자동 진행하며 `.pipeline/*.yaml` 에 상태를 기록합니다 — Breakdown 직후와 Launch 직후 두 번, 생성 문서를 PR 로 기본 브랜치에 합칩니다.

/product — 프로젝트 전 과정 한 번에 돌리기#

항목내용
실행 명령/cc-product:product
분류파이프라인
난이도●●● 높음

프로젝트 설명 한 줄만 주면, 조사부터 출시까지 7단계 전체를 순서대로 진행합니다.

한마디로#

기능 하나를 "조사 → 명세 → 기획 → 설계 → 준비 → 개발 → 출시"까지, 정해진 순서대로 자동으로 밀어주는 종합 진행 버튼입니다. 집을 짓는 데 비유하면, 부지 조사부터 입주까지 전 공정을 한 명의 총괄 감독이 단계별로 챙겨 주는 것과 같아요.

누가·언제 쓰나요#

  • 새 프로젝트를 처음부터 끝까지 한 번에 진행하고 싶을 때
  • 여러 단계를 따로따로 부르지 않고, 전체 흐름을 한 번에 맡기고 싶을 때

👉 프로젝트 규모(난이도)에 따라 일부 단계는 자동으로 건너뜁니다. 예를 들어 작은 버그 수정은 조사·명세·출시 단계를 생략합니다.

무엇을 해주나요#

프로젝트 진행 상태를 .pipeline/(프로젝트이름).yaml 파일에 기록하면서, 각 단계가 끝날 때마다 결과물이 차곡차곡 쌓입니다. 대표적으로:

  • 조사 결과 — docs/discovery-(프로젝트이름).md
  • 명세 결과 — docs/seed-spec-(프로젝트이름).md 등
  • 기획 결과 — PRD/기술 명세 + BDD 인수 조건
  • 설계 결과 — 아키텍처 문서 + UX 명세
  • 개발 결과 — 구현 코드 + PR
  • 출시 전략 — docs/gtm-(프로젝트이름).md

이 문서들은 파일로만 남지 않습니다. 일감 생성(Breakdown)이 끝난 시점과 출시(Launch)가 끝난 시점, 두 번에 걸쳐 PR로 올라가 기본 브랜치에 합쳐집니다.

마지막에는 전체 파이프라인 요약 보고서를 정리해 줍니다.

어떻게 쓰나요#

# 전체 파이프라인
/product  " 커뮤니티 기능 개발 " 

 # 난이도(level) 지정 — 건너뛰기 규칙에 영향
/product --level 3  " 커뮤니티 기능 개발 " 

 # 특정 단계부터 시작
/product --from specify  " 커뮤니티 기능 개발 " 
 /product --from design  " 커뮤니티 기능 개발 " 

 # 특정 단계까지만 진행
/product --to breakdown  " 커뮤니티 기능 개발 "
  • --level : BMAD 프로젝트 난이도(0~4). 비워 두면 자동으로 판단합니다.
  • --from : 어느 단계부터 시작할지. 중간에 멈췄던 작업을 이어서 할 때도 사용합니다.
  • --to : 어느 단계까지만 진행할지.
  • --skip : 건너뛸 단계를 쉼표로 나열합니다.

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

각 단계가 끝날 때마다 결과물을 확인하고, 다음 단계로 넘어가기 전에 사용자에게 한 번씩 확인을 받습니다.

  1. 준비 — 프로젝트 이름(슬러그)을 만들고, 난이도를 자동 판단한 뒤 상태 파일과 docs/ 폴더를 준비합니다.
  2. 조사(Discovery) — 사용자·시장·아이디어를 조사합니다. (작은 작업이면 생략)
  3. 명세(Specification) — 무엇을 만들지 모호함 없이 못 박습니다. (작은 작업이면 생략)
  4. 기획(Planning) — 제품 브리프·PRD/기술 명세와 인수 조건을 정리합니다.
  5. 설계(Design) — 아키텍처와 UX를 설계합니다.
  6. 준비(Scaffold) — 코드 뼈대와 테스트 틀을 자동으로 만들어 둡니다. (작은 작업이면 생략)
  7. 이슈 분해(Breakdown) — 규모를 보고 ZenHub에 (필요시) Epic과 Feature/Bug/Task를 만들고 스프린트를 계획합니다. 여기까지 만들어진 문서를 PR 로 올려 기본 브랜치에 합칩니다 — 다음 개발 단계가 문서가 들어 있는 기준점에서 시작하도록.
  8. 개발(Development) — 작업 항목을 하나씩 실제로 구현하고 PR을 만듭니다. (이때 생기는 문서는 그 코드 PR에 함께 실려 갑니다)
  9. 출시(Launch) — 시장 진입 전략·메시징을 준비하고, 그 문서도 같은 방식으로 PR로 합칩니다. (내부 기능이면 생략)
  10. 마무리 — 상태 파일을 갱신하고 전체 요약 보고서를 출력합니다.

중간에 게이트(품질 관문) 통과 실패나 중단이 생기면, 마지막 위치를 기록해 두었다가 --from 옵션으로 다시 이어서 진행할 수 있습니다.

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

Triggers#

  • When progressing a new project from start to finish
  • When full lifecycle orchestration is needed

Usage#

# Full pipeline
/product  " Community feature development " 

 # Specify level (affects skip rules)
/product --level 3  " Community feature development " 

 # Start from a specific stage
/product --from specify  " Community feature development " 
 /product --from design  " Community feature development " 

 # Up to a specific stage only
/product --to breakdown  " Community feature development "

Parameters#

ParameterRequiredDescriptionExample
description✅Project description"Community feature development"

Options#

OptionDefaultDescription
--levelAuto-determinedBMAD project level (0-4)
--fromdiscoveryStarting stage
--tolaunchEnding stage
--skipNoneStages to skip (comma-separated)

Execution Flow#

Step 1: Project Initialization#

  1. Generate slug from project description (kebab-case)
  2. Auto-determine BMAD project level
    • Level 0: Simple bug fix → Skip Discovery/Specification/Launch
    • Level 1: Small-scale feature addition → Skip Discovery/Specification
    • Level 2: Medium-scale feature → Full execution
    • Level 3: Large-scale feature/new module → Full execution
    • Level 4: New project → Full execution (deep)
  3. Create .pipeline/{slug}.yaml state file
  4. Verify/create docs/ directory

Step 2: Discovery (Analysis)#

Skip condition: Level 0-1

→ /cc-product:discover  " {description} "
  • cc-product: User interview, assumption validation, experiment design
  • cc-product: Competitive analysis, vision formulation
  • cc-product: /cc-product:research, /cc-product:brainstorm
  • Artifacts: docs/discovery-{slug}.md

Step 3: Specification (Spec Verification)#

Skip condition: Level 0-1

→ /cc-product:specify  " {description} "
  • cc-spec: Socratic interview, Seed spec, ambiguity evaluation
  • cc-spec: Contrarian review + Simplifier simplification (parallel)
  • cc-spec: 3-stage evaluation (mechanical/semantic/consensus)
  • Gate: Specification Gate (ambiguity ≤ 0.2, convergence ≥ 0.95, Contrarian 0, consensus 3/3)
  • Artifacts: docs/seed-spec-{slug}.md, docs/socratic-discovery-{slug}.md, docs/decision-log-{slug}.md, docs/spec-evaluation-{slug}.md

Step 4: Planning#

→ /cc-product:plan
  • cc-product: /cc-product:product-brief, /cc-product:prd or /cc-product:tech-spec
  • cc-product: Business model
  • cc-product Analyst: Requirements analysis, BDD Acceptance Criteria
  • Gate: BMAD Analysis Gate
  • Artifacts: PRD/Tech Spec + BDD Acceptance Criteria

Step 5: Design#

→ /cc-product:design
  • cc-product: /cc-product:architecture, /cc-product:create-ux-design
  • cc-product Architect + UX Designer: Parallel review
  • Gate: BMAD Solutioning Gate
  • Artifacts: Architecture Doc + UX Spec

Step 5.5: Scaffold#

Skip condition: Level 0-1

→ /cc-product:scaffold
  • cc-bricks: Mason brick scaffolding per feature (co-bricks)
  • cc-flutter: /cc-flutter:bdd:generate for each feature + co-test-gen build_runner
  • Gate: Scaffold Gate (brick output, .feature files, test gen, step stubs)
  • Artifacts: Scaffolded feature directories, .feature files, widget + patrol test stubs

Step 6: Issue Breakdown#

→ /cc-product:breakdown
  • cc-dev: /cc-dev:zenhub:breakdown (scale auto-inferred — Initiative/Project/Epic/Feature-Bug-Task/Sub-task)
  • cc-product: /cc-product:create-story, /cc-product:sprint-planning
  • cc-product PM: Story points, labeling
  • Gate: BMAD Planning Gate
  • Then: DOCS — planning docs PR (references/helpers.md → Publish Pipeline Docs PR), merged before Step 7 branches
  • Artifacts: ZenHub Epic (optional) + linked work items (Feature/Bug/Task) + merged planning docs PR

Step 7: Development#

→ /cc-product:develop {epic_number}
  • Iterate through work items within Epic, execute cc-dev 13 steps for each
  • cc-product: /cc-product:dev-story
  • cc-product Flutter/Backend Dev: Implementation review
  • Gate: BMAD Implementation Gate
  • Artifacts: Implementation code + PR

Step 8: Launch#

Skip condition: Internal features, minor improvements

→ /cc-product:launch
  • cc-product: GTM strategy, ICP definition, messaging
  • cc-product: A/B testing, cohort analysis
  • Then: LDOC — launch docs PR (same helper)
  • Artifacts: docs/gtm-{slug}.md + merged launch docs PR

Step 9: Completion#

  • Final state file update
  • Full pipeline summary report output
  • Artifact list cleanup

Stage Transitions#

After each stage completion:

  1. Verify artifact existence
  2. Verify gate passage (if applicable)
  3. Update state file
  4. Request user confirmation before entering next stage

Error Handling#

  • Gate failure: Display failure reason, guide to retry after fix
  • Source plugin not installed: Warn and guide manual progression of that stage
  • Interruption: Record last position in state file, resume later with --from option