peach-team-analyze

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Peach Think Team

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

这是一款通用协调器Skill，可接收任意主题，自动设计团队并完成调研→分析→可行性审核→结果输出全流程。

0. 환경 체크

0. 环境检查

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

0-1. 确认Agent团队功能已启用

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

bash

cat ~/.claude/settings.json | grep -i "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS"

若未显示
```
"1"
```
则立即终止并提示：

⚠️  Agent团队功能未启用。

请在~/.claude/settings.json中添加以下内容后重启Claude Code：

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

参考文档: docs/06-에이전트팀-설정.md

0-2. tmux 환경 감지

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으로 팀원 전환)

bash

echo "${TMUX:-not_in_tmux}"

若显示
```
not_in_tmux
```
则→输出提示后继续执行（无tmux时将以进程内模式运行）：

💡 当前非tmux环境。
   若要实时同时查看团队成员状态，请在tmux会话中执行：

   tmux new-session -s think && claude

   当前将以进程内模式运行。（按Shift+Down切换团队成员）

0-3. Codex 플러그인 감지

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 추가)

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）

Inputs

输入格式

bash

/peach-team-analyze [주제]

bash

/peach-team-analyze [主题]

옵션

可选参数

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

model=sonnet|opus|haiku (覆盖团队成员模型，默认值: sonnet)


**model 옵션:**
- 미지정: 기본값 sonnet으로 모든 팀원 실행
- 지정 시: 모든 팀원(analyst, critic)을 해당 모델로 override
- 팀원 투입(§5) 시 각 Agent 호출의 model 파라미터로 전달

---


**model参数说明:**
- 未指定：默认使用sonnet模型运行所有团队成员
- 指定后：所有成员(analyst, critic)将使用该模型
- 成员部署(§5)时，将作为每个Agent调用的model参数传递

---

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

1. 复杂度判断 — 团队协作 vs 独立处理

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

接收主题后，在组建团队前先判断复杂度，以避免过度设计。

복잡도 점수표

复杂度评分表

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

项目	条件	分数
视角多样性	是否需要2个以上独立视角	+1
并行拆分	是否存在2个以上可同时处理的独立领域	+1
交叉验证	结论是否需要反驳/可行性审核	+1

판단 기준

判断标准

점수	처리 방식
0점	단독 처리 — 팀 없이 바로 답변
1점	경계 — 사용자에게 확인 후 결정
2~3점	팀 구성 → 에이전트 팀 실행

0점 예시 (단독 처리):

"React Query v5 마이그레이션 방법 알려줘"
"이 코드 버그 원인 찾아줘"
"A vs B 간단 비교"

2~3점 예시 (팀 필요):

"우리 서비스 인증 아키텍처 어떻게 바꿔야 해?" (보안/성능/유지보수 3관점)
"이 기능 개발 전략 잡아줘" (조사+설계+리스크 분리)
"경쟁사 3곳 분석해줘" (병렬 조사 후 종합)

1점일 때 사용자 확인 예시:

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

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

分数	处理方式
0分	独立处理 — 无需团队直接回答
1分	边界情况 — 询问用户后决定
2~3分	组建团队 → 执行Agent团队协作

0分示例（独立处理）:

"请告诉我React Query v5迁移方法"
"帮我找出这段代码的bug原因"
"简单比较A和B"

2~3分示例（需要团队协作）:

"我们的服务认证架构应该如何调整？"（涉及安全/性能/维护3个视角）
"帮我制定这个功能的开发策略"（调研+设计+风险拆分）
"帮我分析3家竞争对手"（并行调研后汇总）

1分时用户确认示例:

该主题可独立处理。
团队协作会提供更多视角，但耗时更长。

[1] 团队协作  [2] 直接独立回答

2. 팀 유형 자율 결정

2. 自主决定团队类型

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

若分数为2~3分，则根据主题性质自主决定团队类型。

팀 유형

团队类型

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

类型	适用场景	组成
调研团队	信息收集·对比·现状分析	PM + N名分析师(按视角划分) + critic
执行团队	设计·规划·产出物生成	PM + N名开发者(按领域划分) + critic
验证团队	质量·可行性·风险审核	PM + reviewer + tester + critic
混合团队	复杂复合任务	PM + 调研+执行+验证混合成员 + critic

critic 역할 (항상 포함)

critic角色（必含）

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

独立审核者，尝试对团队成员的结论提出反驳
根据主题复杂度决定critic的介入时机:
- 简单(2分): 仅在最后阶段介入一次
- 复杂(3分): 中期 + 后期两次介入

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

3. 提交团队组建方案 → 用户确认

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

📋 팀 구성안

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

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

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

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

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

Codex 적용 자동 판단 기준 (사용자가 오버라이드 가능):

코드 분석/실행이 필요한 경우 → 자동 적용
문서 분석/설계 판단만으로 충분한 경우 → 자동 스킵
사용자가 명시적으로 [적용/스킵]을 지정하면 → 해당 선택 우선

사용자가 수정 요청하면 구성안 수정 후 재확인. 5초 내 응답 없거나 Y이면 → 바로 실행.

组建团队前必须先展示方案，避免因不合理的团队配置浪费资源。

📋 团队组建方案

主题: [主题一句话总结]
团队类型: [调研/执行/验证/混合]

团队成员:
├─ PM(负责人): 综合判断及结果输出
├─ [角色1]: [负责视角/领域]
├─ [角色2]: [负责视角/领域]
├─ [角色3]: [负责视角/领域]（复杂度高时添加）
└─ critic: 结论可行性反驳审核

🔍 Codex交叉验证
├─ 是否应用: [应用 / 跳过]
├─ 原因: [需要代码分析 / 仅文档分析即可 / 其他]
├─ 验证重点: [明确需要Codex确认的内容]
└─ 工作目录: [绝对路径]

预期产出物: [结果形式]

是否按此方案执行？是否需要调整交叉验证范围？ [Y/n]

Codex自动应用判断标准（用户可覆盖）:

需要代码分析/执行时 → 自动应用
仅需文档分析/设计判断时 → 自动跳过
用户明确指定[应用/跳过]时 → 优先遵循用户选择

若用户提出修改请求，则调整方案后重新确认。 5秒内无响应或输入Y则→立即执行。

4. 팀 생성 및 태스크 등록

4. 创建团队并注册任务

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

TeamCreate: team_name="think-[主题缩写]-team"

조사 팀 예시

调研团队示例

TaskCreate:

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

TaskCreate:

"[视角1] 调研" (负责人: analyst-1)
"[视角2] 调研" (负责人: analyst-2)
"[视角3] 调研" (负责人: analyst-3) ← 根据视角数量动态调整
"综合判断" (依赖: 1,2,3, 负责人: pm)
"可行性审核" (依赖: 4, 负责人: critic)

실행 팀 예시

执行团队示例

TaskCreate:

"[영역1] 작성" (owner: dev-1)
"[영역2] 작성" (owner: dev-2)
"통합 검증" (blockedBy: 1,2, owner: pm)
"타당성 검토" (blockedBy: 3, owner: critic)


태스크 의존성 규칙:
- 병렬 가능한 조사/작업: `blockedBy` 없음
- PM 종합: 모든 팀원 완료 후
- critic: PM 종합 후

---

TaskCreate:

"[领域1] 开发" (负责人: dev-1)
"[领域2] 开发" (负责人: dev-2)
"集成验证" (依赖: 1,2, 负责人: pm)
"可行性审核" (依赖: 3, 负责人: critic)


任务依赖规则:
- 可并行的调研/任务: 无`blockedBy`限制
- PM综合判断: 需所有成员完成后执行
- critic审核: 需PM综合判断完成后执行

---

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

5. 部署团队成员（并行执行）

모든 팀원을 같은 turn에서

run_in_background: true

로 동시 투입한다.

所有成员在同一轮次中以

run_in_background: true

同时部署。

팀원 프롬프트 필수 원칙

成员提示词核心规则

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

角色声明: "你是[角色]，负责Task #N。"
完整背景: 成员无对话历史感知 — 需详细说明主题、目标、上下文
绝对文件路径: 若需参考文件，必须指定绝对路径
完成协议: "完成后更新Task #N状态为completed，并通过SendMessage向PM(team-lead@团队名称)汇报。内容控制在150行以内"
输出限制: 指定汇报内容行数（节省Token）

critic 팀원 프롬프트 핵심

critic成员提示词核心

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

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

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

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

你是独立批判审核者(critic)，负责Task #N。

请针对PM的综合判断结果，从以下视角尝试提出反驳:
1. 是否遗漏了视角或证据？
2. 是否存在逻辑跳跃或过度简化？
3. 是否充分覆盖了风险或副作用？

若反驳合理则 → "需修改: [具体内容]"
若结论严谨则 → "可行性确认: [依据]"

汇报发送给PM，内容控制在100行以内。

6. 보고 수집 및 PM 종합

6. 收集汇报及PM综合判断

PM이 모든 팀원 보고를 수신하면:

선정 기준 먼저 선언 — 결론을 내리기 전에 평가 기준을 명시한다

평가 기준:
- 독립 분해 가능한가? (병렬 처리가 의미 있는가)
- 검증 가능한 산출물이 있는가?
- 역할 분담이 단독 대비 실질적 이점이 있는가?

공통점/합의점 정리
충돌점/이견 명시
critic 반론 반영 여부 결정
최종 결론 도출

PM收到所有成员汇报后:

先声明选择标准 — 得出结论前明确评估标准

评估标准:
- 是否可独立拆分？（并行处理是否有意义）
- 是否有可验证的产出物？
- 角色分工相比独立处理是否有实际优势？

整理共识点
明确冲突点/分歧
决定是否采纳critic的反驳意见
得出最终结论

팀원 무응답 대응

成员无响应处理

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

1. 通过SendMessage重新请求汇报 → 等待3分钟
2. 仍无响应则 → 重新部署新成员(v2)
3. 在config.json中强制移除无响应成员后执行TeamDelete

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

7. Codex交叉验证（CODEX_AVAILABLE=true时）

PM 종합 완료 후

codex:codex-rescue

서브에이전트를 스폰하여 교차검증을 실행한다.

/codex:adversarial-review
는
disable-model-invocation
제약으로 오케스트레이터가 자동 호출할 수 없다. 대신
codex:codex-rescue
로 Codex CLI에 교차검증 작업을 task로 전달한다.

PM综合判断完成后，启动

codex:codex-rescue

子Agent执行交叉验证。

/codex:adversarial-review
受
disable-model-invocation
限制，协调器无法自动调用。因此改用
codex:codex-rescue
将交叉验证任务传递给Codex CLI。

프롬프트 작성 규칙 (필수)

提示词编写规则（必守）

codex-rescue는 독립 컨텍스트에서 실행되므로, 판단에 필요한 모든 정보를 프롬프트에 인라인으로 포함해야 한다. 컨텍스트 없이 "약점을 찾아줘"만 보내면 무응답이 된다.

프롬프트 템플릿:

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

codex-rescue在独立上下文环境中运行，因此必须将判断所需的所有信息内联到提示词中。 仅发送"帮我找出弱点"而无上下文会导致无响应。

提示词模板:

Agent(
  subagent_type="codex:codex-rescue",
  run_in_background=true,
  prompt="""
请找出以下分析结论的弱点。
排除critic已审核的内容，仅汇报外部视角下遗漏的点。

PM 종합 결론

PM综合结论

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

[PM综合判断全文内联此处]

critic 검토 결과 (중복 제외 대상)

critic审核结果（排除重复内容）

[critic 보고 본문 전체를 여기에 인라인]

[critic汇报全文内联此处]

질문

问题

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

50줄 이내 보고. """ )


인라인 기준:
- PM 종합: 핵심 발견 + 결론 + 권고 (전문 권장, 200줄 이하로 압축)
- critic 보고: 수정 필요/타당성 확인 판정표 전체
- 관련 파일: 코드 경로만 명시 (codex-rescue가 Bash로 파일 내용을 읽을 수 있음)

该结论是否存在遗漏的风险？
[主题专属问题]

汇报内容控制在50行以内。 """ )


内联标准:
- PM综合内容：核心发现 + 结论 + 建议（推荐全文，压缩至200行以内）
- critic汇报：完整的需修改/可行性确认判定表
- 相关文件：仅指定代码路径（codex-rescue可通过Bash读取文件内容）

critic → Codex 순서 정의

critic → Codex执行顺序定义

critic과 Codex는 역할이 다르다. 중복을 방지하기 위해 순서를 정의한다:

critic (§5에서 실행): 내부 논리 검증 — 빠진 관점, 논리적 비약, 과도한 단순화
Codex (§7에서 실행): critic 보고서를 전달받아 critic이 언급하지 않은 외부 관점 + 반사실적 시나리오만 검토

critic与Codex角色不同。为避免重复，明确执行顺序:

critic（§5中执行）: 内部逻辑验证 — 遗漏视角、逻辑跳跃、过度简化
Codex（§7中执行）: 接收critic汇报后，仅审核critic未提及的外部视角 + 不符合事实的场景

피드백 반영 루프

反馈闭环

Codex 피드백이 결론 수정을 요구하면 → PM 재종합 1회 허용
재종합 후 Codex가 재반론하면 → PM 최종 확정 우선, 루프 종료
Codex 피드백이 경미하면 → 최종 결과에 "반영" 또는 "검토 완료, 이견 없음"으로 명시

若Codex反馈要求修改结论 → 允许PM重新综合一次
重新综合后Codex仍提出反驳 → 优先以PM最终确认为准，终止闭环
若Codex反馈轻微 → 在最终结果中注明"已采纳"或"审核完成，无分歧"

Codex 실행 결과 사용자 확인

Codex执行结果用户确认

Codex 교차검증 결과를 받은 후, PM이 바로 반영하지 않고 사용자에게 먼저 보여준다:

🔍 Codex 교차검증 결과

[Codex 보고 요약 3~5줄]

이 피드백을 결론에 반영할까요?
[1] 반영  [2] 무시  [3] 추가 검증 요청

[1] 반영: PM이 Codex 피드백을 반영하여 재종합
[2] 무시: Codex 피드백을 무시하고 현재 결론 확정
[3] 추가 검증: 사용자가 지정한 항목으로 Codex 재실행

收到Codex交叉验证结果后，PM不直接采纳，先展示给用户:

🔍 Codex交叉验证结果

[Codex汇报摘要3~5行]

是否将此反馈纳入结论？
[1] 采纳  [2] 忽略  [3] 请求进一步验证

[1] 采纳: PM根据Codex反馈重新综合
[2] 忽略: 忽略Codex反馈，确认当前结论
[3] 请求进一步验证: 根据用户指定内容重新执行Codex

작업 디렉토리 고정 (필수)

固定工作目录（必守）

Codex에 전달하는 프롬프트에 반드시 작업 디렉토리를 명시한다. 컨텍스트 이탈(다른 프로젝트 파일 읽기) 방지:

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

必须在传递给Codex的提示词中明确指定工作目录。防止上下文偏离（读取其他项目文件）:

Agent(
  subagent_type="codex:codex-rescue",
  prompt="""
  工作目录: /绝对路径/项目
  请勿读取该目录以外的文件。
  ...
  """
)

fallback

降级方案

CODEX_AVAILABLE=false: critic 팀원 결과로 대체. 별도 안내 없이 진행.
사용자가 §3에서 Codex 스킵 선택: §7 전체 생략, critic 결과로 최종 확정.
Codex 무응답/타임아웃: 60초 대기 → 응답 없으면 스킵, critic 결과로 진행.
Codex 결과 부실: 프롬프트를 보강하여 1회 재시도 → 재시도 후에도 부실하면 critic 결과로 진행.
Codex 컨텍스트 이탈 감지: Codex가 작업 디렉토리 밖 파일을 읽은 경우 → 결과 무효, critic 결과로 대체.

CODEX_AVAILABLE=false: 用critic成员结果替代，无需额外提示继续执行。
用户在§3中选择跳过Codex: 跳过整个§7，以critic结果为最终结论。
Codex无响应/超时: 等待60秒 → 仍无响应则跳过，以critic结果执行。
Codex结果无效: 优化提示词后重试一次 → 仍无效则以critic结果执行。
检测到Codex上下文偏离: 若Codex读取工作目录外文件 → 结果无效，以critic结果替代。

8. 팀 정리

8. 团队清理

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

TeamDelete 실패 시 (active members 오류):

bash

undefined

SendMessage(shutdown_request) → 发送给所有成员
TeamDelete → 清理团队

若TeamDelete失败（active members错误）:

bash

undefined

config.json에서 팀원 강제 제거 후 재시도

在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) "

---

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. 최종 결과 출력

9. 输出最终结果

undefined

undefined

[주제] — 분석 결과

[主题] — 分析结果

팀 구성

团队组成

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

团队类型: [类型]
成员: [角色列表]
Codex交叉验证: [已应用/未应用]

핵심 발견

核心发现

[발견 1]
[발견 2]
[발견 3]

[发现1]
[发现2]
[发现3]

선정 기준

选择标准

독립 분해 가능성: [평가]
산출물 검증 가능성: [평가]
역할 분담 실질 이점: [평가]

可独立拆分性: [评估]
产出物可验证性: [评估]
角色分工实际优势: [评估]

결론

结论

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

[PM综合判断 — 明确直接]

critic 검토

critic审核

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

[可行性确认 / 已采纳修改内容] ※ 若判定为"条件可行"，必须在结论中注明对应条件

Codex 교차검증 (적용 시)

Codex交叉验证（已应用时）

[이견 없음 / 반영된 수정 사항]

[无分歧 / 已采纳修改内容]

다음 액션

后续行动建议

→ [권장 행동 1] → [권장 행동 2]

---

→ [建议行动1] → [建议行动2]

---

참조 문서

参考文档

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

```
docs/07-에이전트팀-실전경험-E2E이식.md
```
— 团队运营实战模式、成员提示词模板
```
docs/06-에이전트팀-설정.md
```
— tmux/settings.json配置指南
```
references/team-patterns.md
```
— 各团队类型详细提示词示例

사용 예시

使用示例

bash

undefined

bash

undefined

어떤 주제든 그냥 전달

直接传递任意主题

/peach-think-team 우리 서비스 인증 아키텍처 JWT vs Session 어떻게 결정해야 해?

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

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

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

undefined

/peach-think-team 我们的服务认证架构应该选JWT还是Session？

/peach-think-team 帮我分析3家竞争对手(토스, 카카오페이, 네이버페이)的支付UX

/peach-think-team 帮我查看这个PR diff，找出设计上的问题

/peach-think-team 帮我从多角度审核明年的技术路线图规划

undefined