peach-think-team

Original🇺🇸 English
Translated

어떤 주제/과제든 받아서 스스로 팀을 구성하고 조사·분석·검토·결과도출까지 처리하는 범용 에이전트 팀 오케스트레이터. "팀으로 분석해줘", "에이전트 팀으로 조사해줘", "다각도로 검토해줘", "심층 분석 부탁해", "여러 관점으로 봐줘", "think-team", "think team" 키워드로 트리거. 단순 질문이 아닌 복합적 판단, 조사, 전략 결정이 필요한 모든 상황에서 사용.

2installs
Added on

NPX Install

npx skill4agent add peachsolution/peach-harness peach-think-team

Peach Think Team

어떤 주제든 받아서 스스로 팀을 설계하고 조사→분석→타당성 검토→결과 도출까지 자동 처리하는 범용 오케스트레이터 스킬.

0. 환경 체크

0-1. 에이전트 팀 기능 활성화 확인

bash
cat ~/.claude/settings.json | grep -i "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS"
  • "1"
    없으면 즉시 중단하고 안내:
⚠️  에이전트 팀 기능이 비활성화되어 있습니다.

~/.claude/settings.json에 아래 내용을 추가한 후 Claude Code를 재시작하세요:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

참고: docs/06-에이전트팀-설정.md

0-2. tmux 환경 감지

bash
echo "${TMUX:-not_in_tmux}"
  • not_in_tmux
    이면 → 안내 출력 후 계속 진행 (tmux 없어도 in-process 모드로 동작):
💡 tmux 환경이 아닙니다.
   팀원을 실시간으로 동시에 확인하려면 tmux 세션 안에서 실행하세요:

   tmux new-session -s think && claude

   지금은 in-process 모드로 진행합니다. (Shift+Down으로 팀원 전환)

0-3. Codex 플러그인 감지

bash
cat ~/.claude/settings.json | grep -i "openai-codex"
  • "codex@openai-codex": true
    있으면 →
    CODEX_AVAILABLE=true
  • 없으면 →
    CODEX_AVAILABLE=false
    (critic 팀원으로 대체, 안내 출력)
ℹ️  Codex 플러그인 미감지 — critic 팀원으로 교차 검증을 대체합니다.
   (Codex 활성화: settings.json에 "codex@openai-codex": true 추가)

1. 복잡도 판단 — 팀 vs 단독

주제를 받으면 팀을 꾸리기 전에 먼저 복잡도를 판단한다. 오버엔지니어링을 방지하기 위함이다.

복잡도 점수표

항목조건점수
관점 다양성2개 이상의 독립적 관점이 필요한가+1
병렬 분리동시에 처리 가능한 독립 영역이 2개 이상인가+1
교차 검증결론에 반론/타당성 검토가 의미 있는가+1

판단 기준

점수처리 방식
0점단독 처리 — 팀 없이 바로 답변
1점경계 — 사용자에게 확인 후 결정
2~3점팀 구성 → 에이전트 팀 실행
0점 예시 (단독 처리):
  • "React Query v5 마이그레이션 방법 알려줘"
  • "이 코드 버그 원인 찾아줘"
  • "A vs B 간단 비교"
2~3점 예시 (팀 필요):
  • "우리 서비스 인증 아키텍처 어떻게 바꿔야 해?" (보안/성능/유지보수 3관점)
  • "이 기능 개발 전략 잡아줘" (조사+설계+리스크 분리)
  • "경쟁사 3곳 분석해줘" (병렬 조사 후 종합)
1점일 때 사용자 확인 예시:
이 주제는 단독으로도 처리 가능합니다.
팀으로 진행하면 더 다각적이지만 시간이 걸립니다.

[1] 팀으로 진행  [2] 단독으로 바로 답변

2. 팀 유형 자율 결정

점수 2~3점이면 주제 성격에 따라 팀 유형을 자율 결정한다.

팀 유형

유형언제구성
조사 팀정보 수집·비교·현황 파악PM + 분석가 N명(관점별) + critic
실행 팀설계·계획·산출물 생성PM + 개발자 N명(영역별) + critic
검증 팀품질·타당성·리스크 검토PM + reviewer + tester + critic
혼합 팀복합 과제PM + 조사+실행+검증 혼합 + critic

critic 역할 (항상 포함)

  • 팀원 결론에 반론을 시도하는 독립 검토자
  • 주제 복잡도에 따라 critic 투입 시점 결정:
    • 단순(2점): 마지막에 한 번만
    • 복잡(3점): 중간 + 마지막

3. 팀 구성안 제시 → 사용자 확인

팀을 꾸리기 전에 반드시 구성안을 먼저 보여준다. 엉뚱한 팀 구성으로 리소스를 낭비하지 않기 위함이다.
📋 팀 구성안

주제: [주제 한 줄 요약]
팀 유형: [조사/실행/검증/혼합]

팀원:
├─ PM(리더): 종합 판단 및 결과 도출
├─ [역할1]: [담당 관점/영역]
├─ [역할2]: [담당 관점/영역]
├─ [역할3]: [담당 관점/영역] (복잡도 높을 때)
└─ critic: 결론 타당성 반론 검토

예상 산출물: [결과물 형태]

이 구성으로 진행할까요? [Y/n]
사용자가 수정 요청하면 구성안 수정 후 재확인. 5초 내 응답 없거나 Y이면 → 바로 실행.

4. 팀 생성 및 태스크 등록

TeamCreate: team_name="think-[주제-축약]-team"

# 조사 팀 예시
TaskCreate:
1. "[관점1] 조사" (owner: analyst-1)
2. "[관점2] 조사" (owner: analyst-2)
3. "[관점3] 조사" (owner: analyst-3)  ← 관점 수에 따라 가변
4. "종합 판단" (blockedBy: 1,2,3, owner: pm)
5. "타당성 검토" (blockedBy: 4, owner: critic)

# 실행 팀 예시
TaskCreate:
1. "[영역1] 작성" (owner: dev-1)
2. "[영역2] 작성" (owner: dev-2)
3. "통합 검증" (blockedBy: 1,2, owner: pm)
4. "타당성 검토" (blockedBy: 3, owner: critic)
태스크 의존성 규칙:
  • 병렬 가능한 조사/작업:
    blockedBy
    없음
  • PM 종합: 모든 팀원 완료 후
  • critic: PM 종합 후

5. 팀원 투입 (병렬 실행)

모든 팀원을 같은 turn에서
run_in_background: true
로 동시 투입한다.

팀원 프롬프트 필수 원칙

  1. 역할 선언: "너는 [역할]이다. Task #N 담당."
  2. 배경 충분히: 팀원은 대화 이력을 전혀 모름 — 주제, 목적, 맥락을 상세히
  3. 파일 경로 절대경로: 참조할 파일이 있으면 절대경로로 명시
  4. 완료 프로토콜: "완료 후 TaskUpdate Task #N → completed, PM(team-lead@팀이름)에게 SendMessage로 보고. 150줄 이내"
  5. 출력 제한: 보고서 줄 수 명시 (토큰 절약)

critic 팀원 프롬프트 핵심

너는 독립 비판 검토자(critic)이다. Task #N 담당.

PM의 종합 판단 결과를 받아 아래 관점에서 반론을 시도하라:
1. 빠진 관점이나 증거는 없는가?
2. 논리적 비약이나 과도한 단순화는 없는가?
3. 리스크나 부작용이 충분히 다뤄졌는가?

반론이 타당하면 → "수정 필요: [구체적 항목]"
결론이 견고하면 → "타당성 확인: [근거]"

보고는 PM에게 SendMessage. 100줄 이내.

6. 보고 수집 및 PM 종합

PM이 모든 팀원 보고를 수신하면:
  1. 선정 기준 먼저 선언 — 결론을 내리기 전에 평가 기준을 명시한다
    평가 기준:
    - 독립 분해 가능한가? (병렬 처리가 의미 있는가)
    - 검증 가능한 산출물이 있는가?
    - 역할 분담이 단독 대비 실질적 이점이 있는가?
  2. 공통점/합의점 정리
  3. 충돌점/이견 명시
  4. critic 반론 반영 여부 결정
  5. 최종 결론 도출

팀원 무응답 대응

1. SendMessage로 보고 재요청 → 3분 대기
2. 응답 없으면 → 새 팀원(v2)으로 재투입
3. config.json에서 무응답 팀원 강제 제거 후 TeamDelete 진행

7. Codex 교차 검증 (CODEX_AVAILABLE=true 시)

PM 종합 완료 후 자동 실행:
/codex:adversarial-review
Codex(GPT-5.4)가 Claude 팀과 다른 관점에서 결론의 약점을 찾는다. Codex 피드백을 최종 결과에 반영하거나 "검토 완료, 이견 없음"으로 명시한다.
CODEX_AVAILABLE=false 시: critic 팀원 결과로 대체. 별도 안내 없이 진행.

8. 팀 정리

SendMessage(shutdown_request) → 모든 팀원에게
TeamDelete → 팀 정리
TeamDelete 실패 시 (active members 오류):
bash
# config.json에서 팀원 강제 제거 후 재시도
python3 -c "
import json, os
path = os.path.expanduser('~/.claude/teams/[팀이름]/config.json')
with open(path) as f: data = json.load(f)
data['members'] = [m for m in data['members'] if m['name'] == 'team-lead']
with open(path, 'w') as f: json.dump(data, f, indent=2)
"

9. 최종 결과 출력

## [주제] — 분석 결과

### 팀 구성
- 팀 유형: [유형]
- 팀원: [역할 목록]
- Codex 교차검증: [적용/미적용]

### 핵심 발견
1. [발견 1]
2. [발견 2]
3. [발견 3]

### 선정 기준
- 독립 분해 가능성: [평가]
- 산출물 검증 가능성: [평가]
- 역할 분담 실질 이점: [평가]

### 결론
[PM 종합 판단 — 명확하고 직접적으로]

### critic 검토
[타당성 확인 / 수정 반영 내역]
※ "조건부 타당" 판정이 있으면 해당 조건을 결론에 반드시 병기

### Codex 교차검증 (적용 시)
[이견 없음 / 반영된 수정 사항]

### 다음 액션
→ [권장 행동 1]
→ [권장 행동 2]

참조 문서

  • docs/07-에이전트팀-실전경험-E2E이식.md
    — 팀 운영 실전 패턴, 팀원 프롬프트 템플릿
  • docs/06-에이전트팀-설정.md
    — tmux/settings.json 설정 가이드
  • references/team-patterns.md
    — 팀 유형별 상세 프롬프트 예시

사용 예시

bash
# 어떤 주제든 그냥 전달
/peach-think-team 우리 서비스 인증 아키텍처 JWT vs Session 어떻게 결정해야 해?

/peach-think-team 경쟁사 3(토스, 카카오페이, 네이버페이) 결제 UX 분석해줘

/peach-think-team 이 PR diff를 보고 설계 상 문제점 찾아줘

/peach-think-team 내년 기술 로드맵 어떻게 잡으면 좋을지 다각도로 검토해줘