Triggers#

• When creating development issues after Design stage completion
• When splitting architecture/UX specs into actionable work units
• When the pipeline covers multiple features → create a Project-level issue wrapping the Epics (auto-inferred, or forced via --project-level)
• When the scope is small enough that no Epic wrapper is warranted (auto-inferred, or forced via --no-epic)

Usage#

/cc-product:breakdown
/cc-product:breakdown --sprint current
/cc-product:breakdown --feature community --entity Post
/cc-product:breakdown --project-level                       # Project 이슈 생성 후 Epic들을 하위로 연결 (자동 추론 오버라이드)
/cc-product:breakdown --parent-project 1024                  # 기존 Project 이슈에 Epic 연결
/cc-product:breakdown --no-epic                               # Epic 생략, Feature/Bug/Task만 생성 (자동 추론 오버라이드)

Options#

Initiative/Project issue type availability is checked dynamically via getIssueTypes() — if the workspace has no Initiative/Project type, falls back to the next level down (Project, then Epic) top-level, with a warning. When none of --initiative-level/--project-level/--no-epic is given, Phase 0's Hierarchy Scale Inference decides the top-level anchor from the design artifacts' scope — this replaces the old "Epic is always created" default.

Prerequisites#

• Design stage completed (Solutioning Gate passed)
• Architecture Doc, UX Spec artifacts exist

Execution Flow#

Phase 0: Hierarchy Scale Inference + Priority Review (before creation)#

Source: cc-dev (delegates to /cc-dev:zenhub:breakdown's Step 1.5/1.6 — see zenhub-integration-agent.md)

-1. Hierarchy scale inference

• Explicit --initiative-level/--project-level/--no-epic always wins
• Otherwise infer from the design artifacts' scope (multi-Epic signals → Project; multi-quarter/company-wide signals → Initiative; single small scope → no Epic wrapper)
• With --project-level (or inferred project): derive Project title/scope from .pipeline/{slug}.yaml

0. Priority scoring
   • Score every Epic/work item to be created: dependency (blocker) / business value / risk / effort
   • Assign tiers p0/p1/p2 — labels are immutable after creation, so this must precede Phase 1
   • Present the inferred hierarchy and the priority table to the user together for one confirmation
   • Write the table to .claude/docs/{feature}/zenhub/priority.md — this is the file config/pipeline.json → stages.breakdown.artifacts declares, so it is produced here, not in Phase 3.5. --no-sort skips the pipeline placement (Phase 3.5), never this table

Phase 1: Initiative/Project/Epic Creation#

Source: cc-dev

0. ZenHub Initiative creation (inferred, or --initiative-level; /cc-dev:zenhub:breakdown --initiative)
   • One Initiative issue wrapping the Project (or Epics directly, if no Project level)
1. ZenHub Project creation (inferred, or --project-level; /cc-dev:zenhub:breakdown --project)
   • One Project issue wrapping all feature Epics
   • Goals, Epic list, and priority table in the Project description
   • Linked to the Initiative via parentIssueId when --initiative-level/--parent-initiative is used
2. ZenHub Epic creation (/cc-dev:zenhub:breakdown; skipped when scale=no-epic)
   • Structure Epic based on Architecture Doc
   • Feature/Entity mapping
   • Link design artifacts in Epic description
   • Linked to the Project via parentIssueId when applicable

Phase 2: Work Item Writing#

Source: cc-product

3. Individual work item writing (/cc-product:create-story)

   • Screen-based Feature items from UX Spec
   • Technical Task items from Architecture
   • Defect-driven Bug items where applicable
   • Type resolved per item (Feature/Bug/Task) — never hardcoded, see references/helpers.md → "Sync Story to ZenHub"
   • Connect BDD scenarios as Acceptance Criteria (Feature items); Bug/Task items use the repro/DoD template instead
   • Set dependency relationships
   • Apply Phase 0 priority labels at creation

4. Sprint planning (/cc-product:sprint-planning)

   • Work item priority determination
   • Sprint assignment
   • Capacity planning

Phase 3: PM Review#

Source: cc-product (PM persona)

5. Work item quality verification
   • Story point estimation
   • Labeling (type, scope, priority)
   • Dependency verification
   • Acceptance Criteria completeness check

Phase 3.5: Pipeline Sorting (skipped with --no-sort)#

Source: cc-dev (rules/zenhub-conventions.md → Priority Review and Pipeline Sorting)

6. Priority-based pipeline placement
   • Project/Epic → Product Backlog
   • Work item P0 → Sprint Backlog (+ sprint assignment when --sprint)
   • Work item P0/P1 (no sprint) → Product Backlog, P2 → Icebox
   • Move in descending priority order (P0 → P1 → P2) — moveIssueToPipeline has no position param, so ordering is approximated by move sequence and recorded as a priority table in the Epic/Project body

Phase 4: Planning Gate#

BMAD Planning Gate verification:

• Issue hierarchy is appropriate for the request scale (issue_hierarchy_structure)
• Story points (story_point)
• Labeling incl. priority tiers and resolved type (labeling)
• Dependencies (dependencies)
• Pipeline placement matches priority matrix (pipeline_sorting)

Phase 5: Planning Docs PR (after the gate, before Development)#

Source: cc-product (references/helpers.md → Publish Pipeline Docs PR — that block is the single definition of the protocol; nothing here restates its steps)

7. Publish the pipeline's documents
   • Call the helper with stage_set = discovery, specification, planning, design, scaffold, breakdown and scope = planning. It collects each stage's declared artifacts plus .pipeline/{slug}.yaml, branches from the default branch, opens the PR and squash-merges it
   • scaffold is in the set but contributes nothing: its artifacts are source paths, and the helper keeps only docs/ · .claude/docs/ · .pipeline/ — scaffolded code reaches the repository through the Story PRs that implement it, not through a docs PR
   • Runs only after the Planning Gate passes (unmet(planning) == 0). Under L-gate-revise a failed gate re-runs this stage and overwrites the same artifact paths — publishing before the verdict would put a document on the default branch that the next attempt contradicts
   • Runs before Development for a mechanical reason: /cc-product:develop branches each Story off the default branch. If the documents are not there yet, every Story branch is cut from a base that lacks the very architecture/UX spec its DoD cites, and the documents reach the repository only by being dragged into an unrelated code PR — or not at all
   • Idempotent: an already-merged planning docs PR for this slug is detected and not re-created, so a re-run of /cc-product:breakdown does not open a second one
   • Degradation (no gh CLI, no remote, empty document set) is recorded and reported, never silent, and never blocks the Planning Gate result — the gate has already passed at this point

Documents produced after this point: the development stage's documents ride along with the code PR /cc-dev:run already opens (no separate publication), and /cc-product:launch publishes its own with the same helper. No pipeline document is left uncommitted at the end of the pipeline.

Artifacts#

• ZenHub Initiative (issue number recorded, when inferred/--initiative-level)
• ZenHub Project (issue number recorded, when inferred/--project-level)
• ZenHub Epic (issue number recorded, unless scale=no-epic)
• Linked work items — Feature/Bug/Task (issue number list)
• Priority table (.claude/docs/{feature}/zenhub/priority.md)
• Project/Epic numbers recorded in .pipeline/{slug}.yaml
• Planning docs PR (docs/{slug}-planning → default branch, squash-merged) carrying the discovery~breakdown documents; its number recorded at stages.{stage}.docs_pr for each stage in the set

After Completion#

• Verify Planning Gate passed
• Record Project/Epic/work item numbers in state file
• Verify the planning docs PR merged (or that its degradation is recorded at stages.{stage}.docs_pr with a reason) — Development must not start from a base whose missing documents nobody noticed
• Present context-clear handoff:

✅ Issue Breakdown stage complete (Planning Gate PASSED).
  Project #{project_number} (optional) / Epic #{epic_number} (optional) created with {item_count} work items (Feature ×{f}, Bug ×{b}, Task ×{t}).
  Pipeline sorting: P0 ×{n} → Sprint Backlog, P1 ×{n} → Product Backlog, P2 ×{n} → Icebox
  Planning docs PR #{docs_pr_number} merged → {doc_count} documents are on {default_branch}

**Option 1 (Recommended)**: Clear context and continue to Development
  /clear
  Then run: /cc-product:develop {epic_number}

**Option 2**: Continue in current context
  Proceed directly to /cc-product:develop {epic_number}