ship — Claude Agent 워크플로

Git 플로우 — 항상 자동 실행

🌿

브랜치 생성

feat/{slug}
-{timestamp}

💾

중간 커밋

Wave A 완료 후
자동 push

💾

중간 커밋

Wave B 완료 후
자동 push

🔧

수정 커밋

자동 수정
라운드마다

📬

PR 생성

게이트 무관
항상 실행

✓ 보호 브랜치(main/master/prd)면 새 브랜치 자동 생성 ✓ 변경사항 없으면 커밋 자동 스킵 ✓ 게이트 실패 시 Draft PR · 통과 시 일반 PR ✓ 라벨 "Claude Agent" 자동 부착

전체 실행 흐름

🌿

Git 사전작업

브랜치 생성 & 초기 설정

feature 설명에서 ASCII 슬러그 추출 → feat/{slug}-{YYYYMMDD-HHmmss} 브랜치 생성. 이미 feature 브랜치에 있으면 현재 브랜치 그대로 사용.

📐

Phase 1

Architect — 계획 수립 & 에이전트 선택

요청을 분석해 plan.md와 agents.txt 자동 생성. 불필요한 에이전트는 제외.

버그 → debugger 필수 UI → frontend API → backend 보안 → security

🗣️

Debate 1

설계 계획 Red / Blue / Judge 토론

🔴 Red가 plan.md 허점 공격 → 🔵 Blue가 ACCEPT/MITIGATE/REJECT 판정 후 수정 → ⚖️ Judge가 최대 2라운드 심판. CONSENSUS 시 Phase 3 진입.

⚡

Phase 3

2-Wave 병렬 에이전트 실행

Wave A(구현) 완료 후 Wave B(검증) 시작. Wave A 패널은 B가 시작될 때까지 화면에 유지.

Wave A: backend · frontend · debugger Wave B: reviewer · test · security

💾

중간 Git

Wave A 완료 후 커밋 / Wave B 완료 후 커밋

각 Wave 완료 시 변경사항 자동 git add -A → commit → push. 변경사항 없으면 스킵.

🗣️

Debate 2

구현 결과 토론 — REWORK 판정 시 Wave 재실행

에이전트 구성에 따라 test(커버리지) 또는 reviewer(코드리뷰) 초점으로 토론. Judge가 REWORK 판정 시 Wave 처음부터 재실행 (횟수 제한 없음).

CONSENSUS → 다음 단계 CONTINUE → 다음 라운드 REWORK → Wave 재실행

🔍

Phase 4

CI 하네스 게이트 — 4단계

tsc → eslint → test → build. 실패 항목이 있으면 Phase 5로 이동.

🔄

Phase 5 (실패 시)

자동 수정 루프 — 최대 3라운드

실패 로그를 에이전트에게 전달 → 코드 수정 → 게이트 재검사 → 커밋/푸시. 라운드마다 자동 커밋.

📬

Phase 6 — 항상 실행

릴리스 매니저 — 최종 커밋 / 푸시 / PR 생성

게이트 통과 여부와 무관하게 무조건 실행. 미커밋 변경사항 정리 → push → PR 생성 또는 업데이트. 기존 PR 있으면 본문 업데이트.

게이트 통과 → 일반 PR 게이트 실패 → Draft PR 라벨: Claude Agent 필수 prd/master 베이스 금지

에이전트 구성

🔧

backend

Wave A

API Route Handler, 서비스 레이어, Zod 검증

🎨

frontend

Wave A

React 컴포넌트, TanStack Query, Tailwind CSS

🐛

debugger

Wave A

경쟁 가설 방식 버그 원인 분석 및 수정

👀

reviewer

Wave B

가독성, 타입 안전성, 레이어 규칙 리뷰

🧪

test

Wave B

Vitest + Testing Library, 커버리지 80%+

🔒

security

Wave B

OWASP Top 10, 인증/인가, 시크릿 검토

tmux 레이아웃 — Wave A → Wave B

STEP 1 Wave A 실행 중 — 구현 에이전트만 열림

🚢 ship

Phase 3 실행 중...
⏳ Wave A: 1/2

🔧 backend

서비스 레이어 작성 중

🎨 frontend

컴포넌트 구현 중

↓ Wave A 완료 · 커밋/푸시

STEP 2 Wave B 시작 — A 패널 유지된 채 B 열림

🚢 ship

✅ Wave A 완료
💾 커밋/푸시 완료

🔧 backend ✓

완료

🎨 frontend ✓

완료

👀 reviewer

코드 리뷰 중

🧪 test

테스트 작성 중

Wave B 완료 후 A+B 패널 모두 자동 닫힘 → 메인 복귀

Debate 시스템 — Red / Blue / Judge

🔴

Red (공격자)

계획/코드의 허점, 위험요소, 누락된 엣지케이스를 공격. 해결책 제시 금지 — 문제 지적만.

🔵

Blue (방어자)

각 공격 항목을 ACCEPT / MITIGATE / REJECT로 판정. ACCEPT·MITIGATE는 실제 파일을 수정해 반영.

⚖️

Judge (심판)

Red/Blue 토론을 심판. Debate 2에서는 REWORK 판정으로 Wave 전체 재실행 가능 (횟수 제한 없음).

CONSENSUS CONTINUE REWORK

사용법

# tmux 세션에서 실행 (패널 분할을 위해 필수) tmux new-session -s work # 실행 ship "구현하거나 수정할 내용을 자연어로 설명" # 예시 ship "로그인 시 이름/전화번호 저장 안 되는 버그 수정" ship "마이페이지 UI를 Figma 디자인대로 구현" ship "결제 API 연동 및 결제 완료 화면 구현"

핵심 특징

요청 내용에 따라 Architect가 필요한 에이전트만 자동 선택
브랜치 생성 → 중간 커밋 → PR 생성이 모든 실행에서 자동으로 보장
Wave A(구현) → Wave B(검증) 순차 실행 — 구현 완료 후 리뷰/테스트
Debate 2에서 REWORK 판정 시 Wave를 횟수 제한 없이 재실행
게이트 실패해도 Draft PR 자동 생성 — 팀에 진행 상황 공유
모든 프롬프트는 파일 경로 참조 방식 — OS 인자 한도 초과 없음