triflux 8.2.3 → 8.3.1

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 계층 분석"
+```

package/skills/tfx-deep-plan/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: tfx-deep-plan
+description: "중요한 기능의 구현 계획을 3자 합의로 수립할 때 사용한다. 'deep plan', '합의 계획', 'ralplan', '철저한 계획', '제대로 설계하고 시작하자' 같은 요청에 사용. 마이크로서비스 도입, 대규모 리팩터링 등 리스크가 큰 작업의 사전 계획에 적극 활용."
+triggers:
+  - deep plan
+  - 합의 계획
+  - consensus plan
+  - deep-plan
+  - 철저한 계획
+  - ralplan
+argument-hint: "<구현할 기능 설명>"
+---
+
+# tfx-deep-plan — Consensus Planning via Tri-CLI Debate
+
+> OMC ralplan 오마주. Planner + Architect + Critic 3자 반복 토론으로 합의된 계획.
+
+## 워크플로우
+
+### Round 1: 독립 계획 (Anti-Herding)
+
+```
+Claude Opus (Planner):
+  "소프트웨어 아키텍트로서 {feature}의 구현 계획을 수립하라.
+   태스크 분해, 순서, 의존성, 검증 방법 포함.
+   JSON: { tasks, dependencies, risks, complexity, reasoning }"
+
+Codex (Architect):
+  "시니어 엔지니어로서 {feature}의 기술적 설계를 작성하라.
+   파일 구조, API 인터페이스, 데이터 모델, 에러 처리 포함.
+   JSON: { design, file_changes, interfaces, data_models, risks }"
+
+Gemini (Critic):
+  "QA/보안 전문가로서 {feature} 구현 시 예상되는 문제를 분석하라.
+   엣지 케이스, 보안 위협, 성능 병목, 테스트 전략 포함.
+   JSON: { edge_cases, security_risks, performance_concerns, test_strategy }"
+```
+
+### Round 2: 교차 검토
+
+각 CLI에게 다른 두 CLI의 결과를 제시:
+
+```
+Claude에게:
+  "Architect 설계: {codex_result}
+   Critic 우려: {gemini_result}
+   이를 반영하여 계획을 수정하라. 수용/반박 근거 포함."
+
+Codex에게:
+  "Planner 계획: {claude_result}
+   Critic 우려: {gemini_result}
+   설계를 수정하라."
+
+Gemini에게:
+  "Planner 계획: {claude_result}
+   Architect 설계: {codex_result}
+   우려 사항이 해소되었는지 판단하라. 미해소 항목 지적."
+```
+
+### Round 3: 합의 도출 (필요 시)
+
+```
+Round 2 후 Consensus Score 산출:
+  >= 80 → 합의 확정
+  60-79 → Round 3 진행 (미합의 항목만)
+  < 60 → 사용자에게 주요 불일치 제시 + 방향 결정 요청
+```
+
+### Final: 합의된 계획 출력
+
+```markdown
+## 합의된 구현 계획: {feature}
+**Consensus Score**: {score}% | **Rounds**: {count}
+
+### 아키텍처 결정
+{3자 합의된 설계 방향}
+
+### 태스크 (합의됨)
+1. [ ] {태스크1} → 검증: {방법} — Planner ✓ Architect ✓ Critic ✓
+2. [ ] {태스크2} → 검증: {방법} — Planner ✓ Architect ✓ Critic: "{조건부}"
+...
+
+### 파일 변경 계획
+| 파일 | 작업 | 이유 |
+|------|------|------|
+| {file} | 생성/수정 | {reason} |
+
+### 리스크 및 완화 (합의됨)
+- {리스크}: {완화} — 3/3 합의
+
+### 테스트 전략 (Critic 주도)
+{Gemini가 제안하고 Claude/Codex가 합의한 테스트 전략}
+
+### 미합의 사항
+- {항목}: {각 CLI 입장 요약}
+```
+
+## 토큰 예산
+
+| 라운드 | 토큰 |
+|--------|------|
+| Round 1 (3x 독립) | ~12K |
+| Round 2 (3x 교차) | ~9K |
+| Round 3 (필요시) | ~6K |
+| 합의 종합 | ~3K |
+| **총합** | **~20-30K** |
+
+## 사용 예
+
+```
+/tfx-deep-plan "마이크로서비스 간 이벤트 기반 통신 도입"
+/tfx-deep-plan "기존 REST API를 GraphQL로 점진적 마이그레이션"
+```