triflux 10.0.0 → 10.0.2

package/skills/tfx-autoroute/SKILL.md.tmpl

@@ -1,188 +0,0 @@
----
-name: tfx-autoroute
-description: "작업 유형에 따라 최적 모델을 자동 선택하여 실행해야 할 때 사용한다. 'sisyphus', '시지프스', 'auto-route', '알아서 라우팅', '최적 모델로' 같은 요청에 사용. 어떤 CLI를 쓸지 모르겠을 때, 또는 실패 시 자동 모델 승격이 필요할 때 적극 활용."
-triggers:
-  - sisyphus
-  - 끝없이
-  - never stop
-  - 시지프스
-  - auto-route
-argument-hint: "<작업 설명>"
----
-
-# tfx-autoroute — Auto-Routing Autonomous Executor
-
-> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
-> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
-
-
-> oh-my-openagent Sisyphus agent 오마주. 바위는 멈추지 않는다 — 그리고 올바른 산을 고른다.
-> "실패하면 더 강한 모델로. 성공할 때까지."
-
-## 용도
-
-- 작업 유형을 모르겠을 때 자동으로 최적 CLI 선택
-- 실패 허용 없이 끝까지 완수해야 할 때
-- Haiku로 충분한 작업에 Opus를 낭비하지 않을 때
-- 비용 최적화 + 완수율 극대화
-
-## 핵심 원리
-
-```
-1. IntentGate로 작업 유형 분류
-2. 유형에 맞는 최적 CLI/모델에 라우팅
-3. 실패 시 자동 승격 (Haiku → Sonnet → Opus, Codex normal → xhigh)
-4. 최종 실패 시에만 사용자에게 보고
-```
-
-## 워크플로우
-
-### Step 0: 라우팅 전략 선택
-
-실행 전에 AskUserQuestion으로 모델 라우팅 전략을 선택받는다:
-
-```
-AskUserQuestion:
-  "기본 라우팅 전략을 선택하세요:"
-  1. 자동 (IntentGate 판단) [기본]
-  2. 성능 우선 (Codex 위주)
-  3. 비용 절약 (Haiku 위주)
-  4. 정확도 우선 (Opus 위주)
-```
-
-- 1번 선택 → Step 1의 IntentGate 분류를 정상 수행
-- 2번 선택 → primary_cli를 Codex(xhigh)로 고정, 실패 시에만 Opus fallback
-- 3번 선택 → primary_cli를 Claude Haiku로 고정, 실패 시 Sonnet → Codex 순 승격
-- 4번 선택 → primary_cli를 Claude Opus로 고정, fallback 없음
-
-사용자가 빈 응답을 보내면 기본값 1번(자동)을 적용한다.
-
-### Step 1: IntentGate 분류
-
-사용자 입력을 분석하여 작업 카테고리와 복잡도를 판단한다:
-
-```
-분류 결과:
-{
-  "category": "visual | deep | quick | code | research | review",
-  "complexity": "trivial | simple | moderate | complex | extreme",
-  "estimated_tokens": N,
-  "routing": {
-    "primary_cli": "gemini | codex | claude",
-    "primary_model": "flash | normal | haiku",
-    "fallback_chain": ["sonnet", "opus"]
-  }
-}
-```
-
-### Step 2: 카테고리 라우팅
-
-| 카테고리 | Primary CLI | Primary 모델 | 이유 |
-|----------|-------------|-------------|------|
-| visual (UI/디자인/멀티모달) | Gemini | flash | 시각적 처리 최적 |
-| deep (아키텍처/설계/분석) | Codex | xhigh | 깊은 추론 필요 |
-| quick (간단한 수정/질문) | Claude | haiku | 최소 비용 |
-| code (구현/디버깅/리팩터링) | Codex | normal | 코드 작성 최적 |
-| research (검색/문서/조사) | Codex | normal | MCP 접근 |
-| review (리뷰/검증/QA) | Codex | thorough | 꼼꼼한 검토 |
-
-### Step 3: 실행
-
-라우팅 결과에 따라 실행한다:
-
-```
-if primary_cli == "codex":
-  Bash("bash ~/.claude/scripts/tfx-route.sh codex '{prompt}' implement")
-
-elif primary_cli == "gemini":
-  Bash("bash ~/.claude/scripts/tfx-route.sh gemini '{prompt}' implement")
-
-elif primary_cli == "claude":
-  if primary_model == "haiku":
-    Agent(model="haiku", prompt="{prompt}")
-  else:
-    Agent(model="sonnet", prompt="{prompt}")
-```
-
-### Step 4: 실패 감지 및 자동 승격
-
-실행 결과를 평가하고, 실패 시 fallback chain을 따라 승격한다:
-
-```
-실패 판단 기준:
-  - exit_code != 0
-  - 출력에 "error", "failed", "unable to" 포함
-  - 출력이 비어 있음
-  - 출력이 프롬프트를 반복하기만 함 (hallucination)
-
-승격 체인:
-  Level 0: primary (최소 비용)
-    ↓ 실패
-  Level 1: 동일 CLI, 모델 한 단계 승격
-    예: haiku → sonnet, codex normal → codex xhigh
-    ↓ 실패
-  Level 2: CLI 전환 + 강한 모델
-    예: gemini → codex xhigh, codex → claude opus
-    ↓ 실패
-  Level 3: Claude Opus 직접 실행 (최후 수단)
-    ↓ 실패
-  Level 4: 사용자에게 보고 + 도움 요청 (AskUserQuestion)
-```
-
-### Step 5: 결과 보고
-
-```markdown
-## Sisyphus 완료
-
-**작업**: {task_description}
-**분류**: {category} / {complexity}
-**라우팅**: {primary_cli} ({primary_model})
-**승격 횟수**: {escalation_count}
-**최종 실행**: {final_cli} ({final_model})
-
-### 실행 경로
-| 시도 | CLI | 모델 | 결과 | 토큰 |
-|------|-----|------|------|------|
-| 1 | Haiku | haiku | 실패 (불완전) | ~1K |
-| 2 | Codex | normal | 성공 | ~3K |
-
-### 결과
-{output}
-
-### 비용 절감
-Primary Opus였다면: ~{opus_cost}K tokens
-실제 사용: ~{actual_cost}K tokens
-절감: {savings}%
-```
-
-## Anti-Stuck 메커니즘
-
-```
-같은 에러로 2회 연속 실패 시:
-  → 에러 메시지를 다음 프롬프트에 포함하여 우회 시도
-
-승격 체인 전체 소진 시 (Level 4):
-  → AskUserQuestion: "다음 작업이 모든 모델에서 실패했습니다.
-     에러: {error}. 접근 방식을 변경하시겠습니까?"
-```
-
-## 토큰 예산
-
-가변. 최소 비용 라우팅이 핵심이므로 고정 예산 없음.
-
-| 시나리오 | 예상 토큰 |
-|----------|----------|
-| 1회 성공 (haiku) | ~2K |
-| 1회 성공 (codex) | ~5K |
-| 1회 승격 후 성공 | ~8K |
-| 2회 승격 후 성공 | ~15K |
-| 전체 체인 소진 | ~25K |
-
-## 사용 예
-
-```
-/tfx-autoroute "이 함수의 타입 에러 수정해"
-/tfx-autoroute "프로젝트 구조 분석해서 아키텍처 다이어그램 만들어"
-/tfx-autoroute "README.md 한국어로 번역"
-/시지프스 "테스트 커버리지 80%까지 올려"
-```

package/skills/tfx-autoroute/skill.json

@@ -1,12 +0,0 @@
-{
-  "name": "tfx-autoroute",
-  "description": "작업 유형에 따라 최적 모델을 자동 선택하여 실행해야 할 때 사용한다. 'sisyphus', '시지프스', 'auto-route', '알아서 라우팅', '최적 모델로' 같은 요청에 사용. 어떤 CLI를 쓸지 모르겠을 때, 또는 실패 시 자동 모델 승격이 필요할 때 적극 활용.",
-  "triggers": [
-    "sisyphus",
-    "끝없이",
-    "never stop",
-    "시지프스",
-    "auto-route"
-  ],
-  "argument_hint": "<작업 설명>"
-}

package/skills/tfx-codex/skill.json

@@ -1,8 +0,0 @@
-{
-  "name": "tfx-codex",
-  "description": "Codex-Only 오케스트레이터. tfx-auto 워크플로우를 Codex 전용으로 고정합니다. '코덱스로 해줘', '코덱스한테 시켜', 'codex로', 'Codex 전용' 같은 요청에 반드시 사용.",
-  "triggers": [
-    "tfx-codex"
-  ],
-  "argument_hint": "\\\"작업 설명\\\" | N:codex \\\"작업 설명\\\""
-}

package/skills/tfx-codex-swarm/SKILL.md.tmpl

@@ -1,16 +0,0 @@
----
-name: tfx-codex-swarm
-deprecated: true
-superseded-by: tfx-swarm
-description: "DEPRECATED — tfx-swarm으로 통합됨. 'codex swarm', '코덱스 스웜' 요청은 tfx-swarm이 처리."
-triggers:
-  - codex-swarm
-  - 코덱스 스웜
----
-
-# tfx-codex-swarm — DEPRECATED
-
-> **DEPRECATED:** 이 스킬은 `tfx-swarm`으로 통합되었습니다. `/tfx-swarm`을 사용하세요.
-> swarm-planner + swarm-hypervisor 파이프라인이 worktree/psmux/codex/원격 실행을 통합 관리합니다.
-
-이 스킬이 호출되면 자동으로 `/tfx-swarm`을 호출합니다.

package/skills/tfx-codex-swarm/skill.json

@@ -1,5 +0,0 @@
-{
-  "name": "tfx-codex-swarm",
-  "description": "OMX 스킬을 활용하는 Codex 다중 세션 스폰 오케스트레이터. PRD/태스크 파일을 스캔하여 각각 독립 git worktree + psmux 세션���로 Codex를 full-auto 실행한다. 'codex swarm', 'codex 다중', '코덱스 스웜', '코덱스 다중 실행', 'PRD 일괄 실행', 'codex spawn', '코덱스 스폰', '다중 코덱스', 'swarm codex', 'omx swarm', '새 창에서 진행', '새 창에서 prd', 'prd 부터', 'prd 실행', 'prd 돌려', '병렬로 돌려', 'worktree로 실행' 같은 요청에 반드시 사용. PRD가 여러 개이거나 병렬 Codex 실행이 필요한 모든 상황에 적극 활용.",
-  "triggers": []
-}

package/skills/tfx-consensus/SKILL.md.tmpl

@@ -1,145 +0,0 @@
----
-name: tfx-consensus
-description: >
-  3자 합의 엔진 — 모든 Deep 스킬의 핵심 인프라. Claude/Codex/Gemini 독립 분석 결과를 교차검증하여 편향 없는 합의를 도출한다.
-  독립 실행도 가능: '합의로 분석해', '3자 합의', 'consensus' 같은 요청 시 직접 호출 가능.
-triggers: [consensus, 합의]
-argument-hint: "<분석 주제 또는 컨텍스트> (Deep 스킬 내부 자동 호출 또는 직접 사용 가능)"
----
-
-# tfx-consensus — Tri-CLI Consensus Engine
-
-> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
-> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
-
-
-> **인프라**: 다른 스킬이 내부적으로 사용. 직접 호출할 필요 없음.
-> 모든 Deep 스킬의 공통 기반. 3개 CLI의 독립 결과를 교차검증하여 합의 도출.
-
-## HARD RULES
-
-> headless-guard가 이 규칙 위반을 **자동 차단**한다. 우회 불가.
-
-1. **`codex exec` / `gemini -p` 직접 호출 절대 금지**
-2. Codex·Gemini → `Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'cli:프롬프트:역할' --timeout 600")` **만** 사용
-3. Claude → `Agent(run_in_background=true)`
-4. Bash + Agent를 같은 메시지에서 동시 호출하여 병렬 실행
-
-이 스킬은 직접 호출하지 않는다. `tfx-deep-*` 스킬이 내부적으로 사용한다.
-
-## MODEL ROLES
-
-| Model | Profile | 역할 | 강점 |
-|-------|---------|------|------|
-| Claude Opus | architect | 합의 통합 및 교차검증 조율 | 논리 분석, 불일치 해소 |
-| Codex | analyst | 구현/보안 관점 독립 분석 | 코드 품질, 취약점 탐지 |
-| Gemini | analyst | UX/문서화 관점 독립 분석 | DX, 접근성, 가독성 |
-
-## EXECUTION STEPS
-
-### Step 1: 독립 분석 dispatch (Anti-Herding)
-
-3개 CLI가 **동시에, 상호 결과를 보지 않고** 독립 분석한다. 한 CLI의 결과가 다른 CLI에 영향을 주면 편향이 발생한다.
-
-**아래 2개 도구를 반드시 같은 응답에서 동시에 호출하라.**
-
-**도구 1 — Claude (Opus/Sonnet) 독립 분석:**
-```
-Agent(
-  subagent_type="oh-my-claudecode:architect",
-  model="opus",
-  run_in_background=true,
-  name="consensus-claude",
-  description="독립 분석 — Claude 관점",
-  prompt="{analysis_prompt} 출력 형식을 JSON으로 강제: { findings: [{ id: 'F1', category: '...', severity: 'critical|high|medium|low', description: '...', evidence: '...' }], summary: '...', confidence: 0.0-1.0 }"
-)
-```
-
-**도구 2 — Codex+Gemini 독립 분석 headless dispatch:**
-```
-Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'codex:{analysis_prompt} 출력 형식을 JSON으로 강제: { findings: [{ id: string, category: string, severity: critical|high|medium|low, description: string, evidence: string }], summary: string, confidence: 0.0-1.0 }:analyst' --assign 'gemini:{analysis_prompt} 출력 형식을 JSON으로 강제: { findings: [{ id: string, category: string, severity: critical|high|medium|low, description: string, evidence: string }], summary: string, confidence: 0.0-1.0 }:analyst' --timeout 600")
-```
-
-### Step 2: 교차검증 (Cross-Validation)
-
-3개 결과(`result_claude`, `result_codex`, `result_gemini`)를 수집한 후 Claude가 통합 교차검증을 수행한다.
-
-합의 분류 알고리즘:
-- 각 finding에 대해 동의한 CLI 수를 집계
-- `agreement_count >= 2` → **CONSENSUS** (합의됨)
-- `agreement_count == 1` → **DISPUTED** (미합의 — 추가 검증 필요)
-- `consensus_score = len(CONSENSUS) / len(ALL_UNIQUE) * 100`
-
-`consensus_score >= 70`이면 Step 4로 직행. 미만이면 Step 3 진행.
-
-### Step 3: Resolution (consensus_score < 70일 때만)
-
-미합의 항목에 대해 2차 라운드를 진행한다.
-
-**아래 2개 도구를 반드시 같은 응답에서 동시에 호출하라.**
-
-**도구 1 — Claude 재검토:**
-```
-Agent(
-  subagent_type="oh-my-claudecode:architect",
-  model="opus",
-  run_in_background=true,
-  name="consensus-resolve-claude",
-  description="미합의 항목 2차 검토",
-  prompt="미합의 항목 목록: {disputed_items}. 다른 두 CLI의 반대 논거: Codex — {codex_rebuttal}, Gemini — {gemini_rebuttal}. 각 항목에 대해 수용(accept) 또는 반박(rebut)으로 응답하라. 수용 시 근거 필수."
-)
-```
-
-**도구 2 — Codex+Gemini 재검토:**
-```
-Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'codex:미합의 항목 목록: {disputed_items}. 다른 두 CLI의 반대 논거: Claude — {claude_rebuttal}, Gemini — {gemini_rebuttal}. 각 항목에 대해 수용(accept) 또는 반박(rebut)으로 응답하라. 수용 시 근거 필수.:analyst' --assign 'gemini:미합의 항목 목록: {disputed_items}. 다른 두 CLI의 반대 논거: Claude — {claude_rebuttal}, Codex — {codex_rebuttal}. 각 항목에 대해 수용(accept) 또는 반박(rebut)으로 응답하라. 수용 시 근거 필수.:analyst' --timeout 600")
-```
-
-Resolution 결과 처리:
-- 수용 2개 이상 → CONSENSUS로 승격
-- 여전히 미합의 → 사용자에게 판단 요청 (AskUserQuestion)
-
-### Step 4: 최종 합의 결과 반환
-
-Learned Weights를 `.omc/state/consensus-weights.json`에서 읽어 가중 투표에 적용한다:
-
-```json
-{
-  "claude": { "accuracy": 0.85, "total": 100, "correct": 85 },
-  "codex":  { "accuracy": 0.82, "total": 100, "correct": 82 },
-  "gemini": { "accuracy": 0.78, "total": 100, "correct": 78 }
-}
-```
-
-가중 투표:
-`weighted_score = (claude_vote * 0.85 + codex_vote * 0.82 + gemini_vote * 0.78) / (0.85 + 0.82 + 0.78)`
-
-최종 결과를 호출 스킬에 반환한다:
-
-```json
-{
-  "consensus_score": 85,
-  "consensus_items": [...],
-  "disputed_items": [...],
-  "resolved_items": [...],
-  "user_decision_needed": [...],
-  "cli_weights": { "claude": 0.85, "codex": 0.82, "gemini": 0.78 }
-}
-```
-
-## ERROR RECOVERY
-
-| 상황 | 대응 |
-|------|------|
-| headless timeout (600s) | Claude Agent로 해당 역할 대체 실행 |
-| Codex 워커 실패 | Agent(oh-my-claudecode:architect, model="opus") 대체 |
-| Gemini 워커 실패 | Agent(oh-my-claudecode:critic, model="sonnet") 대체 |
-
-## 토큰 예산
-
-| Phase | 토큰 |
-|-------|------|
-| Phase 1 (3x 독립분석) | ~15K (각 5K) |
-| Phase 2 (교차검증) | ~3K |
-| Phase 3 (Resolution, 필요 시) | ~8K |
-| **총합** | **18-26K** |

package/skills/tfx-consensus/skill.json

@@ -1,8 +0,0 @@
-{
-  "name": "tfx-consensus",
-  "description": "3자 합의 엔진 — 모든 Deep 스킬의 핵심 인프라. Claude/Codex/Gemini 독립 분석 결과를 교차검증하여 편향 없는 합의를 도출한다. 독립 실행도 가능: '합의로 분석해', '3자 합의', 'consensus' 같은 요청 시 직접 호출 가능.",
-  "triggers": [
-    "[consensus, 합의]"
-  ],
-  "argument_hint": "<분석 주제 또는 컨텍스트> (Deep 스킬 내부 자동 호출 또는 직접 사용 가능)"
-}

package/skills/tfx-debate/SKILL.md.tmpl

@@ -1,191 +0,0 @@
----
-name: tfx-debate
-description: "기술 선택, 아키텍처 비교, 설계 결정에서 3-CLI 구조화 토론으로 최적 답을 도출한다. 'A vs B', '뭐가 나을까', '비교해줘', '어떤 걸 쓸까', '장단점', 'tradeoff' 같은 비교/선택 요청에 반드시 사용한다. 단순 질문이 아닌 여러 옵션 사이의 결정이 필요할 때 적극 활용."
-triggers:
-  - debate
-  - 토론
-  - 3자 토론
-  - tri-debate
-  - 멀티모델 토론
-argument-hint: "<토론 주제 또는 질문>"
----
-
-# tfx-debate — Tri-CLI Structured Debate
-
-> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
-> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
-
-
-> 3개 CLI가 독립 분석 → 교차검증 → 합의 도출. Anti-herding으로 편향 없는 결론.
-
-## 용도
-
-- 설계 결정에서 최적 방향을 찾을 때
-- 코드 아키텍처 선택지 비교
-- 기술 선택 (프레임워크, 라이브러리, 접근법)
-- 요구사항 해석이 모호할 때
-- 어떤 주제든 다관점 분석이 필요할 때
-
-## HARD RULES
-
-> headless-guard가 이 규칙 위반을 **자동 차단**한다. 우회 불가.
-
-1. **`codex exec` / `gemini -p` 직접 호출 절대 금지**
-2. Codex·Gemini → `Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'cli:프롬프트:역할' --timeout 600")` **만** 사용
-3. Claude → `Agent(run_in_background=true)`
-4. Bash + Agent를 같은 메시지에서 동시 호출하여 병렬 실행
-
-## MODEL ROLES
-
-| CLI | 역할 |
-|-----|------|
-| Claude | 소프트웨어 아키텍트 — 시스템 설계 관점 |
-| Codex | 시니어 백엔드 엔지니어 — 구현/기술적 트레이드오프 관점 |
-| Gemini | DevOps/인프라 엔지니어 + DX 전문가 — 운영/개발자경험 관점 |
-
-## EXECUTION STEPS
-
-### Step 1: 주제 파싱 및 명확화
-
-사용자 입력에서 토론 주제를 추출하라. 주제가 모호하거나 비교 대상이 불명확하면 AskUserQuestion으로 명확화하라:
-
-```
-AskUserQuestion:
-  "토론 주제를 더 구체적으로 선택해주세요:"
-  1. {옵션A} vs {옵션B} 기술 비교
-  2. {주제} 아키텍처 접근법 비교
-  3. 직접 입력
-```
-
-주제가 명확한 경우 (예: "REST vs GraphQL") 이 단계를 건너뛰어라.
-
-파싱 결과를 내부적으로 보유하라:
-- topic: 토론 주제
-- context: 프로젝트 컨텍스트 (자동 추출)
-- options: 비교 대상 목록
-- criteria: 평가 기준 목록
-
-### Step 2: 독립 분석 (Anti-Herding)
-
-**아래 2개 도구를 반드시 같은 응답에서 동시에 호출하라.**
-
-Claude Agent를 백그라운드로 실행하라:
-
-```
-Agent(
-  subagent_type="claude",
-  model="opus",
-  run_in_background=true,
-  prompt="당신은 소프트웨어 아키텍트입니다. {topic}에 대해 분석하세요.
-  프로젝트 컨텍스트: {context}
-  각 옵션의 장점, 단점, 리스크를 구조화하세요.
-  최종 추천과 근거를 제시하세요.
-  JSON 형식으로 출력하세요: { recommendation, reasoning, pros, cons, risks, confidence }"
-)
-```
-
-Codex와 Gemini를 headless dispatch로 동시에 실행하라:
-
-```
-Bash("tfx multi --teammate-mode headless --auto-attach --dashboard \
-  --assign 'codex:당신은 시니어 백엔드 엔지니어입니다. {topic}에 대해 구현 관점에서 분석하세요. 프로젝트 컨텍스트: {context}. 각 옵션의 기술적 트레이드오프를 평가하고 구현 난이도, 성능, 확장성을 중심으로 분석하세요. JSON 형식으로 출력하세요: { recommendation, reasoning, pros, cons, risks, confidence }:analyst' \
-  --assign 'gemini:당신은 DevOps/인프라 엔지니어이자 DX 전문가입니다. {topic}에 대해 운영+개발자경험 관점에서 분석하세요. 프로젝트 컨텍스트: {context}. 배포 복잡도, 모니터링, 온보딩 난이도, 개발자 생산성을 중심으로 분석하세요. JSON 형식으로 출력하세요: { recommendation, reasoning, pros, cons, risks, confidence }:analyst' \
-  --timeout 600")
-```
-
-### Step 3: 결과 수집 및 교차검증
-
-3개 결과가 모두 수집되면 다음 기준으로 교차검증하라:
-
-합의 수준을 판정하라:
-- 3/3 동일 추천 → "만장일치" (Strong Consensus) → Step 5로 바로 진행
-- 2/3 동일 추천 → "다수 합의" (Majority Consensus) → Step 5로 진행
-- 3개 모두 다름 → "불일치" (Disputed) → Step 4 토론 라운드 실행
-
-항목별 교차검증을 수행하라:
-- 2개 이상 CLI가 동일 장점/단점 지적 → 확정
-- 1개 CLI만 지적 → "미검증" 표시
-
-### Step 4: 토론 라운드 (불일치 시에만 실행)
-
-불일치 항목이 있으면 각 CLI에게 다음 프롬프트로 2차 라운드를 실행하라.
-
-**아래 2개 도구를 반드시 같은 응답에서 동시에 호출하라.**
-
-Claude Agent를 백그라운드로 실행하라:
-
-```
-Agent(
-  subagent_type="claude",
-  model="opus",
-  run_in_background=true,
-  prompt="다음은 다른 두 분석가의 결론입니다.
-  분석가 A (백엔드 엔지니어): {codex_recommendation} — 근거: {codex_reasoning}
-  분석가 B (DevOps/DX): {gemini_recommendation} — 근거: {gemini_reasoning}
-
-  당신의 원래 입장: {claude_recommendation}
-
-  다른 분석가의 논거를 검토한 후:
-  1. 수용할 점이 있으면 입장을 수정하세요
-  2. 반박할 점이 있으면 근거를 제시하세요
-  3. 최종 추천을 JSON으로 다시 제출하세요: { recommendation, reasoning, confidence, changed }"
-)
-```
-
-Codex와 Gemini 2차 라운드를 headless dispatch로 동시에 실행하라:
-
-```
-Bash("tfx multi --teammate-mode headless --auto-attach --dashboard \
-  --assign 'codex:다음은 다른 두 분석가의 결론입니다. 분석가 A (아키텍트): {claude_recommendation} — 근거: {claude_reasoning}. 분석가 B (DevOps/DX): {gemini_recommendation} — 근거: {gemini_reasoning}. 당신의 원래 입장: {codex_recommendation}. 다른 분석가의 논거를 검토한 후 수용할 점은 반영하고 반박할 점은 근거를 제시하세요. JSON으로 최종 추천을 제출하세요: { recommendation, reasoning, confidence, changed }:analyst' \
-  --assign 'gemini:다음은 다른 두 분석가의 결론입니다. 분석가 A (아키텍트): {claude_recommendation} — 근거: {claude_reasoning}. 분석가 B (백엔드 엔지니어): {codex_recommendation} — 근거: {codex_reasoning}. 당신의 원래 입장: {gemini_recommendation}. 다른 분석가의 논거를 검토한 후 수용할 점은 반영하고 반박할 점은 근거를 제시하세요. JSON으로 최종 추천을 제출하세요: { recommendation, reasoning, confidence, changed }:analyst' \
-  --timeout 600")
-```
-
-### Step 5: 최종 종합
-
-Claude Opus가 전체 토론을 종합하여 다음 구조로 최종 보고서를 작성하라:
-
-```markdown
-## 토론 결과: {topic}
-
-### 합의 사항 (Consensus Score: {score}%)
-- [항목 1] — 3/3 합의
-- [항목 2] — 2/3 합의 (반대: {dissenter} — 근거: {reason})
-
-### 최종 추천
-{recommendation}
-
-### 근거 (3자 종합)
-{synthesized_reasoning}
-
-### 리스크 및 완화 방안
-{risks_and_mitigations}
-
-### 불일치 (해소되지 않은 항목)
-{unresolved_disputes — if any}
-```
-
-## ERROR RECOVERY
-
-- Codex 또는 Gemini 결과가 없으면: 2개 소스로 교차검증을 진행하고 보고서에 누락 CLI를 명시하라
-- tfx multi 명령이 실패하면: 오류 메시지를 출력하고 재시도 1회 후 실패를 사용자에게 보고하라
-- Agent 결과가 없으면: Claude 관점 없이 나머지 2개 소스로 진행하라
-- Round 2 후에도 불일치가 지속되면: 해소되지 않은 항목으로 보고서에 명시하고 최종 추천은 다수결로 결정하라
-
-## TOKEN BUDGET
-
-| 단계 | 토큰 |
-|------|------|
-| Step 2 (3x 독립) | ~15K |
-| Step 3 (교차검증) | ~2K |
-| Step 4 (토론, 불일치 시) | ~8K |
-| Step 5 (종합) | ~3K |
-| **총합** | **20-28K** |
-
-## 사용 예
-
-```
-/tfx-debate "우리 서비스에 Redis vs PostgreSQL LISTEN/NOTIFY for real-time events"
-/tfx-debate "모노레포 vs 멀티레포 for our 3-service architecture"
-/tfx-debate "이 함수를 리팩터링할 때 Strategy 패턴 vs 단순 switch-case"
-```

package/skills/tfx-debate/skill.json

@@ -1,12 +0,0 @@
-{
-  "name": "tfx-debate",
-  "description": "기술 선택, 아키텍처 비교, 설계 결정에서 3-CLI 구조화 토론으로 최적 답을 도출한다. 'A vs B', '뭐가 나을까', '비교해줘', '어떤 걸 쓸까', '장단점', 'tradeoff' 같은 비교/선택 요청에 반드시 사용한다. 단순 질문이 아닌 여러 옵션 사이의 결정이 필요할 때 적극 활용.",
-  "triggers": [
-    "debate",
-    "토론",
-    "3자 토론",
-    "tri-debate",
-    "멀티모델 토론"
-  ],
-  "argument_hint": "<토론 주제 또는 질문>"
-}