@jjlabsio/claude-crew 0.1.18 → 0.1.20

package/.claude-plugin/marketplace.json

@@ -11,7 +11,7 @@
       "name": "claude-crew",
       "source": "./",
       "description": "오케스트레이터 + PM, 플래너, 개발, QA, 마케팅 에이전트 팀으로 단일 제품의 개발과 마케팅을 통합 관리",
-      "version": "0.1.18",
+      "version": "0.1.20",
       "author": {
         "name": "Jaejin Song",
         "email": "wowlxx28@gmail.com"
@@ -28,5 +28,5 @@
       "category": "workflow"
     }
   ],
-  "version": "0.1.18"
+  "version": "0.1.20"
 }

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-crew",
-  "version": "0.1.18",
+  "version": "0.1.20",
   "description": "1인 SaaS 개발자를 위한 멀티 에이전트 오케스트레이션 — 개발, 마케팅, 일정을 한 대화에서 통합 관리",
   "author": {
     "name": "Jaejin Song",
@@ -17,7 +17,6 @@
     "solo-developer"
   ],
   "agents": [
-    "./agents/pm.md",
     "./agents/planner.md",
     "./agents/dev.md",
     "./agents/qa.md",

package/README.md

@@ -2,7 +2,18 @@
 
 1인 SaaS 개발자를 위한 Claude Code 멀티 에이전트 오케스트레이션 플러그인.
 
-개발, 마케팅, 일정을 한 대화에서 통합 관리한다.
+## 파이프라인
+
+```
+crew-interview → crew-plan → crew-dev
+   WHAT            HOW         DO
+```
+
+| 단계 | 역할 | 산출물 |
+|------|------|--------|
+| **crew-interview** | 무엇을 만드는가 — 요구사항 인터뷰, 제품 설계 | spec.md |
+| **crew-plan** | 어떻게 만드는가 — 기술 분석, 태스크 분해 | contract.md |
+| **crew-dev** | 만든다 — 구현, 코드 리뷰, QA | 동작하는 코드 + PR |
 
 ## 설치
 
@@ -39,20 +50,29 @@ HUD statusline이 설정되어 세션 중 레포, 브랜치, 모델, 컨텍스
 
 ## 에이전트 팀
 
-| 에이전트 | 역할 |
-|---------|------|
-| **오케스트레이터** | 유저와 대화, 위임 판단, 영역 간 연동 |
-| **PM** | 유저와 대화하여 기획 확정 |
-| **플래너** | 기획을 명세로 확장, 태스크 분해 |
-| **개발** | 코드 구현, QA와 계약 협상 |
-| **QA** | 스프린트 계약 기반 회의적 검증 |
-| **마케팅** | 콘텐츠 소재, 계획, build in public |
+| 에이전트 | 역할 | 소속 스킬 |
+|---------|------|----------|
+| **오케스트레이터** | 유저와 대화, 위임 판단, 파이프라인 진행 | 전체 |
+| **Explorer** | 코드베이스 탐색 (read-only) | interview, plan |
+| **Researcher** | 외부 리서치 (WebSearch) | interview, plan |
+| **TechLead** | 기술 분석, 아키텍처 방향 판단 | plan |
+| **Planner** | 태스크 분해, 구현 계획 | plan |
+| **PlanEvaluator** | 계획 검증 (하드 임계값) | plan |
+| **Dev** | 코드 구현 | dev |
+| **CodeReviewer** | 코드 리뷰 | dev |
+| **QA** | 실행 검증 | dev |
 
 ## 상태 파일
 
 프로젝트 로컬 `.crew/` 디렉토리에 마크다운 파일로 상태를 관리합니다. 플러그인 업데이트 시에도 학습 내용과 상태는 보존됩니다.
 
-## 설계 원칙
+## 설계 철학
+
+**역할별 관점은 유지하되, 정보는 제한하지 않는다.**
+
+각 에이전트는 특정 관점(기획/기술/구현)에서 사고하지만, 활용할 수 있는 정보(코드 포함)는 제한하지 않는다. 실제 회사의 역할 분리를 모방하는 것이 아니라, 빠뜨리는 관점이 없도록 구조화된 사고를 강제하는 것이 목적이다.
+
+### 기타 원칙
 
 - [Anthropic 하네스 설계 아티클](https://www.anthropic.com/engineering/harness-design)을 최우선 레퍼런스로 따름
 - 가능한 단순하게 시작하고 필요할 때만 복잡성을 높임

package/agents/plan-evaluator.md

@@ -1,7 +1,7 @@
 ---
 name: plan-evaluator
 model: sonnet
-description: 계획 검증 — E1-E4 하드 임계값 판정. Sonnet 사용 (Opus 합리화 방지)
+description: 계획 검증 — E1-E6 하드 임계값 판정. Sonnet 사용 (Opus 합리화 방지)
 tools: [Read, Agent]
 ---
 
@@ -11,13 +11,13 @@ tools: [Read, Agent]
 
 ## 입력
 
-- `spec.md` (유저 가치 시) 또는 `brief.md` (엔지니어링 시)
+- `spec.md`
 - `analysis.md`
 - `plan.md`
 
 ## 접근 금지
 
-- `brief.md` — 유저 가치 유형일 때는 읽지 않는다. (엔지니어링 유형에서만 brief.md 사용)
+- `brief.md` — 읽지 않는다.
 
 ## 출력
 
@@ -25,14 +25,16 @@ tools: [Read, Agent]
 
 ## 검증 항목
 
-4개 항목, 모두 YES/NO 판정:
+6개 항목, 모두 YES/NO 판정:
 
 | # | 항목 | 확인 방법 |
 |---|------|----------|
 | E1 | **검증 시나리오 완성도** — 모든 태스크에 검증 방법이 명시되어 있는가 | 문서 확인 (직접) |
-| E2 | **요구사항 정합성** — 수용 기준이 전부 태스크로 커버되는가 | 문서 대 문서 비교 (직접) |
+| E2 | **spec 전체 커버리지** — spec.md의 수용 기준, 유저 플로우, UI 구조, 비즈니스 규칙이 전부 태스크로 커버되는가 | 문서 대 문서 비교 (직접) |
 | E3 | **코드 참조 사실 여부** — 언급한 파일/모듈이 존재하는가 | Explorer 호출 |
 | E4 | **실행 가능성** — 구현자가 바로 시작할 수 있는 수준인가 | 판단 (직접) |
+| E5 | **테스트 전략 정합성** — analysis.md의 테스트 전략 결정과 plan.md의 태스크 구조가 일치하는가 | 문서 대 문서 비교 (직접) |
+| E6 | **비즈니스 가정 0개** — plan.md가 spec.md에 없는 비즈니스 로직을 임의로 추가하지 않았는가 | 문서 대 문서 비교 (직접) |
 
 ## review.md 출력 형식
 
@@ -45,9 +47,11 @@ tools: [Read, Agent]
 | # | 항목 | 판정 | 근거 |
 |---|------|------|------|
 | E1 | 검증 시나리오 완성도 | YES/NO | {근거} |
-| E2 | 요구사항 정합성 | YES/NO | {근거} |
+| E2 | spec 전체 커버리지 | YES/NO | {근거} |
 | E3 | 코드 참조 사실 여부 | YES/NO | {근거} |
 | E4 | 실행 가능성 | YES/NO | {근거} |
+| E5 | 테스트 전략 정합성 | YES/NO | {근거} |
+| E6 | 비즈니스 가정 0개 | YES/NO | {근거} |
 
 ## FAIL 상세 (NO 항목만)
 ### {항목}: {사유}
@@ -56,12 +60,12 @@ tools: [Read, Agent]
 
 ## FAIL 근본 원인 분류 (FAIL 시 필수)
 - [ ] plan 결함 — 계획 구성/표현 문제 → Planner 재시도 가능
-- [ ] spec 결함 — 수용 기준 자체가 문제 → 즉시 에스컬레이션 필요
+- [ ] spec 결함 — spec.md 자체가 문제 → 즉시 에스컬레이션 필요
 ```
 
 ## 판정 규칙
 
-- 4개 항목 모두 YES → PASS
+- 6개 항목 모두 YES → PASS
 - 하나라도 NO → FAIL
 - E3 코드 참조 확인은 Explorer 서브에이전트를 호출한다.
 - "아마 의도했을 것"이라고 추측하지 않는다. 모호하면 NO.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jjlabsio/claude-crew",
-  "version": "0.1.18",
+  "version": "0.1.20",
   "description": "1인 SaaS 개발자를 위한 멀티 에이전트 오케스트레이션 — 개발, 마케팅, 일정을 한 대화에서 통합 관리",
   "author": "Jaejin Song <wowlxx28@gmail.com>",
   "license": "MIT",

package/scripts/setup-hud.mjs

@@ -9,7 +9,7 @@
 
 import { execSync } from 'node:child_process';
 import { existsSync, readFileSync, writeFileSync, mkdirSync } from 'node:fs';
-import { join } from 'node:path';
+import { join, dirname } from 'node:path';
 import { homedir } from 'node:os';
 
 // ---------------------------------------------------------------------------
@@ -50,8 +50,13 @@ async function main() {
     try { cwd = JSON.parse(raw).cwd || cwd; } catch { /* ignore */ }
   }
 
-  // Use git toplevel as the reliable project root
-  const projectRoot = gitExec('git rev-parse --show-toplevel', cwd) || cwd;
+  // In worktrees, --show-toplevel returns the worktree path, not the main repo.
+  // Use --git-common-dir to resolve back to the main repo path.
+  const topLevel = gitExec('git rev-parse --show-toplevel', cwd) || cwd;
+  const commonDir = gitExec('git rev-parse --git-common-dir', cwd);
+  const projectRoot = (commonDir && commonDir !== '.git' && !commonDir.startsWith('.'))
+    ? dirname(commonDir)  // worktree: commonDir is /path/to/main-repo/.git
+    : topLevel;
 
   const hudCommand = `node "${pluginRoot}/hud/index.mjs"`;
   const localSettingsPath = join(projectRoot, '.claude', 'settings.local.json');

package/skills/crew-dev/SKILL.md

@@ -31,8 +31,8 @@ description: contract.md를 입력으로 받아 Dev + CodeReviewer + QA 파이
 ```
 .crew/plans/{task-id}/
   # crew-plan 산출물 (입력, 이미 존재)
-  brief.md              # 유저 요청 원문
-  spec.md               # PM 출력 (유저 가치 유형만)
+  brief.md              # crew-interview: 유저 원본 요청
+  spec.md               # crew-interview: 인터뷰 완료 후 결정화된 스펙
   analysis.md           # TechLead 출력
   plan.md               # Planner 출력
   contract.md           # 스프린트 계약

package/skills/crew-interview/SKILL.md

@@ -0,0 +1,339 @@
+---
+name: crew-interview
+description: 유저 요구사항을 인터뷰하여 개발 가능한 수준의 spec.md를 생성한다
+---
+
+## 역할
+
+유저의 raw 요청을 받아 체계적 인터뷰를 통해 **WHAT(무엇을 만드는가)**을 완전히 정의한다.
+"코드만 작성하면 되는 수준"의 spec.md를 생성하는 것이 목표다.
+
+에이전트 간 소통은 파일을 통해서만 이루어진다.
+
+---
+
+## 절대 금지
+
+- 코드를 작성하지 않는다.
+- 기술 분석/아키텍처 결정을 하지 않는다 (HOW는 crew-plan의 TechLead 영역).
+- 체크리스트가 전부 YES가 되기 전에 spec.md를 작성하지 않는다.
+- 유저 승인 없이 crew-plan으로 전환하지 않는다.
+- 추측으로 비즈니스 결정을 채우지 않는다.
+
+---
+
+## 파일 구조
+
+```
+.crew/plans/{task-id}/
+  brief.md          # 오케스트레이터: 유저 원본 요청
+  spec.md           # 오케스트레이터: 인터뷰 완료 후 결정화된 스펙
+```
+
+---
+
+## 실행 순서
+
+### Phase 1 — 초기화 (자동)
+
+**1a. task-id 생성 + brief.md 작성**
+
+유저 요청 원문을 `.crew/plans/{task-id}/brief.md`에 저장한다.
+task-id는 요청 내용에서 키워드를 추출하여 kebab-case로 생성한다.
+
+**1b. Explorer 호출 (병렬)**
+
+Explorer 서브에이전트를 병렬로 호출하여 프로젝트 구조를 파악한다.
+
+```
+Agent(subagent_type="explorer", description="프로젝트 구조 탐색", prompt="...")
+```
+
+탐색 목적:
+- 프로젝트 기술 스택, 주요 모듈 구조
+- 유저 요청과 관련된 기존 코드/기능 유무
+- 기존 패턴 (라우팅, 컴포넌트 구조, DB 모델 등)
+
+탐색 결과는 오케스트레이터가 내부적으로 보유한다. 파일로 저장하지 않는다.
+
+**1c. 체크리스트 첫 평가**
+
+유저 요청 + Explorer 결과를 기반으로 체크리스트 5개 항목을 첫 평가한다.
+
+```
+□ 개발자가 판단해야 할 비즈니스 결정이 없는가?
+□ 유저 플로우(정상 + 예외)가 정의되었는가?
+□ 스코프 경계(IN/OUT)가 명시되었는가?
+□ UI 구조와 주요 문구/콘텐츠가 정의되었는가?
+□ 완료 기준이 검증 가능한 형태로 있는가?
+```
+
+각 항목을 YES / NO / 해당없음 으로 판정한다.
+- YES: 유저 요청에서 이미 명확히 정의됨
+- NO: 정보 부족. 질문 필요
+- 해당없음: 이 작업에 적용되지 않음 (예: DB 마이그레이션에 UI 구조)
+
+**전부 YES 또는 해당없음이면**: Phase 2를 건너뛰고 Phase 3으로 직행한다.
+
+---
+
+### Phase 2 — 인터뷰 루프
+
+매 턴 아래 사이클을 반복한다:
+
+**2a. 체크리스트 평가**
+
+현재까지 수집된 정보를 기반으로 5개 항목을 재평가한다.
+
+**2b. 질문 대상 선택 (동적)**
+
+NO 항목 중 **가장 선행되어야 할 것**을 선택한다.
+
+판단 기준: "다른 항목의 답이 이 항목에 의존하는 정도". 예를 들어:
+- 스코프가 안 잡혀 있으면 → 스코프부터 (나머지 질문이 스코프에 의존)
+- 스코프가 잡혔는데 유저 플로우가 없으면 → 유저 플로우 (UI/콘텐츠가 플로우에 의존)
+- 비즈니스 규칙이 독립적이면 → 비즈니스 규칙
+
+**2c. 질문 생성**
+
+규칙:
+- **한 번에 질문 하나**. 여러 질문을 한꺼번에 던지지 않는다.
+- **객관식 우선**. 선택지를 2-3개 먼저 제시하고, 열린 질문은 보조로 사용한다.
+- **코드 탐색 결과 반영**. Explorer가 발견한 기존 코드/패턴을 질문에 활용한다.
+  예: "현재 코드에 JWT 인증이 있는데, 새 기능도 이 방식을 따를까요?"
+- **핵심 비즈니스 결정에는 2-3개 접근법을 제시**한다. 트레이드오프를 포함한다.
+  예: "가격 정책은? A) 월간만 — 단순 B) 월간+연간 — 수익 극대화 C) 무료+유료 — 유저 확보 우선"
+
+질문 형식:
+
+```
+[{현재 라운드}/{최대 20}] {타겟 항목}
+
+{질문}
+
+{선택지가 있는 경우}
+[1] {선택지 1} — {트레이드오프}
+[2] {선택지 2} — {트레이드오프}
+[3] {선택지 3} — {트레이드오프}
+[4] 직접 입력
+```
+
+**2d. Explorer 심화 탐색 (필요 시, 병렬)**
+
+유저 답변에서 언급된 구체적 영역의 코드를 추가 탐색해야 하면 Explorer를 병렬 호출한다.
+예: 유저가 "기존 결제 로직에 추가"라고 답하면 결제 관련 코드를 탐색.
+
+```
+Agent(subagent_type="explorer", description="결제 관련 코드 탐색", prompt="...")
+```
+
+**2e. 유저 답변 수신 + 큰 기획 갭 감지**
+
+유저 답변을 받은 후, 답변에서 연쇄적 하위 결정이 발생하는지 판단한다.
+
+큰 기획 갭의 징후:
+- 하나의 답변에서 3개 이상의 후속 결정이 연쇄적으로 필요
+- 답변 자체가 "아직 결정 안 됨", "모르겠다"이고, 그 범위가 독립된 시스템 설계 수준
+
+큰 기획 갭 발견 시:
+
+```
+이 부분은 인터뷰로 해결할 범위를 넘어서는 별도 기획이 필요합니다.
+
+## 부족한 기획 영역
+{무엇이 부족한지 구체적 설명}
+
+## 기획 시 결정해야 할 항목
+- {항목 1}
+- {항목 2}
+- ...
+
+## 기획 프롬프트
+다음 프롬프트로 별도 세션에서 기획을 진행하세요:
+
+\```
+{해당 기획을 진행할 수 있는 구체적 프롬프트}
+\```
+```
+
+인터뷰를 중단하고 종료한다.
+
+**2f. 체크리스트 재평가**
+
+답변을 반영하여 체크리스트를 재평가한다.
+- 전부 YES 또는 해당없음 → Phase 3으로
+- NO 남음 → 2a로 돌아감
+
+**2g. 라운드 제한**
+
+| 라운드 | 동작 |
+|--------|------|
+| 3+ | 조기 종료 가능. 유저에게 "현재 상태로 진행하시겠습니까?" 옵션 제공 (NO 항목이 남아있다는 경고 포함) |
+| 10 | 소프트 경고: "10라운드에 도달했습니다. 계속하시겠습니까, 현재 상태로 진행하시겠습니까?" |
+| 20 | 하드캡: "최대 라운드에 도달했습니다. 현재 상태로 spec을 작성합니다." (NO 항목은 경고와 함께 기록) |
+
+---
+
+### Phase 3 — Simplifier
+
+체크리스트 전부 YES (또는 조기 종료/하드캡) 후 실행한다.
+
+**3a. 스코프 정리**
+
+지금까지 확정된 전체 스코프를 정리하여 유저에게 보여준다.
+
+**3b. Simplifier 점검**
+
+각 스코프 항목에 대해 "v1에 꼭 필요한가?"를 판단한다.
+
+빼도 되는 항목이 있으면 유저에게 제안한다:
+
+```
+## v1 스코프 점검
+
+현재 스코프에서 v1에 꼭 필요하지 않을 수 있는 항목:
+
+- {항목 1} — 이유: {왜 v2로 미룰 수 있는지}
+- {항목 2} — 이유: {왜 v2로 미룰 수 있는지}
+
+[1] 제안대로 v2로 미루기
+[2] 일부만 v2로 미루기 (어떤 것?)
+[3] 전부 유지
+```
+
+유저 결정을 반영하여 스코프를 확정한다.
+
+빼도 되는 항목이 없으면 이 단계를 건너뛴다.
+
+---
+
+### Phase 4 — spec 결정화 + 유저 승인
+
+**4a. spec.md 작성**
+
+인터뷰 결과를 `.crew/plans/{task-id}/spec.md`에 구조화하여 작성한다.
+
+spec.md 구조 — **해당 섹션만 포함**한다. 해당 없는 섹션은 생략한다:
+
+```markdown
+# 요구사항: {task-id}
+
+## 목표
+한 문장으로: 이 기능이 해결하는 문제.
+
+## 스코프 경계
+- In: 반드시 구현되어야 하는 것
+- Out: 이번에 구현하지 않는 것 (명시적으로 제외)
+
+## 유저 플로우
+### 정상 플로우
+1. {단계 1}
+2. {단계 2}
+...
+
+### 예외 플로우
+- {예외 상황 1}: {처리 방식}
+- {예외 상황 2}: {처리 방식}
+
+## UI 구조 및 주요 콘텐츠
+### {화면/컴포넌트 1}
+- 구조: {레이아웃 설명}
+- 주요 문구:
+  - {요소}: "{텍스트}"
+  - {요소}: "{텍스트}"
+
+### {화면/컴포넌트 2}
+...
+
+## 비즈니스 규칙
+- {규칙 1}: {상세}
+- {규칙 2}: {상세}
+
+## 수용 기준
+- [ ] {테스트 가능한 구체적 행동 1}
+- [ ] {테스트 가능한 구체적 행동 2}
+- [ ] ...
+
+## 전제 조건
+이 태스크가 시작되기 전에 완료되어야 하는 것.
+```
+
+규칙:
+- 수용 기준은 최소 3개, 최대 7개. 모호한 표현("잘 작동한다", "빠르다") 금지.
+- 스코프가 "하루 작업"을 초과하면 분리를 권고한다.
+- 조기 종료/하드캡으로 진행한 경우, NO였던 항목을 spec.md 최하단에 경고로 기록한다:
+  ```markdown
+  ## ⚠ 미해소 항목
+  - {항목}: {무엇이 부족한지}
+  ```
+
+**4b. 유저에게 spec 제시**
+
+작성된 spec.md 전체를 유저에게 보여주고 판단을 요청한다:
+
+```
+spec.md를 작성했습니다. 검토해주세요.
+
+[1] 승인 — 이대로 확정
+[2] 수정 요청 — 특정 부분을 변경
+[3] 거부 — 인터뷰를 다시 진행
+```
+
+**4c. 유저 판단 처리**
+
+- **[1] 승인**:
+  ```
+  spec.md가 확정되었습니다.
+
+  [1] crew-plan으로 넘어가기
+  [2] 여기서 종료 (spec.md만 남김)
+  ```
+  - [1] 선택 시: `Skill("claude-crew:crew-plan")` 호출. task-id를 인수로 전달.
+  - [2] 선택 시: 종료.
+
+- **[2] 수정 요청**: 유저의 수정 사항을 반영하여 spec.md를 갱신한 후 4b로 돌아간다.
+
+- **[3] 거부**: Phase 2로 돌아간다. 체크리스트를 재평가하고 인터뷰를 재개한다.
+
+---
+
+## 에이전트 호출 규칙
+
+| 에이전트 | subagent_type | 모델 | 용도 | 호출 시점 |
+|----------|--------------|------|------|----------|
+| Explorer | explorer | haiku | 코드베이스 탐색 (read-only) | Phase 1b (필수), Phase 2d (필요 시) |
+| Researcher | researcher | sonnet | 외부 조사 (WebSearch) | Phase 2 중 필요 시 |
+
+**중요**: 모든 에이전트 호출 시 반드시 `subagent_type` 파라미터를 지정해야 한다. `subagent_type`이 없으면 PreToolUse hook이 호출을 차단한다. `model` 파라미터는 생략 가능 — hook이 에이전트 정의에서 자동 주입한다.
+
+---
+
+## 오케스트레이터 반환 스키마
+
+**COMPLETE**:
+```json
+{
+  "status": "COMPLETE",
+  "task_id": "{task-id}",
+  "spec_path": ".crew/plans/{task-id}/spec.md"
+}
+```
+
+**ESCALATE (큰 기획 갭)**:
+```json
+{
+  "status": "ESCALATE",
+  "phase": "interview-gap",
+  "reason": "별도 기획 필요: {영역}",
+  "planning_prompt": "{기획 프롬프트}"
+}
+```
+
+**ABORTED (유저 종료)**:
+```json
+{
+  "status": "ABORTED",
+  "task_id": "{task-id}",
+  "reason": "유저가 종료를 선택"
+}
+```

package/skills/crew-plan/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: crew-plan
-description: PM + TechLead + Planner + PlanEvaluator 계획 파이프라인 — contract.md를 생성한다
+description: TechLead + Planner + PlanEvaluator 계획 파이프라인 — contract.md를 생성한다
 ---
 
 ## 역할
 
-오케스트레이터로부터 task-id, brief, 의도 유형(유저 가치/엔지니어링)을 받아 `contract.md`를 생성한다.
+crew-interview가 생성한 spec.md를 입력으로 받아 **HOW(어떻게 만드는가)**를 결정하고 `contract.md`를 생성한다.
 `contract.md`가 생성되어야 crew-dev가 시작할 수 있다.
 
 에이전트 간 소통은 파일을 통해서만 이루어진다. 에이전트의 추론 과정은 다른 에이전트에게 전달되지 않는다.
@@ -16,7 +16,7 @@ description: PM + TechLead + Planner + PlanEvaluator 계획 파이프라인 —
 
 - 코드를 작성하지 않는다.
 - PlanEvaluator가 FAIL을 냈을 때 합리화하여 통과시키지 않는다.
-- brief.md를 Planner, PlanEvaluator에게 전달하지 않는다 (유저 가치 유형 시).
+- brief.md를 Planner, PlanEvaluator에게 전달하지 않는다.
 - 오케스트레이터가 요구사항을 판단하거나 보완하지 않는다.
 
 ---
@@ -25,8 +25,8 @@ description: PM + TechLead + Planner + PlanEvaluator 계획 파이프라인 —
 
 ```
 .crew/plans/{task-id}/
-  brief.md          # 오케스트레이터: 유저 원본 요청
-  spec.md           # PM: 수용 기준, 스코프 (유저 가치 유형만)
+  brief.md          # crew-interview: 유저 원본 요청
+  spec.md           # crew-interview: 인터뷰 완료 후 결정화된 스펙
   analysis.md       # TechLead: 사전 분석 결과
   plan.md           # Planner: 구현 계획 (항상 최신)
   review.md         # PlanEvaluator: 검증 결과 (항상 최신)
@@ -40,70 +40,25 @@ description: PM + TechLead + Planner + PlanEvaluator 계획 파이프라인 —
 
 ## 실행 순서
 
-### Step 1 — brief.md 작성 (오케스트레이터 직접)
+### Step 1 — spec.md 유효성 검사 (오케스트레이터 직접)
 
-`.crew/plans/{task-id}/brief.md`를 작성한다.
+`.crew/plans/{task-id}/spec.md`를 확인한다.
 
-- 유저 요청 원문 + 관련 컨텍스트만 기록한다.
-- 요구사항 판단/보완/해석 금지. 원문 그대로.
-
-**게이트**: brief.md 작성 완료 후 파일이 존재하고 비어 있지 않음을 확인한다.
+**게이트**: spec.md가 존재하고 비어 있지 않음을 확인한다.
 실패 시 즉시 에스컬레이션:
 
 ```
-brief.md가 없거나 비어 있습니다. 계획 파이프라인을 시작할 수 없습니다.
-[1] brief.md를 직접 작성하여 재시도
-[2] 이 태스크를 보류
-```
-
----
-
-### Step 2 — PM 에이전트 실행 (유저 가치 유형만)
-
-**모델**: opus
-**건너뛰기 조건**: 엔지니어링 유형이면 이 단계를 건너뛴다.
-
-호출:
-
-```
-Agent(subagent_type="pm", description="PM: {task-id} 요구사항 정의", prompt="...")
-```
-
-에이전트 프롬프트:
-
-```
-당신은 PM 에이전트다. 유저와 직접 대화하여 요구사항을 확정한다.
-
-## 입력
-.crew/plans/{task-id}/brief.md 를 읽어라.
-
-## 출력
-.crew/plans/{task-id}/spec.md 를 작성하라.
-
-spec.md 필수 섹션: 목표, 스코프 경계(In/Out), 수용 기준(3-7개, 테스트 가능한 구체적 행동), 전제 조건, 미결사항.
-
-## 규칙
-- 정보가 부족하면 AskUserQuestion으로 유저에게 직접 질문하라.
-- 추측으로 빈칸을 채우지 않는다.
-- 수용 기준에 모호한 표현("잘 작동한다", "빠르다") 금지.
-- 스코프가 "하루 작업"을 초과하면 분리를 권고하라.
-```
-
-**실패 조건**: spec.md가 없거나 수용 기준이 비어 있으면 즉시 에스컬레이션.
-
-```
-PM 에이전트가 요구사항 정의에 실패했습니다.
-[1] brief.md를 보완하여 재시도
-[2] spec.md를 직접 작성
+spec.md가 없거나 비어 있습니다. crew-interview를 먼저 실행해야 합니다.
+[1] crew-interview를 실행하여 spec.md를 생성
+[2] spec.md를 직접 작성하여 재시도
 [3] 이 태스크를 보류
 ```
 
 ---
 
-### Step 3 — TechLead 에이전트 실행
+### Step 2 — TechLead 에이전트 실행
 
 **모델**: opus
-**실행 조건**: 항상 (양쪽 유형 모두)
 
 호출:
 
@@ -117,8 +72,10 @@ Agent(subagent_type="techlead", description="TechLead: {task-id} 사전 분석",
 당신은 TechLead 에이전트다. 사전 분석을 수행하고 아키텍처 방향을 판단한다.
 
 ## 입력
-{유저 가치 유형}: .crew/plans/{task-id}/spec.md 를 읽어라.
-{엔지니어링 유형}: .crew/plans/{task-id}/brief.md 를 읽어라.
+.crew/plans/{task-id}/spec.md 를 읽어라.
+
+spec.md에는 목표, 스코프 경계, 유저 플로우, UI 구조, 비즈니스 규칙, 수용 기준이 포함되어 있다.
+WHAT(무엇을 만드는가)은 이미 정의되어 있으므로, HOW(어떻게 만드는가)에 집중하라.
 
 ## 서브에이전트 호출
 - Explorer (Haiku): 코드베이스 탐색. 항상 호출. 병렬 2-3개로 호출하라.
@@ -141,7 +98,7 @@ Agent(subagent_type="techlead", description="TechLead: {task-id} 사전 분석",
 - 탐색(양)은 서브에이전트에게, 판단(질)은 직접.
 ```
 
-**Step 3 결과 저장 (오케스트레이터 직접)**:
+**Step 2 결과 저장 (오케스트레이터 직접)**:
 
 TechLead 에이전트는 read-only이므로 파일을 직접 작성하지 않는다.
 오케스트레이터가 TechLead의 반환 텍스트를 `.crew/plans/{task-id}/analysis.md`로 저장한다.
@@ -150,7 +107,7 @@ TechLead 에이전트는 read-only이므로 파일을 직접 작성하지 않는
 
 ---
 
-### Step 3.5 — 테스트 전략 결정 (오케스트레이터 직접)
+### Step 2.5 — 테스트 전략 결정 (오케스트레이터 직접)
 
 TechLead의 analysis.md에서 테스트 인프라 섹션을 확인한 후, 오케스트레이터가 유저에게 테스트 전략을 질문한다.
 
@@ -192,7 +149,7 @@ TechLead의 analysis.md에서 테스트 인프라 섹션을 확인한 후, 오
 
 ---
 
-### Step 4 — Planner 에이전트 실행
+### Step 3 — Planner 에이전트 실행
 
 **모델**: opus
 
@@ -208,8 +165,8 @@ Agent(subagent_type="planner", description="Planner: {task-id} 구현 계획", p
 당신은 Planner 에이전트다. 구현 계획을 작성한다.
 
 ## 입력
+.crew/plans/{task-id}/spec.md 를 읽어라.
 .crew/plans/{task-id}/analysis.md 를 읽어라.
-{유저 가치 유형 시}: .crew/plans/{task-id}/spec.md 도 읽어라.
 brief.md는 읽지 않는다.
 
 ## 출력
@@ -241,6 +198,7 @@ plan.md 최상단에 `## 테스트 전략` 섹션을 두어 결정 사항을 명
 ## 규칙
 - 코드를 작성하지 않는다.
 - analysis.md의 아키텍처 방향과 가드레일을 따른다.
+- spec.md에 정의된 비즈니스 규칙을 그대로 따른다. 임의로 비즈니스 결정을 추가하지 않는다.
 - 태스크 하나가 4시간 초과 시 분해한다.
 - "나중에 결정" 금지. 모르면 위험 요소에 기록.
 - 필요시 Explorer 서브에이전트를 호출할 수 있다.
@@ -252,8 +210,8 @@ plan.md 최상단에 `## 테스트 전략` 섹션을 두어 결정 사항을 명
 이번은 이전 계획이 리뷰에서 FAIL을 받은 후 재작성하는 것이다.
 
 ## 입력
+.crew/plans/{task-id}/spec.md 를 읽어라.
 .crew/plans/{task-id}/analysis.md 를 읽어라.
-{유저 가치 유형 시}: .crew/plans/{task-id}/spec.md 도 읽어라.
 .crew/plans/{task-id}/review-{n}.md 를 읽어라.
 brief.md는 읽지 않는다.
 
@@ -266,6 +224,7 @@ plan.md 최상단에 "이전 피드백 반영" 섹션을 추가한다.
 
 ## 규칙
 - analysis.md의 아키텍처 방향과 가드레일을 따른다.
+- spec.md에 정의된 비즈니스 규칙을 그대로 따른다. 임의로 비즈니스 결정을 추가하지 않는다.
 - 피드백을 무시하거나 같은 내용으로 작성하지 않는다.
 ```
 
@@ -273,7 +232,7 @@ plan.md 최상단에 "이전 피드백 반영" 섹션을 추가한다.
 
 ---
 
-### Step 5 — PlanEvaluator 에이전트 실행
+### Step 4 — PlanEvaluator 에이전트 실행
 
 **모델**: sonnet (하드 임계값 판정에서 Opus 합리화 방지)
 
@@ -289,29 +248,29 @@ Agent(subagent_type="plan-evaluator", description="PlanEvaluator: {task-id} 계
 당신은 PlanEvaluator 에이전트다. 계획을 검증한다.
 
 ## 입력
-{유저 가치 유형}: .crew/plans/{task-id}/spec.md + .crew/plans/{task-id}/analysis.md + .crew/plans/{task-id}/plan.md
-{엔지니어링 유형}: .crew/plans/{task-id}/brief.md + .crew/plans/{task-id}/analysis.md + .crew/plans/{task-id}/plan.md
-이 파일만 읽는다. 유저 가치 유형에서 brief.md는 읽지 않는다.
+.crew/plans/{task-id}/spec.md + .crew/plans/{task-id}/analysis.md + .crew/plans/{task-id}/plan.md
+이 파일만 읽는다. brief.md는 읽지 않는다.
 
 ## 검증 항목 (하드 임계값)
 아래 각 항목에 YES 또는 NO로만 답한다. 부분 점수 없음.
 
 [ ] E1. 검증 시나리오 완성도 — 모든 태스크에 검증 방법이 명시되어 있는가?
-[ ] E2. 요구사항 정합성 — 수용 기준이 전부 태스크로 커버되는가?
+[ ] E2. spec 전체 커버리지 — spec.md의 수용 기준, 유저 플로우, UI 구조, 비즈니스 규칙이 전부 태스크로 커버되는가? (수용 기준만이 아니라 spec 전체를 검증)
 [ ] E3. 코드 참조 사실 여부 — 언급한 파일/모듈이 존재하는가? (Explorer 서브에이전트 호출)
 [ ] E4. 실행 가능성 — 구현자가 바로 시작할 수 있는 수준인가?
 [ ] E5. 테스트 전략 정합성 — analysis.md의 테스트 전략 결정과 plan.md의 태스크 구조가 일치하는가?
   - TDD: 각 구현 태스크가 RED→GREEN→REFACTOR 순서로 구성되어 있는가? 테스트 파일 경로가 명시되어 있는가?
   - Tests-after: 구현 태스크 뒤에 테스트 작성 태스크가 있는가? 테스트 파일 경로가 명시되어 있는가?
   - None: 이 항목을 YES로 처리한다.
+[ ] E6. 비즈니스 가정 0개 — plan.md가 spec.md에 없는 비즈니스 로직을 임의로 추가하지 않았는가? plan에 "~로 가정", "~로 판단" 등 spec에 근거 없는 비즈니스 결정이 있으면 NO.
 
 ## 판정 규칙
-- 5개 항목 모두 YES → PASS
+- 6개 항목 모두 YES → PASS
 - 하나라도 NO → FAIL
 - "아마 의도했을 것"이라고 추측하지 않는다. 모호하면 NO.
 
 ## FAIL 시 근본 원인 분류 (필수)
-- spec 결함 (수용 기준 자체가 문제) → 오케스트레이터에 알린다
+- spec 결함 (spec.md 자체가 문제) → 오케스트레이터에 알린다
 - plan 결함 (계획 구성/표현 문제) → Planner 재시도 가능
 
 ## E3 코드 참조 확인
@@ -320,37 +279,45 @@ Agent(subagent_type="explorer", description="코드 참조 확인: {파일 목
 
 ## 출력
 아래 형식으로 검증 결과를 텍스트로 반환하라. 파일을 직접 작성하지 않는다.
-형식: 판정(PASS/FAIL), 항목별 결과(E1-E5 YES/NO + 근거), FAIL 상세(NO 항목의 문제+수정 방향), 근본 원인 분류(FAIL 시).
+형식: 판정(PASS/FAIL), 항목별 결과(E1-E6 YES/NO + 근거), FAIL 상세(NO 항목의 문제+수정 방향), 근본 원인 분류(FAIL 시).
 ```
 
-**Step 5 결과 저장 (오케스트레이터 직접)**:
+**Step 4 결과 저장 (오케스트레이터 직접)**:
 
 PlanEvaluator 에이전트는 read-only이므로 파일을 직접 작성하지 않는다.
 오케스트레이터가 PlanEvaluator의 반환 텍스트를 `.crew/plans/{task-id}/review.md`로 저장한다.
 
 ---
 
-### Step 6 — PASS 처리
+### Step 5 — PASS 처리
 
 PlanEvaluator PASS이면:
 
-**6a. review.md 확인**
+**5a. review.md 확인**
 
 review.md가 정상적으로 작성되었고 판정이 PASS임을 확인한다.
 
-**6b. contract.md 작성 (오케스트레이터 직접)**
+**5b. contract.md 작성 (오케스트레이터 직접)**
 
 ```markdown
 # 스프린트 계약: {task-id}
 
 생성일: {date}
-유형: {유저 가치 | 엔지니어링}
 
 ## 목표
-{spec.md 또는 brief.md에서 추출한 한 문장}
+{spec.md에서 추출한 한 문장}
 
 ## 수용 기준
-- [ ] {spec.md의 수용 기준을 그대로 복사 (유저 가치) 또는 brief.md에서 도출 (엔지니어링)}
+- [ ] {spec.md의 수용 기준을 그대로 복사}
+
+## 유저 플로우
+{spec.md의 유저 플로우 섹션이 있으면 그대로 복사}
+
+## UI 구조 및 주요 콘텐츠
+{spec.md의 UI 구조 섹션이 있으면 그대로 복사}
+
+## 비즈니스 규칙
+{spec.md의 비즈니스 규칙 섹션이 있으면 그대로 복사}
 
 ## 가드레일
 ### Must
@@ -373,6 +340,7 @@ review.md가 정상적으로 작성되었고 판정이 PASS임을 확인한다.
 - 기대 결과: {검증할 것}
 
 ## 참조 문서
+- 요구사항: .crew/plans/{task-id}/spec.md
 - 사전 분석: .crew/plans/{task-id}/analysis.md
 - 구현 계획: .crew/plans/{task-id}/plan.md
 
@@ -383,11 +351,11 @@ PlanEvaluator PASS — review.md 참조
 ACTIVE
 ```
 
-**6c. .loop_count 정리**
+**5c. .loop_count 정리**
 
 `.loop_count` 파일이 존재하면 삭제한다.
 
-**6d. 완료 반환**
+**5d. 완료 반환**
 
 ```
 상태: COMPLETE
@@ -397,22 +365,22 @@ contract.md 경로: .crew/plans/{task-id}/contract.md
 
 ---
 
-### Step 7 — FAIL 처리 (피드백 보존 루프)
+### Step 6 — FAIL 처리 (피드백 보존 루프)
 
 PlanEvaluator FAIL이면:
 
-**7a. FAIL 원인 분류**
+**6a. FAIL 원인 분류**
 
 PlanEvaluator가 review.md에 기록한 근본 원인 분류를 확인한다.
 
-- **spec 결함** (수용 기준 자체가 문제):
+- **spec 결함** (spec.md 자체가 문제):
   - Planner를 재시도해도 고칠 수 없다.
   - 즉시 에스컬레이션:
 
 ```
 PlanEvaluator가 spec 결함을 이유로 FAIL을 냈습니다.
 Planner 재시도로는 해결할 수 없습니다.
-[1] PM 에이전트를 재실행하여 spec.md를 재작성
+[1] crew-interview를 재실행하여 spec.md를 재작성
 [2] spec.md를 직접 수정
 [3] 이 태스크를 보류
 ```
@@ -420,13 +388,13 @@ Planner 재시도로는 해결할 수 없습니다.
 - **plan 결함** (계획 구성/표현 문제):
   - 피드백 보존 루프를 진행한다.
 
-**7b. 루프 카운터 읽기**
+**6b. 루프 카운터 읽기**
 
 `.crew/plans/{task-id}/.loop_count` 파일을 읽는다.
 - 파일이 없으면 카운터 = 0 (첫 번째 FAIL)
 - 파일이 있으면 파일 내용(정수)이 카운터 값
 
-**7c. 에스컬레이션 판단**
+**6c. 에스컬레이션 판단**
 
 카운터 값 >= 4이면 즉시 에스컬레이션:
 
@@ -440,7 +408,7 @@ Planner 재시도로는 해결할 수 없습니다.
 
 에스컬레이션 시 `.loop_count` 파일을 삭제한다.
 
-**7d. 피드백 아카이브**
+**6d. 피드백 아카이브**
 
 `n = 카운터 + 1` (이번 회차 번호)
 
@@ -449,13 +417,13 @@ plan.md → plan-{n}.md 로 이름 변경
 review.md → review-{n}.md 로 이름 변경
 ```
 
-**7e. 루프 카운터 증가 저장**
+**6e. 루프 카운터 증가 저장**
 
 `카운터 + 1`을 `.loop_count` 파일에 저장한다.
 
-**7f. Step 4로 돌아감 (retry)**
+**6f. Step 3로 돌아감 (retry)**
 
-Step 4(Planner)로 돌아간다. retry 프롬프트의 `{n}`에 Step 7d에서 계산한 값을 대입한다.
+Step 3(Planner)로 돌아간다. retry 프롬프트의 `{n}`에 Step 6d에서 계산한 값을 대입한다.
 TechLead는 재실행하지 않는다 — 기술적 사실은 변하지 않으므로 analysis.md를 재사용한다.
 
 ---
@@ -478,11 +446,10 @@ Planner + PlanEvaluator 사이클은 최대 5회 (초기 1회 + retry 최대 4
 
 | 에이전트 | subagent_type | 모델 | 주입할 파일 | 차단할 파일 |
 |----------|--------------|------|------------|------------|
-| PM | pm | opus | brief.md | — |
-| TechLead | techlead | opus | spec.md (유저 가치) 또는 brief.md (엔지니어링) | — |
-| Planner (첫 번째) | planner | opus | spec.md (유저 가치 시) + analysis.md | brief.md |
-| Planner (retry) | planner | opus | spec.md (유저 가치 시) + analysis.md + review-{n}.md | brief.md |
-| PlanEvaluator | plan-evaluator | sonnet | spec.md/brief.md + analysis.md + plan.md | brief.md (유저 가치 시) |
+| TechLead | techlead | opus | spec.md | — |
+| Planner (첫 번째) | planner | opus | spec.md + analysis.md | brief.md |
+| Planner (retry) | planner | opus | spec.md + analysis.md + review-{n}.md | brief.md |
+| PlanEvaluator | plan-evaluator | sonnet | spec.md + analysis.md + plan.md | brief.md |
 
 **중요**: 모든 에이전트 호출 시 반드시 `subagent_type` 파라미터를 지정해야 한다. `subagent_type`이 없으면 PreToolUse hook이 호출을 차단한다. `model` 파라미터는 생략 가능 — hook이 에이전트 정의에서 자동 주입한다.
 
@@ -503,7 +470,7 @@ Planner + PlanEvaluator 사이클은 최대 5회 (초기 1회 + retry 최대 4
 ```json
 {
   "status": "ESCALATE",
-  "phase": "brief-gate" | "pm-fail" | "techlead-fail" | "planner-fail" | "evaluator-spec-defect" | "loop-overflow",
+  "phase": "spec-gate" | "techlead-fail" | "planner-fail" | "evaluator-spec-defect" | "loop-overflow",
   "reason": "자유형 텍스트"
 }
 ```