Pipeline Orchestrator#

한마디로 (비개발자용)#

이 문서는 제품을 처음 아이디어부터 출시까지 만드는 과정을, 마치 공장의 컨베이어 벨트처럼 7개의 정해진 단계(발견 → 출시)로 자동 진행해 주는 "총괄 진행자(orchestrator)" 설명서입니다. 요리에 비유하면, 재료 준비부터 손질·조리·플레이팅·서빙까지의 순서를 정리해 둔 레시피이자, 각 단계가 끝날 때마다 "다음 단계로 넘어가도 될 만큼 잘 됐는지" 검사하는 체크포인트(gate)를 두어 품질을 지키는 매니저 역할을 합니다. 각 단계의 결과물(artifact)은 파일로 차곡차곡 저장되므로, 중간에 대화를 새로 시작해도 작업 내용이 사라지지 않습니다. 개발자가 아니어도 "지금 어느 단계까지 왔고, 무엇이 만들어졌는지"를 한눈에 따라갈 수 있도록 돕는 안내서라고 보시면 됩니다.

무엇을·언제 (비개발자용)#

무엇을 해 주나요

• 제품을 만드는 전 과정을 7단계(발견 → 사양 정의 → 기획 → 설계 → 뼈대 만들기 → 일감 생성 → 개발 → 출시)로 나눠 순서대로 자동으로 진행해 줍니다.
• 각 단계마다 알맞은 도구(플러그인)를 알아서 불러와 일을 시키고, 그 단계의 결과물을 docs/ 폴더에 파일로 저장해 둡니다.
• 단계를 넘어가기 전에 "충분히 잘 됐는지" 검사하는 관문(gate)을 두어 품질을 챙기고, 앞 단계의 결과를 다음 단계로 자동으로 넘겨 줍니다.
• 프로젝트가 작으면 불필요한 단계는 건너뛰자고 제안하고, 건너뛸 때는 항상 사용자에게 먼저 확인합니다.
• 지금 어느 단계까지 왔는지, 무엇이 만들어졌는지 한눈에 보여 주는 진행 현황판을 제공합니다.

언제 작동하나요

• "프로젝트 시작", "새 프로젝트", "전체 파이프라인" 같은 말을 했을 때
• /product 명령을 실행했을 때
• 분석 → 사양 검증 → 기획 → 설계 → 개발 → 출시까지 전체 흐름이 필요할 때
• 흩어져 있는 여러 도구(플러그인)를 하나의 흐름으로 묶어 진행해야 할 때

핵심 용어 사전 (비개발자용)#

Triggers#

• When keywords like "start project", "new project", "full pipeline" are mentioned
• When the /product command is invoked
• When the full flow of analysis → spec verification → planning → design → development → launch is needed
• When orchestration connecting existing plugins is needed

Behavior#

1. Project Initialization#

• Generate project slug (kebab-case)
• Create .pipeline/{slug}.yaml state file
• Determine BMAD project level (Level 0-4)

2. Stage Execution Flow#

Discovery → Specification → Planning → Design → Scaffold → Epic Creation → Development → Launch
    │            │             │          │          │           │              │           │
    ▼            ▼             ▼          ▼          ▼           ▼              ▼           ▼
 pm+bmad      cc-spec-      bmad+pm     bmad      cc-bricks    cc-dev-cycle   cc-dev-cycle  pm
 (research)   clarity       (plan/biz)  (arch/ux) +cc-flutter  +bmad(story)   +bmad(dev)    (gtm/anal)
              (외부)                                (외부)       (외부)          (외부)

내부 역량(bmad persona·커맨드, pm 기법)은 cc-product 자체가 단계별로 dispatch. 외부 플러그인만 위임: cc-spec-clarity(Spec) · cc-bricks-feature/cc-flutter-dev(Scaffold) · cc-dev-cycle(Epic/Dev).

3. Per Stage Execution#

1. Check previous artifacts: Verify previous stage artifacts exist
2. Evaluate skip conditions: Determine skippability based on project level/type
3. Delegate to source plugins: Invoke the stage's skills/commands in order
4. Gate verification: Verify gate passage (Specification, Analysis, Solutioning, Planning, Implementation)
5. Save artifacts: Store results in docs/ directory
6. Update state: Refresh .pipeline/{slug}.yaml

4. Inter-stage Data Passing#

• Automatically pass previous stage artifact paths to next stage
• Discovery → Specification: Research results, vision
• Specification → Planning: Seed spec, ambiguity evaluation, decision log
• Planning → Design: PRD, technical specification, BDD Acceptance Criteria
• Design → Scaffold: Architecture doc, UX spec, PRD (acceptance criteria)
• Scaffold → Epic: Scaffolded feature list, .feature file paths, test file paths
• Epic → Development: Epic/Story issue numbers (Stories reference scaffolded code + step stubs as DoD)
• Development → Launch: Deployed feature list

5. Skip Rules#

• Discovery skip: BMAD Level 0-1 (small-scale feature addition for existing product)
• Specification skip: BMAD Level 0-1 (small-scale feature addition for existing product)
• Scaffold skip: BMAD Level 0-1 (hotfix, minor feature without new code structure)
• Launch skip: Internal features, minor improvements, infrastructure changes
• User confirmation: Always confirm with user when skipping

6. State File Format (.pipeline/{slug}.yaml)#

project:
  name:  " Community Feature " 
   slug: community
  level: 3
  created: 2025-01-15T10:00:00Z
  updated: 2025-01-16T14:30:00Z

stages:
  discovery:
    status: completed        # pending | in-progress | completed | skipped
    started: 2025-01-15T10:00:00Z
    completed: 2025-01-15T12:00:00Z
    artifacts:
      - docs/discovery-community.md
    skip_reason: null

  specification:
    status: completed
    started: 2025-01-15T13:00:00Z
    completed: 2025-01-15T14:00:00Z
    gate: specification
    artifacts:
      - docs/seed-spec-community.md
      - docs/socratic-discovery-community.md

  planning:
    status: in-progress
    started: 2025-01-15T14:00:00Z
    gate: analysis           # Current gate
    artifacts: []

  design:
    status: pending
  epic:
    status: pending
  development:
    status: pending
  launch:
    status: pending

7. Context-Clear Handoff#

Each stage produces persistent artifacts in docs/. Between stages, offer the user a context-clear handoff to maximize token efficiency:

Stage {N} complete. Artifacts saved:
  - docs/{artifact}-{slug}.md

**Option 1 (Recommended)**: Clear context and continue to next stage
  /clear
  Then run: /product:{next_stage} docs/{artifact}-{slug}.md

**Option 2**: Continue in current context
  Proceed directly to /product:{next_stage}

Why context-clear matters:

• Each stage can consume significant context window (Socratic interviews, architecture reviews, etc.)
• Artifacts persist in docs/ and .pipeline/{slug}.yaml, so no information is lost
• Next stage reads previous artifacts from files, not from conversation history
• Fresh context allows the next stage to operate at full capacity

Rules:

• Always present Option 1 first (recommended)
• Include the exact artifact file paths so the user can reference them after /clear
• The pipeline state file .pipeline/{slug}.yaml tracks progress across context clears
• If the user chooses Option 2, proceed normally in the same context

Output#

• Project status dashboard (progress by stage)
• Each stage's artifacts (docs/ directory)
• .pipeline/{slug}.yaml state tracking file
• Summary report on stage transitions

Notes#

• Orchestrates from above without modifying existing plugins
• Gates serve as quality checkpoints (specification, analysis, planning, solutioning, implementation)
• Personas serve as reviewers at each stage (Analyst, Architect, PM, etc.)
• Users can independently execute any stage if desired
• Stage-to-source command mappings managed in config/stage-mapping.yaml