@jjlabsio/claude-crew 0.1.8 → 0.1.10

package/.claude-plugin/marketplace.json

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

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-crew",
-  "version": "0.1.8",
+  "version": "0.1.10",
   "description": "1인 SaaS 개발자를 위한 멀티 에이전트 오케스트레이션 — 개발, 마케팅, 일정을 한 대화에서 통합 관리",
   "author": {
     "name": "Jaejin Song",

package/hud/index.mjs

@@ -281,13 +281,14 @@ function renderAgentsMultiLine(agents, maxLines = 5) {
     const isLast = index === displayCount - 1 && sorted.length <= maxLines;
     const prefix = isLast ? '\u2514\u2500' : '\u251c\u2500';
 
-    const name = a.type.padEnd(12);
+    const rawType = a.type.includes(':') ? a.type.split(':').pop() : a.type;
+    const name = rawType.padEnd(7);
     const model = shortModelName(a.model).padEnd(8);
     const duration = formatAgentDuration(a.startTime).padStart(4);
     const desc = a.description.length > 40 ? a.description.slice(0, 37) + '...' : a.description;
 
     detailLines.push(
-      `${dim(prefix)} ${cyan(name)}${model}${dim(duration)}   ${desc}`
+      `${dim(prefix)} ${cyan(name)} ${model}${dim(duration)}   ${desc}`
     );
   });
 

package/package.json

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

package/skills/crew-dev/SKILL.md

@@ -21,6 +21,7 @@ description: contract.md를 입력으로 받아 Dev + CodeReviewer + QA 파이
 - brief.md를 어떤 에이전트에게도 전달하지 않는다.
 - contract.md를 CodeReviewer에게 전달하지 않는다 (가드레일만 인라인 주입).
 - plan.md를 CodeReviewer에게 전달하지 않는다.
+- git commit 시 `--no-verify`를 생략하지 않는다 (호스트 프로젝트의 pre-commit hook 중복 실행 방지).
 - Dev가 자체 검증을 통과하지 못한 상태에서 검증 단계로 넘기지 않는다.
 
 ---
@@ -52,7 +53,7 @@ description: contract.md를 입력으로 받아 Dev + CodeReviewer + QA 파이
 | 에이전트 | subagent_type | 볼 수 있는 것 | 차단 | 차단 근거 |
 |----------|--------------|-------------|------|----------|
 | **Dev** | dev | plan.md, contract.md | brief.md, spec.md, analysis.md | 의도 추측 방지, plan+contract에 필요 정보 포함 |
-| **CodeReviewer** | code-reviewer | git diff, 가드레일(인라인) | contract.md, plan.md, brief.md, spec.md, dev-log.md | 수용 기준 체리피킹 방지 |
+| **CodeReviewer** | code-reviewer | git diff(직접 실행), 가드레일(인라인) | contract.md, plan.md, brief.md, spec.md, dev-log.md | 수용 기준 체리피킹 방지 (.crew/는 .gitignore 대상이므로 diff에 노출되지 않음) |
 | **QA** | qa | plan.md | contract.md, brief.md, spec.md | 검증 편향 방지 |
 
 **중요**: 모든 에이전트 호출 시 반드시 `subagent_type` 파라미터를 지정해야 한다. HUD에서 에이전트 타입을 식별하는 데 사용된다.
@@ -120,15 +121,23 @@ brief.md, spec.md, analysis.md는 읽지 않는다.
 
 ## 작업 순서
 1. plan.md의 유저 스토리와 태스크 목록을 확인한다.
-2. 코드베이스를 탐색한다 (Glob, Grep, Read로 관련 파일 파악).
-3. 유저 스토리 단위로 순차 구현한다.
-4. 각 유저 스토리 완료 후 dev-log.md에 진행상황을 기록한다.
-5. 모든 구현 완료 후 자체 검증을 실행한다:
+2. plan.md의 `## 테스트 전략` 섹션을 확인한다.
+3. 코드베이스를 탐색한다 (Glob, Grep, Read로 관련 파일 파악).
+4. 유저 스토리 단위로 순차 구현한다.
+   - **TDD인 경우**: 각 태스크에서 반드시 RED→GREEN→REFACTOR 순서를 따른다.
+     1. RED: 실패하는 테스트를 먼저 작성하고 실행하여 FAIL을 확인한다.
+     2. GREEN: 테스트를 통과하는 최소한의 코드를 작성한다.
+     3. REFACTOR: 코드 품질을 개선한다 (필요시).
+   - **Tests-after인 경우**: 구현을 먼저 완료한 후, plan.md에 명시된 테스트 태스크를 수행한다.
+   - **None인 경우**: 현재와 동일하게 구현한다.
+5. 각 유저 스토리 완료 후 dev-log.md에 진행상황을 기록한다.
+6. 모든 구현 완료 후 자체 검증을 실행한다:
    - 빌드 성공 확인
    - 린트 통과 확인
    - 타입 체크 통과 확인
    - 기존 테스트 스위트 통과 확인
-6. 자체 검증이 모두 통과하면 완료를 선언한다.
+   - lint-staged 검증: `npx lint-staged --dry-run` 실행 (설정이 있는 경우에만)
+7. 자체 검증이 모두 통과하면 완료를 선언한다.
    자체 검증이 실패하면 직접 수정하여 통과시킨다.
 
 ## 출력
@@ -136,8 +145,9 @@ brief.md, spec.md, analysis.md는 읽지 않는다.
 
 ## 규칙
 - plan.md에 없는 것을 구현하지 않는다 (스코프 크리프 금지).
-- 자체 검증 4개(빌드/린트/타입/테스트) 모두 PASS 해야 완료를 선언할 수 있다.
+- 자체 검증 5개(빌드/린트/타입/테스트/lint-staged) 모두 PASS 해야 완료를 선언할 수 있다.
 - 기존 코드베이스의 컨벤션을 따른다.
+- TDD 전략인 경우, 테스트를 먼저 작성하지 않고 프로덕션 코드를 작성하지 않는다.
 ```
 
 **retry 시 에이전트 프롬프트**:
@@ -159,11 +169,11 @@ brief.md, spec.md, analysis.md는 읽지 않는다.
 1. 피드백에서 FAIL 항목을 모두 파악한다.
 2. 각 FAIL 항목에 대해 수정을 수행한다.
 3. dev-log.md를 갱신한다 (최상단에 "수정 이력 (retry {n})" 섹션 추가).
-4. 자체 검증 4개를 모두 다시 실행한다.
+4. 자체 검증 5개를 모두 다시 실행한다.
 
 ## 규칙
 - 피드백에서 지적하지 않은 부분을 추가로 변경하지 않는다.
-- 자체 검증 4개 모두 PASS 해야 완료를 선언할 수 있다.
+- 자체 검증 5개 모두 PASS 해야 완료를 선언할 수 있다.
 ```
 
 **Phase 2 실패 조건**: Dev 에이전트가 자체 검증을 통과하지 못한 채 완료를 선언하면 에스컬레이션.
@@ -181,9 +191,8 @@ CodeReviewer와 QA를 **동시에** Agent tool 2개로 호출한다.
 에이전트 호출 시 반드시 `subagent_type: "code-reviewer"`를 지정한다.
 
 오케스트레이터가 해야 할 사전 작업:
-1. `git diff main...HEAD` 출력을 캡처한다.
-2. contract.md에서 가드레일 섹션(Must/Must NOT)만 추출한다.
-3. 둘 다 CodeReviewer 프롬프트에 인라인으로 주입한다.
+1. contract.md에서 가드레일 섹션(Must/Must NOT)만 추출한다.
+2. 가드레일을 CodeReviewer 프롬프트에 인라인으로 주입한다.
 
 에이전트 프롬프트:
 
@@ -191,13 +200,10 @@ CodeReviewer와 QA를 **동시에** Agent tool 2개로 호출한다.
 당신은 CodeReviewer 에이전트다. 코드 변경 사항의 품질을 판단한다.
 
 ## 입력
-아래 diff를 검토하라. 이것이 검토 대상의 전부다.
+`git diff main...HEAD`를 직접 실행하여 변경 사항을 확인하라.
 contract.md, plan.md, brief.md, spec.md, dev-log.md는 읽지 않는다.
 코드만 보고 판단한다.
 
-### diff
-{git diff main...HEAD 출력}
-
 ### 가드레일 (contract.md에서 추출)
 #### Must
 - {오케스트레이터가 contract.md에서 복사한 내용}
@@ -244,13 +250,17 @@ contract.md, brief.md, spec.md는 읽지 않는다.
 2. 린트 검증
 3. 타입 체크 검증
 4. 테스트 스위트 검증
-5. E2E / 통합 검증 — plan.md의 테스트 시나리오 기반
+5. 테스트 전략 준수 검증 (TDD 또는 Tests-after인 경우)
+   - plan.md에 명시된 테스트 파일이 실제로 존재하는가?
+   - 해당 테스트가 실행되고 통과하는가?
+   - None인 경우 이 항목을 PASS로 처리한다.
+6. E2E / 통합 검증 — plan.md의 테스트 시나리오 기반
 
 ## 출력
 .crew/plans/{task-id}/qa-report.md 를 작성하라.
 
 ## 판정 규칙
-- 항목 1-5 중 하나라도 FAIL → 전체 FAIL
+- 항목 1-6 중 하나라도 FAIL → 전체 FAIL
 - 모든 항목 PASS → 전체 PASS
 
 ## 규칙
@@ -286,10 +296,12 @@ Agent(name="qa", subagent_type="qa", model="sonnet", prompt="...")
 
 ```bash
 git add -A
-git commit -m "feat({task-id}): {contract.md 목표 1줄 요약}"
+git commit --no-verify -m "feat({task-id}): {contract.md 목표 1줄 요약}"
 git push -u origin feat/{task-id}
 ```
 
+> `--no-verify`: crew-dev가 이미 빌드/린트/타입/테스트 + lint-staged 검증을 완료했으므로 호스트 프로젝트의 pre-commit hook을 중복 실행하지 않는다.
+
 PR을 생성한다 (머지하지 않는다).
 
 **5b. 상태 갱신**

package/skills/crew-plan/SKILL.md

@@ -115,13 +115,18 @@ PM 에이전트가 요구사항 정의에 실패했습니다.
 ## 서브에이전트 호출
 - Explorer (Haiku): 코드베이스 탐색. 항상 호출. 병렬 2-3개로 호출하라.
   Agent(description="코드베이스 탐색", model="haiku", prompt="...")
+  **필수 탐색 항목**: 테스트 인프라도 반드시 탐색한다. Explorer 중 1개는 다음을 확인:
+  - 테스트 프레임워크 설정 파일 (jest.config.*, vitest.config.*, pytest.ini 등)
+  - 대표적인 테스트 파일 2-3개의 패턴
+  - 커버리지 설정 여부
+  - 테스트 실행 스크립트 (package.json scripts 등)
 - Researcher (Sonnet): 외부 리서치. 필요시만 호출.
   Agent(description="외부 리서치", model="sonnet", prompt="...")
 
 ## 출력
 .crew/plans/{task-id}/analysis.md 를 작성하라.
 
-analysis.md 필수 섹션: 요구사항 보완, 코드베이스 맥락(관련 파일/기존 패턴/테스트 구조), 아키텍처 방향(권장+대안), 엣지 케이스/리스크, 가드레일(Must/Must NOT), 외부 리서치(해당 시).
+analysis.md 필수 섹션: 요구사항 보완, 코드베이스 맥락(관련 파일/기존 패턴/테스트 구조), 아키텍처 방향(권장+대안), 엣지 케이스/리스크, 가드레일(Must/Must NOT), 테스트 인프라(프레임워크/패턴/유무), 외부 리서치(해당 시).
 
 ## 규칙
 - 요구사항에 빈틈이 있으면 AskUserQuestion으로 유저에게 직접 질문하라.
@@ -132,6 +137,48 @@ analysis.md 필수 섹션: 요구사항 보완, 코드베이스 맥락(관련
 
 ---
 
+### Step 3.5 — 테스트 전략 결정 (오케스트레이터 직접)
+
+TechLead의 analysis.md에서 테스트 인프라 섹션을 확인한 후, 오케스트레이터가 유저에게 테스트 전략을 질문한다.
+
+**테스트 인프라가 있는 경우**:
+
+```
+테스트 인프라가 감지되었습니다: {프레임워크명}
+테스트 전략을 선택하세요:
+[1] TDD — 각 태스크를 RED(실패 테스트) → GREEN(최소 구현) → REFACTOR로 구성
+[2] Tests-after — 구현 태스크 완료 후 테스트 태스크 추가
+[3] None — 자동화 테스트 없음 (QA 에이전트 검증만)
+```
+
+**테스트 인프라가 없는 경우**:
+
+```
+테스트 인프라가 감지되지 않았습니다.
+테스트 전략을 선택하세요:
+[1] TDD — 테스트 인프라 셋업 후 RED → GREEN → REFACTOR로 구현
+[2] Tests-after — 테스트 인프라 셋업 후 구현 완료 뒤 테스트 추가
+[3] None — 자동화 테스트 없음 (QA 에이전트 검증만)
+```
+
+[1] 또는 [2] 선택 시 인프라가 없으면 추가 질문:
+
+```
+테스트 프레임워크를 선택하세요:
+[1] vitest  [2] jest  [3] bun test  [4] pytest  [5] 기타 (직접 입력)
+```
+
+**결과 기록**: 선택된 테스트 전략을 analysis.md 하단에 추가한다:
+
+```markdown
+## 테스트 전략
+- 결정: {TDD | Tests-after | None}
+- 프레임워크: {기존 감지된 프레임워크 또는 유저 선택}
+- 인프라 셋업 필요: {YES | NO}
+```
+
+---
+
 ### Step 4 — Planner 에이전트 실행
 
 **모델**: opus
@@ -153,6 +200,27 @@ brief.md는 읽지 않는다.
 
 plan.md 필수 구조: 유저 스토리(US-N) 단위. 각 유저 스토리에 구현 태스크 + 테스트 시나리오(최소 2개: 정상+에러). 위험 요소 섹션. 검증 시나리오 섹션(조건/행위/기대 결과 — contract.md에 그대로 포함됨).
 
+## 테스트 전략
+analysis.md의 `## 테스트 전략` 섹션을 확인하고, 결정에 따라 태스크 구조를 달리한다.
+
+### TDD인 경우
+- 인프라 셋업이 필요하면 첫 번째 태스크로 "테스트 인프라 셋업"을 추가한다.
+- 각 유저 스토리의 구현 태스크를 다음 순서로 구성한다:
+  1. RED — 실패하는 테스트 작성 (테스트 파일 경로 명시)
+  2. GREEN — 테스트를 통과하는 최소한의 코드 작성
+  3. REFACTOR — 코드 품질 개선 (필요시)
+- 각 태스크의 수용 기준에 포함: `테스트 파일: {경로}`, `테스트 실행 결과: PASS`
+
+### Tests-after인 경우
+- 인프라 셋업이 필요하면 첫 번째 태스크로 "테스트 인프라 셋업"을 추가한다.
+- 구현 태스크를 먼저 나열한 후, 별도의 테스트 작성 태스크를 추가한다.
+- 테스트 태스크의 수용 기준에 포함: `테스트 파일: {경로}`, `테스트 실행 결과: PASS`
+
+### None인 경우
+- 현재와 동일. 자동화 테스트 태스크 없이 검증 시나리오만 포함한다.
+
+plan.md 최상단에 `## 테스트 전략` 섹션을 두어 결정 사항을 명시한다.
+
 ## 규칙
 - 코드를 작성하지 않는다.
 - analysis.md의 아키텍처 방향과 가드레일을 따른다.
@@ -211,9 +279,13 @@ plan.md 최상단에 "이전 피드백 반영" 섹션을 추가한다.
 [ ] E2. 요구사항 정합성 — 수용 기준이 전부 태스크로 커버되는가?
 [ ] E3. 코드 참조 사실 여부 — 언급한 파일/모듈이 존재하는가? (Explorer 서브에이전트 호출)
 [ ] E4. 실행 가능성 — 구현자가 바로 시작할 수 있는 수준인가?
+[ ] E5. 테스트 전략 정합성 — analysis.md의 테스트 전략 결정과 plan.md의 태스크 구조가 일치하는가?
+  - TDD: 각 구현 태스크가 RED→GREEN→REFACTOR 순서로 구성되어 있는가? 테스트 파일 경로가 명시되어 있는가?
+  - Tests-after: 구현 태스크 뒤에 테스트 작성 태스크가 있는가? 테스트 파일 경로가 명시되어 있는가?
+  - None: 이 항목을 YES로 처리한다.
 
 ## 판정 규칙
-- 4개 항목 모두 YES → PASS
+- 5개 항목 모두 YES → PASS
 - 하나라도 NO → FAIL
 - "아마 의도했을 것"이라고 추측하지 않는다. 모호하면 NO.
 
@@ -261,6 +333,11 @@ review.md가 정상적으로 작성되었고 판정이 PASS임을 확인한다.
 ### Must NOT
 - {analysis.md에서 추출}
 
+## 테스트 전략
+- 결정: {TDD | Tests-after | None}
+- 프레임워크: {프레임워크명}
+- 인프라 셋업 필요: {YES | NO}
+
 ## 검증 시나리오
 {plan.md의 검증 시나리오 섹션을 그대로 복사}
 

package/skills/crew/SKILL.md

@@ -1,189 +0,0 @@
----
-name: crew
-description: crew-plan과 crew-dev를 연결하는 오케스트레이터 — 유저 요청을 받아 PR 생성까지
----
-
-## 역할
-
-유저 요청을 받아 crew-plan(계획)과 crew-dev(구현)를 순차 실행하여 PR을 생성한다.
-코드를 작성하지 않는다. 에이전트에게 위임한다.
-
----
-
-## 절대 금지
-
-- 코드를 직접 작성, 수정, 검토하지 않는다.
-- 기획, 계획, 검증을 직접 수행하지 않는다. 해당 에이전트에게 위임한다.
-- 에이전트가 FAIL을 냈을 때 합리화하여 통과시키지 않는다.
-
----
-
-## 실행 순서
-
-### Step 1 — 초기 셋업
-
-`.crew/` 폴더가 없으면 생성한다.
-
-```bash
-mkdir -p .crew/plans
-```
-
-### Step 2 — 의도 분류
-
-유저 요청을 2가지로 분류한다:
-
-| 유형 | 기준 | PM 관여 | 예시 |
-|------|------|---------|------|
-| **유저 가치** | 유저가 변화를 인지함 | O | 기능 추가, UI 변경, 플로우 수정 |
-| **엔지니어링** | 유저가 변화를 인지하지 못함 | X | 리팩토링, 마이그레이션, 버그 수정, 인프라, 성능, 테스트 |
-
-분류 기준: **"이 작업의 결과를 유저(사용자)가 인지하는가?"**
-
-애매하면 유저에게 물어본다.
-
-### Step 3 — task-id 생성
-
-task-id를 생성한다. 형식: `{간결한-영문-슬러그}` (예: `add-search-filter`, `fix-auth-timeout`)
-
-```bash
-mkdir -p .crew/plans/{task-id}
-```
-
-### Step 4 — crew-plan 실행
-
-crew-plan 파이프라인을 실행한다.
-
-오케스트레이터가 crew-plan에 전달할 정보:
-- task-id
-- 의도 유형 (유저 가치 / 엔지니어링)
-- 유저 요청 원문 (brief.md 작성용)
-
-crew-plan의 반환을 확인한다:
-- **COMPLETE** → contract.md 경로를 확인하고 Step 5로 진행
-- **ESCALATE** → 유저에게 에스컬레이션 내용을 전달하고, 유저 응답에 따라 재시도 또는 보류
-
-### Step 5 — crew-dev 실행
-
-crew-dev 파이프라인을 실행한다.
-
-오케스트레이터가 crew-dev에 전달할 정보:
-- task-id
-
-crew-dev의 반환을 확인한다:
-- **COMPLETE** → PR URL을 유저에게 전달
-- **ESCALATE** → 유저에게 에스컬레이션 내용을 전달하고, 유저 응답에 따라 재시도 또는 보류
-
-### Step 6 — 완료 보고
-
-유저에게 최종 결과를 보고한다:
-- task-id
-- PR URL
-- 주요 변경 사항 요약
-
----
-
-## 에스컬레이션 처리
-
-에스컬레이션은 유저에게 선택지를 제시하고 응답을 기다린다.
-유저 응답에 따라:
-
-- **재시도**: 해당 파이프라인의 실패 지점부터 재실행
-- **수정**: 유저가 직접 파일을 수정한 후 재실행
-- **보류**: 상태를 BLOCKED으로 갱신하고 종료
-
----
-
-## 산출물 파일 구조
-
-```
-.crew/plans/{task-id}/
-  # crew-plan 산출물
-  brief.md          # 오케스트레이터: 유저 원본 요청
-  spec.md           # PM: 수용 기준, 스코프 (유저 가치 유형만)
-  analysis.md       # TechLead: 사전 분석 결과
-  plan.md           # Planner: 구현 계획
-  review.md         # PlanEvaluator: 검증 결과 (최신)
-  plan-{n}.md       # 실패한 계획 아카이브
-  review-{n}.md     # 실패한 리뷰 아카이브
-  contract.md       # 최종 계약 (PASS 시만 생성)
-  .loop_count       # 계획 루프 카운터
-
-  # crew-dev 산출물
-  dev-log.md        # Dev: 구현 진행 로그
-  review-report.md  # CodeReviewer: 코드 리뷰 결과 (최신)
-  qa-report.md      # QA: 실행 검증 결과 (최신)
-  review-report-{n}.md  # FAIL 시 아카이브
-  qa-report-{n}.md      # FAIL 시 아카이브
-  .dev_loop_count       # 개발 루프 카운터
-```
-
----
-
-## contract.md 구조
-
-PlanEvaluator PASS 후 crew-plan이 생성한다.
-
-```markdown
-# 스프린트 계약: {task-id}
-
-생성일: {date}
-유형: {유저 가치 | 엔지니어링}
-
-## 목표
-{한 문장}
-
-## 수용 기준
-- [ ] {testable 기준 1}
-- [ ] {testable 기준 2}
-
-## 가드레일
-### Must
-- {TechLead가 정의한 필수 사항}
-
-### Must NOT
-- {TechLead가 정의한 금지 사항}
-
-## 검증 시나리오
-
-### {시나리오 1 제목}
-- 조건: {사전 상태}
-- 행위: {실행할 것}
-- 기대 결과: {검증할 것}
-
-## 참조 문서
-- 사전 분석: .crew/plans/{task-id}/analysis.md
-- 구현 계획: .crew/plans/{task-id}/plan.md
-
-## 검증 이력
-PlanEvaluator PASS — review.md 참조
-
-## 상태
-ACTIVE
-```
-
----
-
-## 에이전트 라인업
-
-### crew-plan
-| 에이전트 | subagent_type | 모델 | 역할 |
-|----------|--------------|------|------|
-| PM | pm | Opus | 유저 인터뷰, spec.md 작성 (유저 가치만) |
-| TechLead | techlead | Opus | 사전 분석, 아키텍처 방향, 가드레일 |
-| Planner | planner | Opus | 계획 문서 작성 |
-| PlanEvaluator | plan-evaluator | Sonnet | E1-E4 하드 임계값 검증 |
-
-### crew-dev
-| 에이전트 | subagent_type | 모델 | 역할 |
-|----------|--------------|------|------|
-| Dev | dev | Opus | 코드 구현 + 자체 검증 |
-| CodeReviewer | code-reviewer | Opus | 코드 품질 + 가드레일 위반 판정 |
-| QA | qa | Sonnet | 실행 검증 (빌드/테스트/E2E) |
-
-### 공유 서브에이전트
-| 에이전트 | subagent_type | 모델 | 역할 |
-|----------|--------------|------|------|
-| Explorer | explorer | Haiku | 코드베이스 탐색 (병렬, Read-only) |
-| Researcher | researcher | Sonnet | 외부 정보 조사 (필요시만, Read-only) |
-
-**중요**: 모든 에이전트 호출 시 반드시 `subagent_type` 파라미터를 지정해야 한다. HUD에서 에이전트 타입을 식별하는 데 사용된다.