Claude Flow

claude-flow — Fable 지휘 × Claude 작업자 파이프라인

플랜의 태스크를 순차로 구현 → 검증 → 커밋하며 최종 통합 검증까지 자율 완주한다. 지휘관도 작업자도 Claude다 — Fable 5(메인 스레드)가 직접 지휘하고, 실행은 Agent 툴로 스폰한 sonnet/opus 작업자에게 위임한다. 토큰 규율은 ../_shared/token-discipline.md를 따른다 (시작 시 반드시 읽을 것). 플랜 승인 후에는 중단 조건에 걸리지 않는 한 사용자에게 묻지 않는다.

역할

| 역할 | 담당 | 수단 | |---|---|---| | 지휘관 | 플랜, 작업 분해, 태스크별 지시·티어 지정, diff 판정, 최종 감사, 커밋 | Fable 5 (메인 스레드) — 직접 결정 | | 작업자 (물량) | 구현, 테스트 작성, 리팩토링, 다중 파일 편집 | Agent(model: "sonnet") | | 작업자 (정예) | 어려운 디버깅, 동시성·보안 민감 수정, 아키텍처가 얽힌 정밀 작업 | Agent(model: "opus") |

전제 조건 (Phase 0 진입 전 확인)

• git repo일 것 (태스크별 커밋 때문). 아니면 사용자에게 확인.
• 워킹트리가 깨끗할 것. 기존 변경이 있으면 태스크 커밋이 오염되므로 시작 전에 커밋/스태시를 권하고 확인받는다.
• 프로젝트의 검증 수단(테스트 러너, 빌드, 린트/타입체크)을 파악한다. 아무것도 없으면 시작 전 확인에 포함: smoke test 추가를 제안하거나 diff 리뷰만으로 진행할지 묻는다.

Phase 0 — 플랜 확보 (유일한 승인 게이트)

1. 인자가 있으면 (/claude-flow 결제모듈) feature-name 후보로 쓴다.

• SDD 진행 중 진입(게이트 압축): 직전에 spec 문서(예: requirements)의 승인을 물은 상태에서 이 스킬이 "진행해"류와 함께 호출되면, 그것을 해당 문서 승인으로 해석한다. 남은 spec 문서(design·tasks)는 SDD 템플릿·산출물 위치 그대로 작성하되, 개별 승인 대신 아래의 단일 플랜 게이트로 압축해 한 번에 확인받는다. (SDD 워크플로우는 이 플러그인의 sdd 스킬 참조.)

1. .claude/specs/*/tasks.md에서 미완료 체크박스가 있는 spec을 스캔:

• 있으면: 그 tasks.md가 플랜이다. 남은 태스크 목록을 보여주고 시작 확인을 1회 받는다.
• 없으면 (즉석 분해): 리포를 탐색한 뒤 태스크 목록을 작성한다 — 각 태스크에 목표·범위(파일)·완료 기준 필수. .claude/specs//tasks.md로 저장하고 (SDD 산출물 위치와 동일) 사용자 승인을 1회 받는다.

1. 플랜 승인 시 "지휘: Fable 5 / 작업자: sonnet·opus" 구성을 함께 표기하고, 승인과 동시에 자동 실행이 시작됨을 명시한다. 이후 완주까지 논스톱.

Phase 1 — 태스크 루프

각 미완료 태스크에 대해 순서대로:

1. 준비: 목표·범위·완료 기준을 확정하고, 관련 코드를 Fable 5가 직접(또는 Explore 에이전트로) 탐색해 컨텍스트 요약을 만든다.
2. 실행 — 위임 기준:

• 구현·테스트 작성·리팩토링·다중 파일 편집 → Agent(model: "sonnet") 스폰.
• opus 상향 조건: 근본원인 추론이 필요한 디버깅, 동시성/보안/데이터 정합성 민감 수정, 설계 판단이 얽힌 리팩토링, sonnet 반려 후 상향. 티어 지정은 지휘관 몫.
• 한두 파일의 사소한 수정, 설정 변경 → 위임하지 않고 Fable 5가 직접 (스폰 오버헤드가 더 크다).
• 위임 프롬프트 4요소 (필수): ① 목표 한 문장 ② 범위 — 건드릴 파일·디렉토리와 건드리면 안 되는 것("do not touch X") ③ 컨텍스트 — 탐색으로 알아낸 구조·컨벤션·제약 요약, 코드 전문 복붙 금지·file:line 포인터로 (작업자가 직접 읽는다) ④ 완료 기준 — 어떤 테스트/빌드/동작이 통과해야 완료인지. 끝에 보고 형식을 명시한다: "변경 파일 목록·검증 결과 tail·완료 기준 판정만 보고".
• 순차 실행: 작업자들이 워킹트리를 공유하므로 태스크 병렬 스폰 금지 (atomic 커밋 오염). 병렬은 read-only 탐색(Explore)만. 파일이 전혀 안 겹치는 태스크는 isolation: "worktree"로 병렬 가능하나 머지 비용 때문에 예외로만.

1. 검증 (수락 게이트 — 생략 금지):

• git diff를 직접 읽는다: 범위 이탈, 의도치 않은 삭제, 컨벤션 위반.
• 테스트/빌드/린트를 직접 실행한다. 작업자의 보고를 믿지 않는다.
• 완료 기준 충족을 판정한다.

1. 실패 시: 반려 사유를 구체적 수정 지시로 정리해 같은 작업자에 SendMessage로 재작업시킨다 (컨텍스트 유지, 반려 사유만 전달). 1차 재작업도 실패하면 티어 상향(sonnet→opus, opus였다면 Fable 직접 수정)을 고려한다. 최대 2회. 그래도 실패면 루프를 중단하고 보고한다 — 어느 태스크, 무엇이 실패, 시도 내역, 현재 워킹트리 상태. 실패한 변경은 되돌리지 말고 그대로 두고 사용자 지시를 기다린다.
2. 통과 시: tasks.md 체크박스 갱신 → atomic 커밋 (해당 태스크 변경 + tasks.md 갱신만 포함, Conventional Commits + 스코프 — 제목 언어는 프로젝트 컨벤션을 따르고 기본은 한국어, 태스크와 1:1).
3. 태스크 하나 끝날 때마다 한 줄 진행 보고 ([3/7] ✓ feat(api): …). 하니스에 TaskCreate/TaskUpdate가 있으면 진행 추적에 사용.

Phase 2 — 최종 통합 검증

모든 태스크 완료 후:

1. 전체 테스트 스위트 + 빌드 + 린트/타입체크를 실행한다.
2. 플랜 시작 커밋 대비 전체 diff를 self-review한다: 태스크 간 불일치, 죽은 코드, 중복, 스코프 이탈.
3. 런타임 표면이 있으면 실제로 띄워서 E2E 동작을 확인한다 (verify 계열 스킬이 있으면 활용).
4. 통합 이슈가 나오면 수정 태스크로 만들어 Phase 1 루프로 회귀한다 (fix 커밋). 재시도 한도 정책 동일.

Phase 3 — 완료 보고 & 핸드오프

• 최종 보고: 완료 태스크와 커밋 목록, 검증 결과 요약, 재시도가 있었던 태스크와 원인.
• spec 기반이면 tasks.md 완료 상태를 확인한다. 회고·배포 스킬이 있는 환경이면 그쪽으로 연결을 제안한다.

중단 조건과 재개

중단 조건 (이때만 사용자에게 돌아간다):

• 재시도 한도(2회) 초과
• 실행 중 spec/플랜 변경이 필요한 발견 (스코프 판단은 사용자 몫)
• 파괴적 작업 필요 (데이터 삭제, 마이그레이션, 외부 서비스 변경 등)
• 검증 수단 자체의 고장 (테스트 러너가 플랜과 무관하게 깨져 있는 등)

재개: /claude-flow를 다시 호출하면 tasks.md 체크박스 기준으로 중단 지점부터 이어간다. 태스크별 커밋이 롤백 포인트다.

연계

• 점검 카운터파트는 /claude-review — 같은 역할 분담으로 read-only 프로젝트 점검을 돈다.
• claude-flow 결과를 다른 모델 계열의 리뷰 도구로 점검하면 실행·점검에 서로 다른 모델이 들어가는 교차 검증이 된다.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: tmdry4530
• Source: tmdry4530/chamdom-claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.