dev-cycle

개발 사이클 마스터 허브 — 이슈 처리(dev)·ZenHub 보드(zenhub)·PR 게이트(pr)·세션 마무리(session)·OpenAPI(openapi) 네임스페이스의 커맨드로 라우팅합니다

/dev-cycle — 개발 사이클의 "안내 데스크"#

항목	내용
실행 명령	`/cc-dev:dev-cycle`
난이도	●○○ 간단

한마디로#

이슈 생성부터 머지까지, 지금 하려는 일에 맞는 개발 사이클 커맨드를 찾아 연결해주는 안내 데스크입니다. cc-dev에는 커맨드가 많은데, 무엇을 원하는지 말하면 알맞은 진입점으로 보내줍니다.

누가·언제 쓰나요#

개발 사이클 자동화를 쓰고 싶은데 어떤 커맨드를 불러야 할지 모를 때
이슈 처리·백로그 관리·PR 게이트·세션 마무리 중 어느 영역인지부터 헷갈릴 때

라이프사이클 척추#

이슈 생성/정제 → 브랜치 → 구현 → /cc-dev:pr:preflight → PR → 리뷰 반영 → 머지 → /cc-dev:session:wrap
     (zenhub)              (dev)      (pr)              (dev)              (session)

상황 → 진입점 결정 테이블#

하려는 일	네임스페이스	커맨드
말 한마디로 이슈 생성→계획→구현→PR 머지까지 원스톱	`dev`	`/cc-dev:go`
이슈 하나를 브랜치→구현→PR→머지까지 자동 처리	`dev`	`/cc-dev:run "할 일"` 또는 `/cc-dev:run {이슈번호}`
이슈 계층(Initiative~Sub-task)을 재귀 처리 — 독립 형제는 Orca 워크트리 병렬 디스패치 (스폰 전 사람 승인 필수 · 동시 상한 `--max-parallel` , cap 때문에 미룬 형제는 deferred 로그 · 머지는 항상 직렬 ), 순차로 내리려면 `--no-parallel`	`dev`	`/cc-dev:batch`
순차 의존이 있는 형제들을 한 줄(선형 스택)로 묶어 PR 을 쌓고 싶다 / `gh stack` 을 쓰고 싶다	`dev`	커맨드 아님 — 스킬 stacked-prs ( 선택형 모드 , 기본값은 기존 5레벨 계층. 서로 독립인 형제는 그대로 `/cc-dev:batch` 병렬 · 켜면 층마다 CI 가 돌아 비용 맞교환)
버그 이슈 수정 사이클	`dev`	`/cc-dev:bugfix`
같은 문제를 반복하며 막혔을 때 (측면 사고)	`dev`	`/cc-dev:unstuck`
요구사항 → Initiative/Epic/Task 이슈 생성	`zenhub`	`/cc-dev:zenhub:breakdown`
외부 피드백 → 정리된 이슈로 스테이징	`zenhub`	`/cc-dev:zenhub:triage`
백로그 우선순위 재정렬	`zenhub`	`/cc-dev:zenhub:rerank`
스프린트 이월/팀 배분/보드 관리	`zenhub`	`/cc-dev:zenhub:sprint-rollover` `/cc-dev:zenhub:team-align` `/cc-dev:zenhub:manage`
릴리스 노트 생성	`zenhub`	`/cc-dev:zenhub:changelog`
워크스페이스 파이프라인 초기화	`zenhub`	`/cc-dev:zenhub:init-workspace`
PR 전 변경 패키지 테스트 게이트	`pr`	`/cc-dev:pr:preflight`
게시된 AI 코드 리뷰 반영 ( 수동 전용 — 자동 사이클이 호출하지 않는다. `/cc-dev:run` Step 11 은 `/cc-quality:review` 를 돌린다)	`pr`	`/cc-dev:pr:review-processor`
세션 종료·문서 갱신	`session`	`/cc-dev:session:wrap`
OpenAPI Response → Domain Mapper 생성	`openapi`	`/cc-dev:openapi:mapper`
인시던트 회고 (blameless)	`dev`	`/cc-dev:debrief`

🔗 위 척추 그림과 이 표는 라우팅 색인(비규범)입니다. 실행 모델 — 재귀 깊이·병렬 폭·승인 지점·머지 직렬화 — 의 SoT는 각 커맨드 자기 문서입니다: 계층 배치는 batch.md, 원스톱 파이프라인은 go.md, 13단계 사이클은 run.md (SoT §0 가 규범 블록의 자리를 정합니다). 어긋나면 그 문서의 ```flow 블록이 이깁니다 (§6). 기질 선택은 §4 Substrate Selection, 팬아웃 의무(width:·tier:·deferred 로그)는 §5 Fan-out Obligations 를 따릅니다. 폭·상한·타임아웃 같은 값을 이 표로 복사하지 마세요 — 값은 각 커맨드 자리에만 둡니다.

스킬 라우팅 (자동 트리거 지식)#

스킬	언제 트리거되나
`dev`	이슈→머지 사이클 규칙 전반 (/cc-dev:run 의 척추)
`pr`	PR 생성·리뷰·머지 컨벤션
`session`	세션 마무리·문서 갱신 규칙
`zenhub-conventions`	ZenHub 이슈 타입·파이프라인·라벨 컨벤션
`branch-hierarchy`	Epic/이슈 계층 브랜치 전략
`stacked-prs`	GitHub 네이티브 Stacked PR( `gh stack` ) 실행 모드 — 채택 판단·스택 머지 의미론 (branch-hierarchy 의 선택형 대안, public preview)
`agent-teams`	에이전트 팀 구성·Effort Routing 규칙
`merge-conflict-resolution`	머지 충돌 해소 절차
`claude-review-automation`	Claude 리뷰 자동화 설정
`dev-env-sync` / `parallel-test-env` / `incremental-build`	개발 환경 동기화·병렬 테스트·증분 빌드
`discovery-audit`	디스커버리 산출물 감사

경계 (다른 플러그인으로)#

스펙이 모호해서 이슈를 만들기 어렵다 → cc-spec (/spec:*)
제품 파이프라인 상위 단계(Discovery→Launch) → cc-product (/product)
코드 리뷰·QA 산출물 → cc-quality (/cc-quality:review, /checklist:*)
Flutter 구현 자체 → cc-flutter (/flutter-dev)
전체 도구 지도 → cc-compass (/compass)

⚙️ 상세 명세 (개발자 / AI 에이전트용)

Triggers#

cc-dev의 커맨드 중 무엇을 쓸지 불명확할 때
개발 사이클 자동화의 진입점 탐색이 필요할 때

Context Trigger Pattern#

/dev-cycle [의도 설명]

인자 없이 부르면 위 결정 테이블을 보여주고, 의도를 설명하면 해당 커맨드로 바로 라우팅합니다.

Namespaces#

네임스페이스	커맨드 수	역할
`dev`	6	이슈 사이클 자동화 (go/run/batch/bugfix/unstuck/debrief)
`zenhub`	8	보드·백로그·스프린트 관리
`pr`	2	PR 전 테스트 게이트 · AI 리뷰 반영(수동 진입점 — 자동 사이클이 호출하지 않음)
`session`	1	세션 마무리
`openapi`	1	OpenAPI → Mapper 생성

Agents#

에이전트 정의는 agents/** 참고 — 오케스트레이터(/cc-dev:run 등)가 subagent_type 이름으로 디스패치하는 내부 워커이며 직접 호출 대상이 아닙니다. 모든 에이전트는 frontmatter model: 티어를 명시합니다 (Effort Routing Convention — agent-teams 스킬).

Typical Flow#

# 원스톱 (권장) — 한 번의 계획 승인으로 머지까지
/cc-dev:go  " 요구사항 "                # 브레인스토밍 → 이슈 계층 생성 → 계획 승인(1회) → 구현 → PR 머지

# 단계별 수동 체이닝
/cc-dev:zenhub:breakdown  " 요구사항 "     # 이슈 생성 (마지막에  " 바로 개발 시작 "   선택 가능)
→ /cc-dev:batch {epic} 또는 /cc-dev:run {issue}   # 브랜치 → 구현 → 테스트 → PR → 머지
→ /cc-dev:session:wrap                # 문서 갱신·세션 마무리