triflux 8.5.0 → 8.6.0

package/skills/tfx-autoroute/SKILL.md

@@ -1,184 +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%까지 올려"
-```
+---
+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("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-consensus/SKILL.md

@@ -1,112 +1,114 @@
----
-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
+---
+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에 영향을 주면 편향이 발생한다.
+
+```
+실행 방식 (MANDATORY — headless dispatch):
+  ├─ Claude (Opus/Sonnet): Agent(subagent_type, run_in_background=true)
+  └─ CLI 워커 (Codex+Gemini): Bash("tfx multi --teammate-mode headless --auto-attach --dashboard \
+        --assign 'codex:{prompt}:analyst' \
+        --assign 'gemini:{prompt}:analyst' \
+        --timeout 600")
+
+각 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 병렬 실행 (headless dispatch + 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

@@ -60,16 +60,16 @@ Claude (Agent, background):
    최종 추천과 근거를 제시하세요.
    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 }"
+> **MANDATORY: Codex/Gemini 독립 분석은 headless dispatch로 실행**
 
-Gemini (Bash, background):
-  gemini -y -p \
-    "당신은 DevOps/인프라 엔지니어이자 DX 전문가입니다. {topic}에 대해 운영+개발자경험 관점에서 분석하세요.
-     {context}. JSON: { recommendation, reasoning, pros, cons, risks, confidence }"
+CLI 워커 headless dispatch (Bash, background):
+  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: 결과 수집 및 교차검증