triflux 10.0.0 → 10.0.2

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

@@ -1,281 +0,0 @@
----
-name: tfx-deep-plan
-description: "중요한 기능의 구현 계획을 3자 합의로 수립할 때 사용한다. 'deep plan', '합의 계획', 'ralplan', '철저한 계획', '제대로 설계하고 시작하자' 같은 요청에 사용. 마이크로서비스 도입, 대규모 리팩터링 등 리스크가 큰 작업의 사전 계획에 적극 활용."
-triggers:
-  - deep plan
-  - 합의 계획
-  - consensus plan
-  - deep-plan
-  - 철저한 계획
-  - ralplan
-argument-hint: "<구현할 기능 설명>"
----
-
-# tfx-deep-plan — Tri-Model Consensus Planning
-
-> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
-> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
-
-
-> **Light 버전**: tfx-plan. 기본값. 깊이 수정자 없으면 Light 선택.
-3개 모델(Opus 4.6 · GPT 5.4 · Gemini)이 독립 설계 후 교차검증하여 합의된 계획을 도출한다.
-
----
-
-## 전제조건 프로브 및 Tier Degradation
-
-> **진입 즉시 실행** — 10초 내 가시적 출력을 보장한다. 빈 stdout + exit 0 **금지**.
-
-### 환경 프로브
-
-워크플로우 진입 전, 아래 프로브를 실행하여 가용 환경을 감지한다:
-
-```bash
-psmux --version 2>/dev/null && \
-  curl -sf http://127.0.0.1:27888/status >/dev/null && \
-  codex --version 2>/dev/null && \
-  gemini --version 2>/dev/null
-```
-
-### Tier 판정
-
-| Tier | 조건 | 실행 방식 |
-|------|------|----------|
-| **Tier 1** | psmux + Hub + Codex + Gemini 전부 정상 | 기존 headless multi (변경 없음) |
-| **Tier 2** | 일부 CLI만 가용 (Codex 또는 Gemini 중 하나) | 가용 CLI + Claude Agent 조합 |
-| **Tier 3** | headless 불가 또는 `claude -p` one-shot | Claude Agent only |
-
-```
-IF claude -p (one-shot 모드):
-  → Tier 3 즉시 fallback
-
-IF psmux 없음 OR Hub 미응답:
-  → Tier 3
-
-IF Codex 없음 AND Gemini 없음:
-  → Tier 3
-
-IF Codex 없음 OR Gemini 없음:
-  → Tier 2
-
-ELSE:
-  → Tier 1
-```
-
-### Tier 3 진입 시 필수 출력
-
-```
-⚠ [Tier 3] headless multi 환경 미충족 — single-model 모드로 실행합니다 (consensus 미적용)
-  누락: {missing_components}
-  권장: psmux, Hub, Codex CLI, Gemini CLI 설치 후 재실행
-```
-
-Tier 3에서는 모든 headless dispatch(`tfx multi ...`)를 **Claude Agent**(subagent)로 대체한다.
-Tier 2에서는 누락된 CLI만 Claude Agent로 대체한다.
-
-## 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. Step 2, Step 4에서 **Bash + Agent를 같은 메시지에서 동시 호출**하여 3개 모델 병렬 실행
-
-## MODEL ROLES
-
-| Model | Profile | 역할 | 강점 |
-|-------|---------|------|------|
-| **Claude Opus 4.6** | Agent(model="opus") | Planner | 전략적 아키텍처 비전, 리스크 통합 판단 |
-| **Codex GPT 5.4** | `--assign 'codex:...:architect'` (gpt54_xhigh) | Architect | 구현 설계, API 인터페이스, 파일 구조 |
-| **Gemini** | `--assign 'gemini:...:critic'` | Critic | 엣지케이스, 보안 위협, 테스트 전략 |
-
----
-
-## EXECUTION — 아래 Step을 순서대로 실행하라
-
-사용자 입력을 `TASK`로 참조한다.
-
-### Step 1: 코드베이스 정찰
-
-TASK와 관련된 코드베이스를 파악한다. 결과를 `RECON`으로 기억한다.
-
-도구 호출:
-```
-Agent(
-  subagent_type="Explore",
-  model="haiku",
-  description="codebase recon",
-  prompt="다음 기능과 관련된 코드베이스를 탐색하라: [TASK 삽입]
-  보고할 것: (1) 관련 파일/디렉토리 (2) 기존 아키텍처 패턴 (3) 주요 의존성/인터페이스. bullet point로 간결하게."
-)
-```
-
-### Step 2: Round 1 — 독립 설계 (Anti-Herding)
-
-3개 모델이 서로의 결과를 **보지 않고** 동시에 독립 분석한다.
-**아래 2개 도구를 반드시 같은 응답에서 동시에 호출하라.**
-
-#### 2a. Claude Opus — Planner (Agent, background)
-
-```
-Agent(
-  subagent_type="oh-my-claudecode:architect",
-  model="opus",
-  run_in_background=true,
-  name="planner-r1",
-  description="deep-plan R1 Planner",
-  prompt="소프트웨어 아키텍트로서 구현 계획을 수립하라.
-
-기능: [TASK 삽입]
-코드베이스: [RECON 삽입]
-
-아래 JSON으로 응답하라:
-{
-  \"vision\": \"설계 방향 1-2문장\",
-  \"tasks\": [{\"id\": \"T1\", \"title\": \"...\", \"desc\": \"...\", \"deps\": [], \"complexity\": \"low|med|high\"}],
-  \"order\": [\"T1\", \"T2\"],
-  \"risks\": [{\"id\": \"R1\", \"desc\": \"...\", \"severity\": \"critical|high|med|low\", \"mitigation\": \"...\"}],
-  \"files\": [{\"path\": \"...\", \"action\": \"create|modify|delete\", \"reason\": \"...\"}],
-  \"confidence\": 0.85,
-  \"reasoning\": \"핵심 결정 이유\"
-}"
-)
-```
-
-#### 2b. Codex + Gemini — Architect + Critic (headless)
-
-`TASK`와 `RECON`을 프롬프트에 삽입하여 아래 Bash를 호출한다.
-프롬프트 안의 작은따옴표는 `'\''`로 이스케이프한다.
-
-```
-Bash("tfx multi --teammate-mode headless --auto-attach --dashboard \
-  --assign 'codex:시니어 엔지니어로서 기술적 설계를 작성하라. 기능: [TASK]. 코드베이스: [RECON]. JSON 응답: {\"architecture\": \"패턴+이유\", \"components\": [{\"name\": \"\", \"responsibility\": \"\", \"interfaces\": []}], \"data_models\": [{\"name\": \"\", \"fields\": [], \"relations\": []}], \"api\": [{\"endpoint\": \"\", \"method\": \"\", \"desc\": \"\"}], \"files\": [{\"path\": \"\", \"purpose\": \"\"}], \"impl_notes\": [], \"confidence\": 0.85}:architect' \
-  --assign 'gemini:QA 보안 전문가로서 구현 리스크를 분석하라. 기능: [TASK]. 코드베이스: [RECON]. JSON 응답: {\"edge_cases\": [{\"id\": \"E1\", \"scenario\": \"\", \"impact\": \"\", \"fix\": \"\"}], \"security\": [{\"id\": \"S1\", \"threat\": \"\", \"severity\": \"critical|high|med|low\", \"mitigation\": \"\"}], \"performance\": [{\"id\": \"P1\", \"bottleneck\": \"\", \"optimization\": \"\"}], \"test_strategy\": {\"unit\": [], \"integration\": [], \"edge_case\": []}, \"missing_reqs\": [], \"risk_level\": \"low|med|high|critical\", \"confidence\": 0.85}:critic' \
-  --timeout 600")
-```
-
-### Step 3: 결과 수집
-
-- `RESULT_PLANNER`: planner-r1 Agent 결과 (SendMessage로 수신 또는 완료 알림 대기)
-- `RESULT_ARCHITECT` + `RESULT_CRITIC`: headless stdout JSON에서 각 워커 출력 추출
-
-**실패 워커 처리**: 워커가 실패하면 Claude Agent로 해당 역할을 대체 실행한다.
-
-### Step 4: Round 2 — 교차 검토
-
-각 모델에게 다른 두 모델의 Round 1 결과를 제시하고 수용/수정/반박을 요청한다.
-**아래 2개 도구를 반드시 같은 응답에서 동시에 호출하라.**
-
-#### 4a. Claude Opus — 계획 수정 (Agent, background)
-
-```
-Agent(
-  subagent_type="oh-my-claudecode:critic",
-  model="opus",
-  run_in_background=true,
-  name="planner-r2",
-  description="deep-plan R2 cross-review",
-  prompt="Round 1 결과를 교차 검토하고 계획을 수정하라.
-
-네 계획: [RESULT_PLANNER 삽입]
-Architect(Codex) 설계: [RESULT_ARCHITECT 삽입]
-Critic(Gemini) 분석: [RESULT_CRITIC 삽입]
-
-각 항목에 대해:
-- ACCEPT: 수용 (이유)
-- MODIFY: 부분 수정 (원안→수정안, 이유)
-- REJECT: 반박 (근거)
-
-JSON: {\"revisions\": [{\"source\": \"codex|gemini\", \"item\": \"...\", \"action\": \"accept|modify|reject\", \"reason\": \"...\"}], \"updated_plan\": {같은 스키마}}"
-)
-```
-
-#### 4b. Codex + Gemini — 교차 검토 (headless)
-
-3개 Round 1 결과를 각 프롬프트에 삽입한다. 결과가 길면 핵심만 요약하여 삽입.
-
-```
-Bash("tfx multi --teammate-mode headless --auto-attach --dashboard \
-  --assign 'codex:교차 검토하라. Planner 계획: [RESULT_PLANNER 요약]. 네 설계: [RESULT_ARCHITECT 요약]. Critic 분석: [RESULT_CRITIC 요약]. 각 항목 ACCEPT/MODIFY/REJECT + 이유. JSON: {\"revisions\": [...], \"updated_design\": {같은 스키마}}:architect' \
-  --assign 'gemini:교차 검토하라. Planner 계획: [RESULT_PLANNER 요약]. Architect 설계: [RESULT_ARCHITECT 요약]. 네 분석: [RESULT_CRITIC 요약]. 우려 해소 여부 판단. JSON: {\"resolved\": [...], \"still_concerned\": [...], \"new_concerns\": [...], \"updated_test_strategy\": {...}}:critic' \
-  --timeout 600")
-```
-
-### Step 5: 합의 점수 산출
-
-Round 2 결과를 모아 Claude가 직접 계산한다 (Agent 불필요):
-
-```
-모든 고유 항목에 대해:
-  동의 수 = 해당 항목에 동의한 모델 수 (ACCEPT 또는 유사 제안)
-
-  >= 2 동의 → CONSENSUS (합의)
-  == 1 동의 → DISPUTED (미합의)
-
-consensus_score = CONSENSUS / 전체_고유_항목 * 100
-
-분기:
-  >= 80% → Step 6 확정
-  60-79% → Round 3 진행 (미합의 항목만 재토론, 같은 headless 패턴)
-  < 60%  → AskUserQuestion으로 핵심 불일치 제시, 사용자 판단 요청
-```
-
-### Step 6: 합의된 계획 출력
-
-아래 형식으로 최종 결과를 출력한다:
-
-```markdown
-## 합의된 구현 계획: [TASK]
-
-**Consensus**: {score}% | **Rounds**: {count} | **Models**: Opus 4.6 + GPT 5.4 + Gemini
-
-### 설계 방향
-{3자 합의된 아키텍처 결정}
-
-### 태스크
-| # | 태스크 | 복잡도 | 합의 | 비고 |
-|---|--------|--------|------|------|
-| T1 | {title} | {complexity} | P:✓ A:✓ C:✓ | {notes} |
-
-### 파일 변경
-| 파일 | 작업 | 이유 |
-|------|------|------|
-| {path} | {action} | {reason} |
-
-### 리스크 & 완화
-| 리스크 | 심각도 | 완화 | 합의 |
-|--------|--------|------|------|
-| {risk} | {severity} | {mitigation} | {n}/3 |
-
-### 테스트 전략 (Critic 주도)
-{Gemini가 제안하고 나머지가 합의한 테스트 계획}
-
-### 미합의 사항
-| 항목 | Planner(Opus) | Architect(GPT5.4) | Critic(Gemini) |
-|------|---------------|---------------------|----------------|
-| {item} | {position} | {position} | {position} |
-```
-
----
-
-## ERROR RECOVERY
-
-| 상황 | 대응 |
-|------|------|
-| headless timeout (600s) | Claude Agent로 해당 역할 대체 실행 |
-| Codex 워커 실패 | `Agent(subagent_type="oh-my-claudecode:architect", model="opus")` 대체 |
-| Gemini 워커 실패 | `Agent(subagent_type="oh-my-claudecode:critic", model="sonnet")` 대체 |
-| consensus < 60% | AskUserQuestion → 사용자 방향 결정 후 해당 방향으로 확정 |
-| 프롬프트 quoting 오류 | 작은따옴표 → `'\''` 이스케이프. 줄바꿈 → 공백 치환 |
-
-## TOKEN BUDGET
-
-| Phase | Tokens |
-|-------|--------|
-| Step 1: Recon (Haiku) | ~2K |
-| Step 2: Round 1 (3 parallel) | ~15K |
-| Step 4: Round 2 (3 parallel) | ~12K |
-| Step 5-6: Consensus + Output | ~3K |
-| **Total** | **~25-32K** |

package/skills/tfx-deep-plan/skill.json

@@ -1,13 +0,0 @@
-{
-  "name": "tfx-deep-plan",
-  "description": "중요한 기능의 구현 계획을 3자 합의로 수립할 때 사용한다. 'deep plan', '합의 계획', 'ralplan', '철저한 계획', '제대로 설계하고 시작하자' 같은 요청에 사용. 마이크로서비스 도입, 대규모 리팩터링 등 리스크가 큰 작업의 사전 계획에 적극 활용.",
-  "triggers": [
-    "deep plan",
-    "합의 계획",
-    "consensus plan",
-    "deep-plan",
-    "철저한 계획",
-    "ralplan"
-  ],
-  "argument_hint": "<구현할 기능 설명>"
-}

package/skills/tfx-deep-qa/SKILL.md.tmpl

@@ -1,164 +0,0 @@
----
-name: tfx-deep-qa
-description: "보안, 성능, 접근성까지 포함한 철저한 검증이 필요할 때 사용한다. 'deep qa', '심층 검증', '철저히 테스트', '보안까지 확인', '전방위 검증' 같은 요청에 사용. 프로덕션 배포 전 다각도 품질 검증에 적극 활용."
-triggers:
-  - deep qa
-  - 심층 검증
-  - thorough test
-  - deep-qa
-argument-hint: "[테스트 대상 경로 또는 기능 설명]"
----
-
-# tfx-deep-qa — Tri-CLI Deep Verification
-
-> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
-> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
-
-
-> **Light 버전**: tfx-qa. 기본값. 깊이 수정자 없으면 Light 선택.
-> 3-CLI 독립 검증 → 교차검증 → 2+ 합의 항목만 보고. false-positive 87% 감소.
-
-## 핵심 원리
-
-**Anti-Herding**: 3개 CLI가 서로의 결과를 보지 않고 독립 검증.
-**Consensus Only**: 2개 이상 CLI가 동일 이슈를 지적한 항목만 최종 보고.
-
-## 용도
-
-- 릴리스 전 전면 검증
-- 보안/성능/접근성을 동시에 다각도 점검
-- 단일 CLI 검증으로는 놓치는 교차 영역 결함 탐지
-- false-positive 최소화가 필요한 QA 게이트
-
-## 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 Opus | 기능검증 | 기능 정확성, 엣지케이스, 누락 테스트 |
-| Codex | 보안+성능 | OWASP Top 10, O(n²) 복잡도, 메모리 누수, 입력 검증 |
-| Gemini | UX+접근성 | API 응답 일관성, 에러 메시지, WCAG 2.1 AA |
-
-## EXECUTION STEPS
-
-### Step 1: 검증 대상 수집
-
-대상을 다음 우선순위로 결정한다:
-1. 사용자 지정 파일/경로 → 해당 범위
-2. `git diff` (staged + unstaged) → 변경된 파일
-3. 지정 없음 → 프로젝트 전체 테스트
-
-수집 항목: 변경 파일 목록 + diff, 관련 테스트 파일, 영향 받는 모듈/의존성
-
-### Step 2: 3-CLI 독립 검증 — 아래 2개 도구를 반드시 같은 응답에서 동시에 호출하라.
-
-**Claude Agent (기능검증):**
-```
-Agent(
-  subagent_type="oh-my-claudecode:verifier",
-  model="opus",
-  run_in_background=true,
-  name="qa-functional",
-  description="기능 정확성 및 엣지케이스 검증",
-  prompt="QA 엔지니어로서 다음 코드의 기능 정확성을 검증하라. 테스트를 실행하고 결과를 보고하라. 누락된 엣지 케이스를 식별하라 (null, 빈 입력, 경계값, 동시성). 누락된 테스트 케이스를 제안하라. JSON으로 응답하라: { test_result: {pass, fail, skip}, findings: [{id, file, line, category, severity, description, test_scenario}], edge_case_tests: [...], overall_verdict: 'pass'|'fail' }"
-)
-```
-
-**Codex + Gemini headless dispatch (보안+성능+UX):**
-```
-Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'codex:보안/성능 전문가로서 이 코드를 검증하라. OWASP Top 10을 체크하라. O(n²) 이상 복잡도를 탐지하라. 메모리 누수 패턴을 찾아라. 입력 검증 누락을 확인하라. JSON으로 응답하라: { findings: [{id, file, line, category, severity, description, fix}], overall_verdict: \"pass\"|\"fail\" }:verifier' --assign 'gemini:UX/접근성 전문가로서 이 코드를 검증하라. API 응답 형식 일관성을 확인하라. 에러 메시지의 사용자 친화성을 평가하라. WCAG 2.1 AA 준수를 검토하라 (UI 관련 시). 문서와 실제 동작 일치 여부를 확인하라. JSON으로 응답하라: { findings: [{id, file, line, category, severity, description, suggestion}], overall_verdict: \"pass\"|\"fail\" }:verifier' --timeout 600")
-```
-
-### Step 3: Consensus Scoring
-
-모든 findings를 수집하여 유사도를 비교한다:
-- 동일 파일+라인±5 + 유사 카테고리 → 동일 이슈로 간주
-- 3/3 합의 → CONFIRMED (severity 유지)
-- 2/3 합의 → LIKELY (severity 유지, 반대 의견 첨부)
-- 1/3만 지적 → UNVERIFIED (참고용, 별도 섹션)
-
-`consensus_score = consensus_items / total_unique_items × 100`
-
-### Step 4: 실패 수정 — 합의된 Critical/High 항목에 대해서만 실행
-
-```
-Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'codex:다음 합의된 이슈들을 수정하라. 각 이슈에 대해 최소한의 변경으로 수정하고 수정 후 테스트를 재실행하여 통과 여부를 확인하라. 이슈 목록: {consensus_findings}:fixer' --timeout 300")
-```
-
-### Step 5: 종합 보고서 작성
-
-아래 형식으로 보고서를 출력한다:
-
-```markdown
-## Deep QA Report: {target}
-**Consensus Score**: {score}% | **Verifiers**: Claude/Codex/Gemini
-**Verdict**: PASS / CONDITIONAL PASS / FAIL
-
-### Critical (3/3 합의)
-- [C1] `{file}:{line}` — {description}
-  - Claude: {detail} | Codex: {detail} | Gemini: {detail}
-  - **Fix**: {applied_fix}
-
-### High (2/3 합의)
-- [H1] `{file}:{line}` — {description}
-  - 합의: {agreers} | 반대: {dissenter}: "{reason}"
-
-### Verified Medium
-- ...
-
-### 엣지 케이스 테스트 제안
-| 시나리오 | 입력 | 기대 결과 | 제안자 |
-|---------|------|----------|--------|
-| {scenario} | {input} | {expected} | Claude |
-
-### Unverified (1/3만 지적, 참고용)
-- [U1] `{file}:{line}` — {description} (by {single_cli})
-
-### 수정 요약
-- 수정된 파일: {list}
-- 테스트 재실행 결과: {pass}/{total}
-
-### 검증 통계
-| CLI | 영역 | 발견 수 | 합의 기여율 |
-|-----|------|---------|------------|
-| Claude | 기능/엣지케이스 | {n} | {%} |
-| Codex | 보안/성능 | {n} | {%} |
-| Gemini | UX/접근성 | {n} | {%} |
-```
-
-## ERROR RECOVERY
-
-| 오류 | 조치 |
-|------|------|
-| headless dispatch 타임아웃 | `--timeout` 값을 900으로 올려 재시도 |
-| Agent 결과 미수신 | Step 2를 Agent만 단독 재실행 |
-| consensus 0% | 대상 범위가 너무 넓음 — 파일 단위로 분할 후 재실행 |
-| tfx multi 명령 실패 | `tfx status`로 teammate 연결 상태 확인 |
-
-## 토큰 예산
-
-| 단계 | 토큰 |
-|------|------|
-| Step 1 (수집) | ~1K |
-| Step 2 (3x 독립 검증) | ~15K |
-| Step 3 (Consensus) | ~3K |
-| Step 4 (수정) | ~3K |
-| Step 5 (보고) | ~3K |
-| **총합** | **~25K** |
-
-## 사용 예
-
-```
-/tfx-deep-qa
-/tfx-deep-qa "src/auth/ 디렉토리 전체"
-/tfx-deep-qa "최근 커밋 변경사항 심층 검증"
-/tfx-deep-qa "결제 모듈 배포 전 최종 검증"
-```

package/skills/tfx-deep-qa/skill.json

@@ -1,11 +0,0 @@
-{
-  "name": "tfx-deep-qa",
-  "description": "보안, 성능, 접근성까지 포함한 철저한 검증이 필요할 때 사용한다. 'deep qa', '심층 검증', '철저히 테스트', '보안까지 확인', '전방위 검증' 같은 요청에 사용. 프로덕션 배포 전 다각도 품질 검증에 적극 활용.",
-  "triggers": [
-    "deep qa",
-    "심층 검증",
-    "thorough test",
-    "deep-qa"
-  ],
-  "argument_hint": "[테스트 대상 경로 또는 기능 설명]"
-}

package/skills/tfx-deep-research/SKILL.md.tmpl

@@ -1,216 +0,0 @@
----
-name: tfx-deep-research
-description: "기술 비교, 아키텍처 조사, 경쟁사 분석 등 깊이 있는 리서치가 필요할 때 사용한다. '심층 조사', '자세히 알아봐', 'deep research', '전면 리서치', '비교 분석 보고서', '종합 리서치' 같은 요청에 반드시 사용. 단순 검색이 아닌 멀티소스 교차검증이 필요한 리서치에 적극 활용."
-triggers:
-  - deep research
-  - 딥 리서치
-  - 심층 리서치
-  - deep-research
-  - thorough research
-  - 깊이 조사
-  - 전면 리서치
-argument-hint: "[--depth quick|standard|deep] <리서치 주제>"
----
-
-# tfx-deep-research — Multi-Source Deep Research with Tri-CLI Consensus
-
-> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
-> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
-
-
-> **Light 버전**: tfx-research. 기본값. 깊이 수정자 없으면 Light 선택.
-> 쿼리 분해 → 3-CLI 독립 병렬 검색 → 교차검증 → 합의 기반 종합 보고서.
-> STORM(Stanford) perspective-guided + GPT-Researcher recursive tree + Tavily deep research pipeline 영감.
-
-## 용도
-
-- 기술 선택 전 심층 조사
-- 경쟁사/대안 분석
-- 새 도메인 학습을 위한 종합 리서치
-- 아키텍처 결정 근거 수집
-- 학술/산업 동향 파악
-
-## 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 | MCP | 관점 |
-|-----|-----|------|
-| Claude | Exa (neural semantic) | 학술/기술 깊이 (논문, 공식 문서, 벤치마크) |
-| Codex | Brave Search | 실용/구현/산업 사례 중심 |
-| Gemini | Tavily | 비용/운영/DX(개발자 경험) 중심 |
-
-## Depth 모드
-
-| 모드 | 서브쿼리 | 소스/쿼리 | 라운드 | 토큰 | 시간 |
-|------|---------|----------|--------|------|------|
-| quick | 3개 | 2 | 1 | ~20K | 2-3분 |
-| standard | 5개 | 3 | 1-2 | ~40K | 5-8분 |
-| deep | 8-10개 | 5 | 2-3 | ~80K | 10-15분 |
-
-기본값: standard
-
-## EXECUTION STEPS
-
-### Pre-Phase: Depth 선택
-
-`--depth` 플래그가 지정되지 않은 경우, AskUserQuestion으로 depth를 선택받아라:
-
-```
-AskUserQuestion:
-  "리서치 깊이를 선택하세요:"
-  1. quick (3 서브쿼리, ~20K 토큰, 2-3분)
-  2. standard (5 서브쿼리, ~40K 토큰, 5-8분) [기본]
-  3. deep (8-10 서브쿼리, ~80K 토큰, 10-15분)
-```
-
-사용자가 빈 응답을 보내면 기본값 `standard`를 적용하라.
-
-### Step 1: 주제 분석 및 쿼리 분해
-
-Claude Opus로 주제를 분석하고 서브쿼리로 분해하라:
-
-- depth에 따라 서브쿼리 수를 결정한다 (quick=3, standard=5, deep=8-10)
-- 각 서브쿼리에 관점(학술/기술, 실용/산업, 비용/운영)을 매핑한다
-- sub_queries 목록과 perspectives 목록을 내부적으로 보유한다
-
-### Step 2: 3-CLI 독립 병렬 검색 (Anti-Herding)
-
-**아래 2개 도구를 반드시 같은 응답에서 동시에 호출하라.**
-
-Claude Agent를 백그라운드로 실행하라:
-
-```
-Agent(
-  subagent_type="claude",
-  model="opus",
-  run_in_background=true,
-  prompt="다음 서브쿼리를 Exa web_search_exa로 검색하라.
-  서브쿼리 목록: {sub_queries}
-  관점: 학술/기술 깊이 (논문, 공식 문서, 벤치마크)
-  각 쿼리에서 category='research paper' 우선, highlights=true, numResults=5로 검색하라.
-  각 결과의 제목, URL, 핵심 내용을 추출하여 구조화하여 반환하라."
-)
-```
-
-Codex와 Gemini를 headless dispatch로 동시에 실행하라:
-
-```
-Bash("tfx multi --teammate-mode headless --auto-attach --dashboard \
-  --assign 'codex:다음 서브쿼리를 Brave Search로 검색하고 결과를 종합하라. 서브쿼리 목록: {sub_queries}. 관점: 실용/구현/산업 사례 중심. brave_web_search와 brave_news_search를 활용하고, freshness=pw로 최신 결과를 우선하라. 각 쿼리당 상위 5개 결과의 제목, URL, 핵심 내용을 구조화하여 반환하라.:researcher' \
-  --assign 'gemini:다음 서브쿼리를 Tavily로 검색하라. 서브쿼리 목록: {sub_queries}. 관점: 비용/운영/DX(개발자 경험) 중심. tavily_search를 search_depth=advanced, max_results=5, include_raw_content=false로 호출하라. 각 결과를 구조화하여 제목, URL, 핵심 내용을 반환하라.:researcher' \
-  --timeout 600")
-```
-
-### Step 3: 결과 수집 및 교차검증
-
-3개 CLI 결과가 모두 수집되면 다음 기준으로 교차검증하라:
-
-1. 사실 일치: 3개 소스가 동일 사실을 보고하는가
-2. 추천 일치: 동일 기술/접근법을 추천하는가
-3. 수치 일치: 벤치마크, 가격, 성능 수치가 일치하는가
-4. 리스크 일치: 동일 위험을 식별하는가
-
-소스 신뢰도를 다음 가중치로 평가하라:
-- 공식 문서/벤치마크 → weight 1.0
-- 학술 논문 → weight 0.9
-- 신뢰 블로그 (engineering blog) → weight 0.7
-- 일반 블로그/포럼 → weight 0.5
-- 날짜 가중: 6개월 이내 ×1.0, 1년 이내 ×0.8, 2년 이내 ×0.5
-
-### Step 4: 합의 종합 보고서 생성
-
-Claude Opus가 교차검증된 결과를 종합하여 다음 구조로 최종 보고서를 작성하라:
-
-```markdown
-# Deep Research Report: {topic}
-**Date**: {date} | **Depth**: {depth} | **Consensus Score**: {score}%
-**Sources**: {total_sources}개 | **Sub-queries**: {count}개
-
-## Executive Summary
-{3-5줄 핵심 요약}
-
-## 핵심 발견사항 (Consensus Items)
-### 1. {finding_1} — 합의도: {3/3 또는 2/3}
-{상세 내용 + 근거 + 출처}
-
-### 2. {finding_2}
-...
-
-## 비교 분석
-| 항목 | 옵션A | 옵션B | 옵션C |
-|------|-------|-------|-------|
-| 성능 | ... | ... | ... |
-| 비용 | ... | ... | ... |
-| 운영 | ... | ... | ... |
-
-## 미합의 사항 (Disputed Items)
-- {항목}: Claude는 X, Codex는 Y, Gemini는 Z — 이유: ...
-
-## 추천
-{교차검증된 최종 추천 + 조건부 판단 기준}
-
-## 소스 목록
-1. [{title}]({url}) — 신뢰도: {score} — 사용 MCP: {exa|brave|tavily}
-...
-```
-
-### Step 5: Recursive Depth (deep 모드 전용)
-
-deep 모드에서 Phase 3 교차검증 중 중요 하위 주제가 발견되면 재귀적으로 Step 2-4를 반복하라:
-
-- 최대 3개 하위 주제까지 재귀 실행한다
-- 각 재귀 결과를 메인 보고서에 병합한다
-- 재귀 실행도 반드시 Agent + Bash 동시 호출 패턴을 사용한다
-
-## ERROR RECOVERY
-
-- Codex 또는 Gemini 결과가 없으면: 해당 CLI 없이 2개 소스로 교차검증을 진행하고 보고서에 누락 CLI를 명시하라
-- tfx multi 명령이 실패하면: 오류 메시지를 그대로 출력하고 재시도 1회 후 실패를 사용자에게 보고하라
-- Agent 결과가 없으면: Claude Exa 검색 없이 나머지 2개 소스로 진행하라
-
-## TOKEN BUDGET
-
-| 단계 | quick | standard | deep |
-|------|-------|----------|------|
-| Step 1 (분해) | 1K | 2K | 3K |
-| Step 2 (3x검색) | 9K | 18K | 30K |
-| Step 3 (교차검증) | 3K | 5K | 8K |
-| Step 4 (보고서) | 5K | 10K | 15K |
-| Step 5 (재귀) | — | — | 24K |
-| **총합** | **~18K** | **~35K** | **~80K** |
-
-## MCP 활용 전략 (Exa/Brave/Tavily 리버스엔지니어링 기반)
-
-### Exa 최적 활용
-- `type: "auto"` — neural+keyword 하이브리드
-- `category: "research paper"` — 학술 검색 시
-- `highlights: true, text.maxCharacters: 300` — 토큰 효율 핵심
-- `includeDomains` — 신뢰 도메인 필터링
-
-### Brave 최적 활용
-- `brave_news_search` — 최신 동향/뉴스
-- `freshness: "pw"` (past week) — 최신성 보장
-- `result_filter: "web"` — 불필요한 결과 방지
-- 독립 인덱스 → Google/Bing과 다른 결과
-
-### Tavily 최적 활용
-- `tavily_search` — 빠른 범용 검색
-- `include_raw_content: false` — 토큰 절약
-- `max_results: 5` — 적정 결과 수
-- `search_depth: "advanced"` — standard 모드 이상
-
-## 사용 예
-
-```
-/tfx-deep-research "2026 실시간 데이터 파이프라인 아키텍처 비교"
-/tfx-deep-research --depth deep "Claude Code vs Cursor vs Windsurf 멀티에이전트 지원 비교"
-/tfx-deep-research --depth quick "pnpm vs bun vs npm 2026 벤치마크"
-```