소크라테스식 3인 팀 토론으로 계획·설계·의사결정을 다각도 검증한다. TeamCreate로 사회자(team lead) + advocate(socratic-partner) + skeptic(design-skeptic) 팀을 구성하고, 라운드 기반 교차 반박으로 합의와 쟁점을 도출한다. "$debate", "/debate", "토론해줘", "소크라테스 토론", "죽음의 토론" 등 사용자가 계획이나 설계에 대해 다각도 검증을 원할 때 사용한다. 단순 질문, 코드 구현, 단일 리뷰에는 사용하지 않는다.
사용자의 계획·설계·의사결정을 advocate와 skeptic의 구조화된 토론으로 검증하여 합의사항 테이블 + 수정된 계획 + 품질 기준을 도출한다.
토론을 시작하려면 다음 중 하나가 필수다:
"토론해줘"만 입력된 경우, 반드시 "무엇에 대해 토론할까요? 설계 내용이나 파일 경로를 제공해주세요."로 물어본다.
토론은 다음 3가지 산출물이 모두 완성되어야 성공이다:
3가지가 모두 채워지지 않으면 토론을 완료하지 않는다.
$debate # 토론 대상을 물어봄
$debate <계획/설계 설명> # 해당 내용으로 토론 시작
$debate <파일경로> # 파일 내용을 토론 대상으로 사용
TeamCreate("socratic-debate")
├── team-lead (사회자, 나): 중재 + 소크라테스 반문 + 합의/쟁점 정리
├── advocate (socratic-partner): 강점 논증 + 약점 인정 + 개선 방향
└── skeptic (design-skeptic): 약점 지적 + 실패 시나리오 + 대안 제시
Agent({
name: "advocate",
subagent_type: "socratic-partner",
team_name: "socratic-debate",
prompt: <Round 1 초기 프롬프트 — 아래 참조>
})
Agent({
name: "skeptic",
subagent_type: "design-skeptic",
team_name: "socratic-debate",
prompt: <Round 1 초기 프롬프트 — 아래 참조>
})
advocate와 skeptic을 동시(병렬) 스폰한다.
Advocate 초기 프롬프트:
당신은 소크라테스식 토론의 advocate 역할이다.
아래 [토론 대상]에 대해 가장 강력한 3가지 강점을 논증해라.
맹목적 옹호가 아니라 약점도 인정하되, 각 강점에 대해 개선 방향을 함께 제시해라.
발언 구조 (필수):
- Claim: 주장
- Evidence: 근거 (코드, 도메인 지식, 구체적 사례)
- Hidden Assumption: 이 주장이 성립하려면 참이어야 하는 전제
- Failure Possibility: 이 주장이 무너지는 조건
200-250단어 이내로 작성한다. 한국어로 소통한다.
반드시 사회자(team lead)에게만 SendMessage로 응답한다.
---
[토론 대상]
{subject}
Skeptic 초기 프롬프트:
당신은 소크라테스식 토론의 skeptic 역할이다.
아래 [토론 대상]에 대해 가장 위험한 3가지 약점 또는 빠진 부분을 지적해라.
파괴가 목적이 아니라 강화가 목적이다. 각 약점에 대해 반드시 구체적 대안을 제시해라.
발언 구조 (필수):
- Attack: 가장 강한 주장부터 공격
- Failure Scenarios: 2-3개 구체적 실패 시나리오 (트리거 조건 명시)
- Rollback Difficulty: trivial / moderate / hard / catastrophic
- Counterexample: 이 설계가 잘못된 결과를 내는 현실적 상황
200-250단어 이내로 작성한다. 한국어로 소통한다.
반드시 사회자(team lead)에게만 SendMessage로 응답한다.
---
[토론 대상]
{subject}
사회자 행동: 양쪽 수신 후 → 충돌 지점 테이블 정리 → 사용자에게 표시
충돌 지점 테이블 형식:
| # | 쟁점 | Advocate 입장 | Skeptic 입장 | 충돌 유형 |
|---|------|--------------|-------------|----------|
| 1 | ... | ... | ... | 전제 충돌 / 우선순위 차이 / 해법 상이 |
각 에이전트에게 상대의 핵심 논점을 전달하면서 소크라테스식 질문 1개를 추가한다.
Advocate에게 보내는 메시지:
skeptic이 다음과 같이 반박했다:
{skeptic 핵심 논점 요약}
소크라테스 질문: {반문}
위 반박에 대해 교차 반박해라. 동의하는 부분은 인정하고,
반박할 부분은 Claim → Evidence → Hidden Assumption → Failure Possibility 구조로 응답해라.
200-250단어 이내. 사회자에게만 SendMessage로 응답한다.
Skeptic에게 보내는 메시지: (동일 구조, advocate 논점 전달)
소크라테스 질문 생성 가이드: See references/socratic-questions.md
사회자 행동: 양쪽 수신 후 → 합의점과 남은 쟁점을 분리 정리 → 사용자에게 표시
### 합의점
- ...
### 남은 쟁점
| # | 쟁점 | 핵심 분기점 |
|---|------|------------|
| 1 | ... | ... |
남은 쟁점에 대해 각자에게 구체적 해법을 요구한다.
다음 쟁점에 대해 구체적 해법을 제시해라.
"~하면 된다" 수준의 추상적 답변은 금지. 구현 수준의 구체성을 요구한다.
남은 쟁점:
{remaining_issues}
200-250단어 이내. 사회자에게만 SendMessage로 응답한다.
사회자 행동: 최종 합의사항 + 원래 계획 대비 변경사항 정리 → 사용자에게 표시
Round 3에서 합의 안 된 쟁점이 있으면 Round 4를 진행한다.
토론 종료 후 다음 3가지를 정리하여 사용자에게 제공한다.
| # | 항목 | 결정 | 근거 |
|---|------|------|------|
| 1 | ... | 유지 / 변경 / 추가 / 삭제 | advocate·skeptic 공통 근거 |
원래 계획 대비 변경된 부분을 구체적으로 명시한다.
#### 변경사항
- **[항목]**: (기존) ... → (변경) ...
#### 유지사항
- **[항목]**: 유지 이유
토론에서 도출된, 이 설계가 만족해야 하는 검증 기준.
| # | 기준 | 검증 방법 | 출처 라운드 |
|---|------|----------|-----------|
| 1 | ... | ... | Round N |
아웃풋 정리 후 advocate, skeptic에게 shutdown_request를 보낸다:
SendMessage({ to: "advocate", message: { type: "shutdown_request" } })
SendMessage({ to: "skeptic", message: { type: "shutdown_request" } })