triflux 8.3.0 → 8.4.0

package/skills/tfx-autoroute/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: tfx-autoroute
+description: "작업 유형에 따라 최적 모델을 자동 선택하여 실행해야 할 때 사용한다. 'sisyphus', '시지프스', 'auto-route', '알아서 라우팅', '최적 모델로' 같은 요청에 사용. 어떤 CLI를 쓸지 모르겠을 때, 또는 실패 시 자동 모델 승격이 필요할 때 적극 활용."
+triggers:
+  - sisyphus
+  - 끝없이
+  - never stop
+  - 시지프스
+  - auto-route
+argument-hint: "<작업 설명>"
+---
+
+# tfx-autoroute — Auto-Routing Autonomous Executor
+
+> 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("codex exec --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check '{prompt}'")
+
+elif primary_cli == "gemini":
+  Bash("gemini -y -p '{prompt}'")
+
+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-consensus/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: tfx-consensus
+description: 3자 합의 엔진 — 모든 Deep 스킬의 핵심 인프라. Claude/Codex/Gemini 독립 분석 결과를 교차검증하여 편향 없는 합의를 도출한다.
+triggers: []
+argument-hint: "(내부 전용 — Deep 스킬이 자동 호출)"
+---
+
+# tfx-consensus — Tri-CLI Consensus Engine
+
+> 모든 Deep 스킬의 공통 기반. 3개 CLI의 독립 결과를 교차검증하여 합의 도출.
+
+## Core Protocol
+
+이 스킬은 직접 호출하지 않는다. `tfx-deep-*` 스킬이 내부적으로 사용한다.
+
+## Consensus Algorithm
+
+### Phase 1: Independent Analysis (Anti-Herding)
+
+3개 CLI가 **동시에, 상호 결과를 보지 않고** 독립 분석한다. 이것이 핵심이다 — 한 CLI의 결과가 다른 CLI에 영향을 주면 편향이 발생한다.
+
+```
+실행 방식:
+  ├─ Claude (Opus/Sonnet): Agent() 또는 /team worker로 실행
+  ├─ Codex: Bash("codex exec --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check '{prompt}'")
+  └─ Gemini: Bash("gemini -y -p '{prompt}'")
+
+각 CLI에게 동일한 프롬프트를 전달하되, 출력 형식을 JSON으로 강제:
+  {
+    "findings": [
+      { "id": "F1", "category": "...", "severity": "critical|high|medium|low", "description": "...", "evidence": "..." }
+    ],
+    "summary": "...",
+    "confidence": 0.0-1.0
+  }
+```
+
+### Phase 2: Cross-Validation
+
+Claude가 3개 결과를 통합하여 교차검증한다:
+
+```
+입력: result_claude, result_codex, result_gemini
+
+for each finding in ALL results:
+  agreement_count = count(CLIs that found this or similar finding)
+
+  if agreement_count >= 2:
+    mark as "CONSENSUS" (합의됨)
+  elif agreement_count == 1:
+    mark as "DISPUTED" (미합의 — 추가 검증 필요)
+
+consensus_score = len(CONSENSUS) / len(ALL_UNIQUE) * 100
+```
+
+### Phase 3: Resolution (consensus_score < 70일 때)
+
+```
+미합의 항목에 대해 2차 라운드:
+  1. 각 CLI에게 다른 두 CLI의 반대 논거를 제시
+  2. "수용(accept) 또는 반박(rebut)으로 응답하라"
+  3. 수용이 2개 이상이면 CONSENSUS로 승격
+  4. 여전히 미합의이면 사용자에게 판단 요청 (AskUserQuestion)
+```
+
+### Learned Weights (시간 기반 신뢰도)
+
+```
+각 CLI의 historical accuracy를 .omc/state/consensus-weights.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 }
+}
+
+가중 투표 시 accuracy를 weight로 사용:
+  weighted_score = (claude_vote * 0.85 + codex_vote * 0.82 + gemini_vote * 0.78) / (0.85 + 0.82 + 0.78)
+```
+
+## Output Format
+
+```json
+{
+  "consensus_score": 85,
+  "consensus_items": [...],
+  "disputed_items": [...],
+  "resolved_items": [...],
+  "user_decision_needed": [...],
+  "cli_weights": { "claude": 0.85, "codex": 0.82, "gemini": 0.78 }
+}
+```
+
+## Integration Point
+
+Deep 스킬에서 사용하는 방법:
+
+```
+1. 프롬프트 준비 (주제 + 분석 관점 + 출력 형식)
+2. 3개 CLI 병렬 실행 (Bash background + Agent background)
+3. 결과 수집
+4. 위 Consensus Algorithm 적용
+5. consensus_score >= 70 → 확정
+6. consensus_score < 70 → Resolution Phase 진입
+7. 최종 결과를 호출 스킬에 반환
+```
+
+## Token Budget
+
+- Phase 1 (3x 독립분석): ~15K (각 5K)
+- Phase 2 (교차검증): ~3K
+- Phase 3 (Resolution, 필요 시): ~8K
+- **총합**: 18-26K tokens

package/skills/tfx-debate/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: tfx-debate
+description: "기술 선택, 아키텍처 비교, 설계 결정에서 3-CLI 구조화 토론으로 최적 답을 도출한다. 'A vs B', '뭐가 나을까', '비교해줘', '어떤 걸 쓸까', '장단점', 'tradeoff' 같은 비교/선택 요청에 반드시 사용한다. 단순 질문이 아닌 여러 옵션 사이의 결정이 필요할 때 적극 활용."
+triggers:
+  - debate
+  - 토론
+  - 3자 토론
+  - tri-debate
+  - 멀티모델 토론
+argument-hint: "<토론 주제 또는 질문>"
+---
+
+# tfx-debate — Tri-CLI Structured Debate
+
+> 3개 CLI가 독립 분석 → 교차검증 → 합의 도출. Anti-herding으로 편향 없는 결론.
+
+## 용도
+
+- 설계 결정에서 최적 방향을 찾을 때
+- 코드 아키텍처 선택지 비교
+- 기술 선택 (프레임워크, 라이브러리, 접근법)
+- 요구사항 해석이 모호할 때
+- 어떤 주제든 다관점 분석이 필요할 때
+
+## 워크플로우
+
+### Step 1: 주제 파싱
+
+사용자 입력에서 토론 주제를 추출한다. 주제가 모호하거나 비교 대상이 불명확하면 AskUserQuestion으로 명확화한다:
+
+```
+AskUserQuestion:
+  "토론 주제를 더 구체적으로 선택해주세요:"
+  1. {옵션A} vs {옵션B} 기술 비교
+  2. {주제} 아키텍처 접근법 비교
+  3. 직접 입력
+```
+
+주제가 명확한 경우 (예: "REST vs GraphQL") 이 단계를 건너뛴다.
+
+```
+입력: "REST vs GraphQL for our microservice API"
+파싱: {
+  topic: "REST vs GraphQL for microservice API",
+  context: (프로젝트 컨텍스트에서 자동 추출),
+  options: ["REST", "GraphQL"],  // 식별 가능하면
+  criteria: ["성능", "개발 생산성", "유지보수", "학습 곡선"]
+}
+```
+
+### Step 2: 독립 분석 (Anti-Herding)
+
+**반드시 3개를 동시에, 상호 결과 비공개로 실행한다.**
+
+```
+Claude (Agent, background):
+  "당신은 소프트웨어 아키텍트입니다. {topic}에 대해 분석하세요.
+   프로젝트 컨텍스트: {context}
+   각 옵션의 장점, 단점, 리스크를 구조화하세요.
+   최종 추천과 근거를 제시하세요.
+   JSON 형식으로 출력하세요: { recommendation, reasoning, pros, cons, risks, confidence }"
+
+Codex (Bash, background):
+  codex exec --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check \
+    "당신은 시니어 백엔드 엔지니어입니다. {topic}에 대해 구현 관점에서 분석하세요.
+     {context} 기반으로 각 옵션의 기술적 트레이드오프를 평가하세요.
+     JSON: { recommendation, reasoning, pros, cons, risks, confidence }"
+
+Gemini (Bash, background):
+  gemini -y -p \
+    "당신은 DevOps/인프라 엔지니어이자 DX 전문가입니다. {topic}에 대해 운영+개발자경험 관점에서 분석하세요.
+     {context}. JSON: { recommendation, reasoning, pros, cons, risks, confidence }"
+```
+
+### Step 3: 결과 수집 및 교차검증
+
+3개 결과가 모두 수집되면 tfx-consensus 프로토콜 적용:
+
+```
+합의 분석:
+  - 3/3 동일 추천 → "만장일치" (Strong Consensus)
+  - 2/3 동일 추천 → "다수 합의" (Majority Consensus)
+  - 3개 모두 다름 → "불일치" (Disputed → Round 2 필요)
+
+항목별 교차검증:
+  - 2+ CLI가 동일 장점/단점 지적 → 확정
+  - 1개 CLI만 지적 → "미검증" 표시
+```
+
+### Step 4: 토론 라운드 (불일치 시)
+
+불일치 항목이 있으면 2차 라운드 진행:
+
+```
+각 CLI에게:
+  "다음은 다른 두 분석가의 결론입니다:
+   분석가 A: {other_1.recommendation} — 근거: {other_1.reasoning}
+   분석가 B: {other_2.recommendation} — 근거: {other_2.reasoning}
+
+   당신의 원래 입장: {own.recommendation}
+
+   다른 분석가의 논거를 검토한 후:
+   1. 수용할 점이 있으면 입장을 수정하세요
+   2. 반박할 점이 있으면 근거를 제시하세요
+   3. 최종 추천을 다시 제출하세요"
+```
+
+### Step 5: 최종 종합
+
+```
+Claude Opus가 전체 토론을 종합하여 최종 보고서 작성:
+
+## 토론 결과: {topic}
+
+### 합의 사항 (Consensus Score: {score}%)
+- [항목 1] — 3/3 합의
+- [항목 2] — 2/3 합의 (반대: {dissenter} — 근거: {reason})
+
+### 최종 추천
+{recommendation}
+
+### 근거 (3자 종합)
+{synthesized_reasoning}
+
+### 리스크 및 완화 방안
+{risks_and_mitigations}
+
+### 불일치 (해소되지 않은 항목)
+{unresolved_disputes — if any}
+```
+
+## 토큰 예산
+
+| 단계 | 토큰 |
+|------|------|
+| 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-deep-analysis/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: tfx-deep-analysis
+description: "다각도 심층 분석이 필요할 때 사용한다. 'deep analyze', '심층 분석', '제대로 분석', '3관점 분석', '편향 없이 분석' 같은 요청에 사용. 아키텍처 결정, 기술 부채 평가, 대규모 리팩터링 전 분석에 적극 활용."
+triggers:
+  - deep analyze
+  - 심층 분석
+  - deep-analysis
+argument-hint: "<분석 대상 — 파일, 디렉토리, 또는 주제>"
+---
+
+# tfx-deep-analysis — Tri-CLI Deep Analysis
+
+> Claude(아키텍처) + Codex(구현/보안) + Gemini(UX/문서화) → Tri-Debate → 합의.
+> 3자 전문 관점의 편향 없는 분석.
+
+## 핵심 원리
+
+**Tri-Perspective**: 아키텍처/구현보안/UX문서 3축으로 분석하여 단일 관점 편향 제거.
+**Tri-Debate**: 독립 분석 후 교차 토론으로 합의 도출. 불일치 항목도 명시적으로 보고.
+
+## 용도
+
+- 아키텍처 결정 전 종합 분석
+- 레거시 코드베이스 상태 진단
+- 보안 + 성능 + UX 교차 분석
+- 기술 부채 종합 평가
+- 리팩터링 범위 결정
+- 마이그레이션 전 영향도 분석
+
+## 워크플로우
+
+### Phase 1: 대상 수집 및 범위 설정
+
+```
+Claude가 분석 대상을 파싱하고 범위를 정의:
+{
+  "target": "{path_or_topic}",
+  "scope": "디렉토리 전체 — 하위 모듈 포함",
+  "analysis_depth": "파일 구조 + 코드 본문 + 의존성",
+  "focus_areas": ["아키텍처", "보안", "성능", "DX"]
+}
+```
+
+### Phase 2: 3-CLI 독립 분석 (Anti-Herding)
+
+**3개 CLI가 동시에, 상호 결과를 보지 않고 전문 관점에서 분석한다.**
+
+```
+Claude Opus (아키텍처/설계, background):
+  "소프트웨어 아키텍트로서 분석하라:
+   대상: {target}
+
+   분석 렌즈:
+   1. 아키텍처 — 레이어 분리, 의존성 방향, 순환 참조
+   2. 설계 패턴 — SOLID 준수, 적절한 추상화 수준
+   3. 모듈 응집도/결합도 — cohesion/coupling 평가
+   4. 확장성 — 새 요구사항 추가 시 변경 범위
+   5. 테스트 용이성 — DI, 인터페이스, mock 가능성
+
+   JSON: { findings: [{id, category, severity, description, location, recommendation}],
+           architecture_diagram: '텍스트 기반 구조도',
+           health_score: 0-100 }"
+
+Codex (구현/성능/보안, background):
+  codex exec --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check \
+  "시니어 엔지니어+보안 전문가로서 분석하라:
+   대상: {target}
+
+   분석 렌즈:
+   1. 구현 품질 — 복잡도, 중복, 에러 핸들링
+   2. 성능 — 알고리즘 효율, 메모리 패턴, I/O 병목
+   3. 보안 — OWASP Top 10, 입력 검증, 인증/인가
+   4. 안정성 — 에러 전파, 장애 격리, 리소스 관리
+   5. 기술 부채 — deprecated API, TODO, 하드코딩
+
+   JSON: { findings: [...], metrics: {complexity, loc, tech_debt_hours},
+           health_score: 0-100 }"
+
+Gemini (UX/문서화/접근성, background):
+  gemini -y -p \
+  "UX 엔지니어+테크니컬 라이터로서 분석하라:
+   대상: {target}
+
+   분석 렌즈:
+   1. DX(개발자 경험) — API 직관성, 에러 메시지, 사용 용이성
+   2. 문서화 — JSDoc/주석 품질, README, 예제 코드
+   3. 접근성 — UI가 있으면 WCAG 2.1 AA, 키보드/스크린리더
+   4. 국제화 — 하드코딩 문자열, 로케일 처리
+   5. 네이밍 — 일관성, 도메인 언어, 가독성
+
+   JSON: { findings: [...], documentation_score: 0-100,
+           health_score: 0-100 }"
+```
+
+### Phase 3: Tri-Debate (교차검증)
+
+3개 결과를 수집한 후, 각 CLI에게 다른 두 CLI의 분석을 제시하여 교차검증:
+
+```
+각 CLI에게:
+  "다른 두 분석가의 결과입니다:
+   분석가 A: {findings_summary_a}
+   분석가 B: {findings_summary_b}
+
+   1. 동의하는 발견에 '+1' 표시
+   2. 반대하는 발견에 근거를 제시하여 반박
+   3. 다른 분석가가 놓친 중요 사항 추가
+   4. health_score를 재조정하라"
+
+결과: tfx-consensus 프로토콜로 합의 도출
+  - 3/3 동의 → CONFIRMED
+  - 2/3 동의 → LIKELY (반대 의견 첨부)
+  - 1/3만 지적 → UNVERIFIED
+```
+
+### Phase 4: 합의 종합 보고서
+
+```markdown
+# Deep Analysis Report: {target}
+**Consensus Score**: {score}% | **Analysts**: Claude/Codex/Gemini
+**Health Score**: {weighted_avg}/100
+
+## Executive Summary
+{3-5줄 핵심 요약 — 3자 합의 기반}
+
+## Architecture
+{Claude 주도 분석 + Codex/Gemini 교차검증}
+### 구조도
+{텍스트 기반 아키텍처 다이어그램}
+### 강점
+- {3/3 합의된 아키텍처 강점}
+### 약점
+- {2+ 합의된 아키텍처 약점}
+
+## 발견사항 (합의된 항목)
+
+### Critical
+- [C1] `{file}:{line}` — {description} — {3/3}
+  - 아키텍처: {Claude} | 구현: {Codex} | DX: {Gemini}
+  - **권장**: {recommendation}
+
+### High
+- [H1] ...
+
+### Medium
+- [M1] ...
+
+## 메트릭
+| 항목 | 값 | 평가 |
+|------|-----|------|
+| 아키텍처 건강도 | {Claude score}/100 | {평가} |
+| 구현 품질 | {Codex score}/100 | {평가} |
+| DX/문서화 | {Gemini score}/100 | {평가} |
+| 종합 (가중평균) | {avg}/100 | {평가} |
+| 기술 부채 추정 | {hours}h | {심각도} |
+
+## 개선 로드맵 (합의 순)
+| 우선순위 | 항목 | 예상 공수 | 합의도 |
+|---------|------|----------|--------|
+| P0 | {item} | {hours}h | 3/3 |
+| P1 | {item} | {hours}h | 2/3 |
+
+## Unverified (참고용)
+- [U1] {description} (by {single_cli})
+
+## 불일치 사항
+- {항목}: Claude는 {X}, Codex는 {Y}, Gemini는 {Z}
+```
+
+## 토큰 예산
+
+| Phase | 토큰 |
+|-------|------|
+| Phase 1 (수집) | ~1K |
+| Phase 2 (3x 독립분석) | ~15K |
+| Phase 3 (Tri-Debate) | ~9K |
+| Phase 4 (보고서) | ~5K |
+| **총합** | **~30K** |
+
+## 사용 예
+
+```
+/tfx-deep-analysis "src/payment/ 전체 모듈"
+/tfx-deep-analysis "이 프로젝트 아키텍처 심층 분석"
+/tfx-deep-analysis "마이그레이션 전 레거시 API 계층 분석"
+```