SuperAPI AI Directory
Partner中文AI newsFavorites
Skillspeach-team-analyze

peach-team-analyze

General & other

View repository

Updated 10-15 21:40

About this skill

Peach Think Team

For any topic, design a team on its own and a general-purpose orchestrator skill that automatically handles everything from research → analysis → feasibility review → result derivation.

0. Environment check

0-1. Check whether the agent team feature is enabled

cat ~/.claude/settings.json | grep -i "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS"
  • "1" if not, stop immediatelyand guide:
⚠️  에이전트 팀 기능이 비활성화되어 있습니다.

Add the following to ~/.claude/settings.json, then restart Claude Code:

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


### 0-2. tmux 환경 감지

```bash
echo "${TMUX:-not_in_tmux}"
  • not_in_tmuxif so → after outputting the guide, continue (works in in-process mode even without tmux):
💡 tmux 환경이 아닙니다.
   팀원을 실시간으로 동시에 확인하려면 tmux 세션 안에서 실행하세요:

   tmux new-session -s think && claude

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

0-3. Detect the Codex plugin

cat ~/.claude/settings.json | grep -i "openai-codex"
  • "codex@openai-codex": true if present → CODEX_AVAILABLE=true
  • if not → CODEX_AVAILABLE=false (replaced by a critic team member, output the guide)
ℹ️  Codex 플러그인 미감지 — critic 팀원으로 교차 검증을 대체합니다.
   (Codex 활성화: settings.json에 "codex@openai-codex": true 추가)

Inputs

/peach-team-analyze [주제]

# 옵션
# model=sonnet|opus|haiku  (팀원 모델 override, 기본값: sonnet)

model option:

  • unspecified: run all team members with the default sonnet
  • if specified: override all team members (analyst, critic) with that model
  • when deploying team members (§5), pass it as the model parameter of each Agent call

1. Complexity assessment — team vs solo

When a topic is received, before forming a team first assess the complexity. This is to prevent overengineering.

Complexity score table

Item Condition Score
Perspective diversity Are two or more independent perspectives needed +1
Parallel separation Are there two or more independent areas that can be handled simultaneously +1
Cross-validation Is a counterargument/feasibility review meaningful for the conclusion +1

Judgment criteria

Score Handling method
0점 Solo handling — answer directly without a team
1점 Borderline — decide after confirming with the user
2~3점 Team formation → run agent team

0-point examples (solo handling):

  • "Tell me how to migrate to React Query v5"
  • "Find the cause of this code bug"
  • "Simple comparison of A vs B"

2–3 point examples (team needed):

  • "How should we change our service's authentication architecture?" (3 perspectives: security/performance/maintainability)
  • "Set up a development strategy for this feature" (separate research + design + risk)
  • "Analyze 3 competitors" (parallel research then synthesis)

Example of user confirmation when it is 1 point:

이 주제는 단독으로도 처리 가능합니다.
팀으로 진행하면 더 다각적이지만 시간이 걸립니다.

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

2. Autonomous team type determination

If the score is 2–3, autonomously determine the team type according to the nature of the topic.

Team type

Type When Composition
Research team Information gathering, comparison, and status 파악 PM + N analysts (by perspective) + critic
Execution team Design, planning, and artifact generation PM + N developers (by area) + critic
Verification team Quality, validity, and risk review PM + reviewer + tester + critic
Mixed team Complex task PM + mixed research+execution+verification + critic

critic role (always included)

  • Team members' conclusions attempt counterargumentsan independent reviewer who
  • Determine when to bring in the critic based on topic complexity:
    • Simple (2 points): only once at the end
    • Complex (3 points): midway + at the end

3. Present team composition proposal → user confirmation

Before forming the team, must first show the composition proposal. This is to avoid wasting resources on an inappropriate team composition.

📋 팀 구성안

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

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

🔍 Codex 교차검증
├─ 적용 여부: [적용 / 스킵]
├─ 사유: [코드 분석 필요 / 문서 분석만으로 충분 / etc.]
├─ 검증 초점: [구체적으로 Codex에게 무엇을 확인시킬지]
└─ 작업 디렉토리: [절대경로]

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

이 구성으로 진행할까요? 교차검증 범위를 조정하시겠습니까? [Y/n]

Codex application automatic decision criteria (user can override):

  • If code analysis/execution is needed → apply automatically
  • If document analysis/design judgment alone is sufficient → skip automatically
  • If the user explicitly specifies [apply/skip] → that choice takes precedence

If the user requests changes, revise the composition proposal and reconfirm. If there is no response within 5 seconds or the response is Y → execute immediately.

4. Create team and register tasks

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)

Task dependency rules:

  • Parallelizable research/work: blockedBy none
  • PM synthesis: after all team members complete
  • critic: after PM synthesis

5. Assign team members (parallel execution)

Assign all team members in the same turn run_in_background: truesimultaneously.

Essential principles for team member prompts

  1. Role declaration: "You are [role]. You are in charge of Task #N."
  2. Sufficient background: Team members do not know the conversation history at all — provide the topic, purpose, and context in detail
  3. Absolute file paths: If there are files to reference, specify them as absolute paths
  4. Completion protocol: "After completion, TaskUpdate Task #N → completed, report to PM (team-lead@teamname) via SendMessage. Within 150 lines"
  5. Output limit: Specify the number of lines in the report (save tokens)

Key points for critic team member prompts

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

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

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

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

6. Collect reports and PM synthesis

When the PM receives all team member reports:

  1. Declare selection criteria first — state the evaluation criteria before drawing a conclusion 
    평가 기준:
- 독립 분해 가능한가? (병렬 처리가 의미 있는가)
- 검증 가능한 산출물이 있는가?
- 역할 분담이 단독 대비 실질적 이점이 있는가?
  2. Summarize common points/agreements
  3. State conflicts/disagreements
  4. Decide whether to incorporate critic counterarguments
  5. Derive final conclusion

Handling team member non-response

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

7. Codex cross-validation (when CODEX_AVAILABLE=true)

After PM synthesis is complete, codex:codex-rescue spawn a subagent to run cross-validation.

/codex:adversarial-review는 disable-model-invocation Due to constraints, the orchestrator cannot call it automatically. Instead, codex:codex-rescueto pass the cross-validation task to Codex CLI as a task.

Prompt writing rules (required)

Since codex-rescue runs in an independent context, all information needed for judgment must be included inline in the prompt. If you send only "find weaknesses" without context, there will be no response.

Prompt template:

Agent(
  subagent_type="codex:codex-rescue",
  run_in_background=true,
  prompt="""
아래 분석 결론의 약점을 찾아줘.
critic이 이미 검토한 항목은 중복 제외하고, 외부 관점에서 놓친 점만 보고.

## PM 종합 결론
[PM 종합 판단 본문 전체를 여기에 인라인]

## critic 검토 결과 (중복 제외 대상)
[critic 보고 본문 전체를 여기에 인라인]

## 질문
- 이 결론에 놓친 리스크가 있는가?
- [주제 특화 질문]

50줄 이내 보고.
"""
)

Inline criteria:

  • PM synthesis: key findings + conclusion + recommendations (full text recommended, compressed to 200 lines or fewer)
  • critic report: full revision-needed/validity-confirmation decision table
  • Related files: specify only code paths (codex-rescue can read file contents with Bash)

Define critic → Codex order

critic and Codex have different roles. To prevent duplication, orderis defined:

  1. critic (executed in §5): internal logic verification — missing perspectives, logical leaps, excessive simplification
  2. Codex (executed in §7): receives the critic report and external perspectives not mentioned by critic + counterfactual scenariosonly review

Feedback reflection loop

  • If Codex feedback requires revising the conclusion → PM re-synthesis 1회 allowed
  • If Codex rebuts again after re-synthesis → PM final decision takes priority, loop ends
  • If Codex feedback is minor → state in the final result as "reflected" or "review complete, no disagreement"

User confirmation of Codex execution results

After receiving the Codex cross-validation results, the PM does not immediately reflect them but shows them to the user first:

🔍 Codex 교차검증 결과

[Codex 보고 요약 3~5줄]

이 피드백을 결론에 반영할까요?
[1] 반영  [2] 무시  [3] 추가 검증 요청
  • [1] Reflect: PM reflects Codex feedback and re-synthesizes
  • [2] Ignore: ignore Codex feedback and finalize the current conclusion
  • [3] Additional verification: rerun Codex on items specified by the user

Fix working directory (required)

In the prompt passed to Codex, must specify the working directory. Prevent context deviation (reading files from another project):

Agent(
  subagent_type="codex:codex-rescue",
  prompt="""
  작업 디렉토리: /절대경로/프로젝트
  이 디렉토리 밖의 파일은 읽지 마라.
  ...
  """
)

fallback

  • CODEX_AVAILABLE=false: replace with critic team member results. Proceed without separate guidance.
  • User selects Codex skip in §3: omit all of §7, finalize with critic results.
  • Codex no response/timeout: wait 60 seconds → if no response, skip and proceed with critic results.
  • Codex results insufficient: reinforce the prompt and retry once → if still insufficient after retry, proceed with critic results.
  • Codex context deviation detected: if Codex reads files outside the working directory → results invalid, replace with critic results.

8. Team cleanup

SendMessage(shutdown_request) → 모든 팀원에게
TeamDelete → 팀 정리

If TeamDelete fails (active members error):

# 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. Final result output

## [주제] — 분석 결과

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

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

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

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

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

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

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

Reference documents

  • references/team-patterns.md — Detailed prompt examples by team type, practical team operation patterns, tmux pane management reference

Usage example

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

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

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

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