squadlisted

# squad 큰 작업 한 덩이를 **여러 워커가 동시 진행 가능한 독립 단위 N개**로 쪼개고 인터페이스·우선순위를 정의한다. 한 에이전트가 계획만 만들고 실 구현은 위임 — **Orchestrator-Worker 패턴**. N은 작업 성격으로 결정 — 카드 9종처럼 명확하면 9, 화면 3개면 3, PRD 20 features면 20. 숫자 고정 아님. ## 언제 쓰는가 - 작업이 1주+ 규모이고 여러 사람·AI 동시 진행 가능 - PRD/대형 spec을 features로 분해 - 진행 중 프로젝트의 잔여 작업을 재분배 쓰지 말 것: 1-2 task 소규모(→ `/plan`), 단일 세션(→ `/dev`), 요구 모호(→ `/deep-interview`). ## 6단계 프로토콜 1. **원천 수집** — `PRD.md`, `blueprint.json`, 기존 spec 탐색. 없으면 사용자 합의 후 작성. 2. **단위 합의** — `AskUserQuestion` 1회로 단위 결정 (기능 / 화면 / 핫스팟). 옵션 묻는 횟수 최소화. 3. **스펙 작성** — `templates/spec-template.md`의 10섹션 × N개. **INVEST** 검사(Independent · Negotiable · Valuable · Estimable · Small · Testable). 4. **DAG + CPM** — 각 스펙 §4 의존성으로 DAG. 최장 경로 = critical path = P0. 5. **그룹화** — P0(단독·블로커) / P1(독립 병렬) / P2(small fix) / C(P0 후 풀림). 6. **brief 출력** — 작업자별 1줄. 자기충족(`docs/specs/FEAT-xxx.md` 1개만 봐도 시작 가능). **반복 사이클**: 검사 게이트(tsc/lint/test/AC) → complete 이동 또는 `§0 잔여` 압축 → DAG 재평가 → 인덱스 재갱신. ## 우선순위 분류 | 그룹 | 정의 | 시작 시점 | |---|---|---| | **P0** | Critical path 위, 다른 단위가 의존 | 즉시·단독 | | **P1** | 의존 없는 독립 단위 | P0와 동시 | | **P2** | small fix (5분~30분) | 누구나·아무 때 | | **C** | P0 완료 후 풀림 | 의존 해제 시 | ## 큰 파일 분리 패턴 작업 대상이 하나의 큰 파일(예: 1000+줄 컴포넌트, switch 분기, 거대한 store)이고 워커별 책임이 함수/case 단위로 분리 가능하면, **P0에 "사전 리팩터"를 박는 것이 critical path**다. ### P0 사전 리팩터 체크리스트 1. **큰 파일을 워커별 파일로 분리** — `cards/{kind}/Content.tsx`처럼 디렉토리/파일을 책임 단위로 쪼갬. 원본은 thin router(switch만)로 남김. 2. **공통 헬퍼 추출** — 모든 워커가 쓰는 함수/타입/상수를 `_shared/`로 모음. 워커는 i