triflux 10.3.4 → 10.7.0

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

@@ -0,0 +1,285 @@
+---
+internal: true
+name: tfx-interview
+description: "요구사항이 모호하거나 구현 전 명확화가 필요할 때 사용한다. 'interview', '인터뷰', '요구사항 정리', '뭘 만들어야 하는지 모르겠어', '명확하게 해줘' 같은 요청에 반드시 사용. 구현 시작 전 스펙을 확정하고 싶을 때 적극 활용."
+triggers:
+  - interview
+  - 인터뷰
+  - 요구사항 탐색
+  - tfx-interview
+  - 모호성 분석
+argument-hint: "<구현할 주제 또는 요구사항>"
+---
+
+# {{SKILL_NAME}} — Quantified Socratic Requirements Exploration
+
+> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
+> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
+
+
+> OMC deep-interview + ouroboros 오마주. 모호성을 숫자로 측정하고 20% 미만까지 질문한다.
+> "측정할 수 없으면 개선할 수 없다."
+>
+> **Gemini 위임**: 분석·점수 계산·산출물 초안은 Gemini CLI에 위임하여 Claude 토큰을 절약한다.
+> 위임 패턴: `Bash("bash scripts/tfx-route.sh gemini exec '{prompt}'")`
+
+## 위임 패턴
+
+Claude와 Gemini의 역할을 분리하여 토큰을 최적화한다.
+
+| 담당 | 작업 |
+|------|------|
+| **Claude** | AskUserQuestion (사용자 상호작용), 최종 파일 저장 |
+| **Gemini** | 모호성 점수 계산, 질문 생성, 응답 분석, 산출물 초안 |
+
+```bash
+# 위임 호출 형태
+Bash("bash scripts/tfx-route.sh gemini exec '{prompt}'")
+```
+
+Gemini 실패 시 Fallback: Claude Opus가 분석을 직접 처리한다.
+
+## 용도
+
+- 구현 전 요구사항 명확화
+- 모호한 요청을 정량적으로 분석하여 실행 가능한 수준으로 구체화
+- 빠진 제약 조건, 성공 기준, 경계 조건을 체계적으로 발견
+- 과잉 구현/과소 구현 방지
+
+## 핵심: 모호성 점수 (Ambiguity Score)
+
+요구사항의 모호성을 수학적으로 측정한다:
+
+```
+ambiguity = 1 - (goal × 0.40 + constraints × 0.30 + criteria × 0.30)
+
+각 요소 (0.0 ~ 1.0):
+  goal       — 목표 명확도. "무엇을 달성하려는가?"가 명확한가?
+  constraints — 제약 조건 명확도. 범위, 기술 스택, 시간, 호환성 등
+  criteria   — 성공 기준 명확도. "어떻게 되면 완료인가?"
+
+예시:
+  입력: "인증 기능 추가해"
+  goal = 0.5 (인증이 무슨 인증? OAuth? JWT? 세션?)
+  constraints = 0.2 (기술 스택? 기존 시스템 연동?)
+  criteria = 0.1 (테스트? 성능? 보안 수준?)
+  ambiguity = 1 - (0.5×0.40 + 0.2×0.30 + 0.1×0.30) = 1 - 0.29 = 0.71 (71%)
+
+목표: ambiguity < 0.20 (20% 미만)이 될 때까지 질문 반복.
+```
+
+## 워크플로우
+
+### Step 1: 초기 모호성 평가
+
+사용자 입력을 Gemini에 전달하여 초기 ambiguity score를 계산한다:
+
+```bash
+# Claude → Gemini 위임
+Bash("bash scripts/tfx-route.sh gemini exec 'Analyze the following requirement and calculate ambiguity score. Return JSON: {goal, constraints, criteria, ambiguity, suggested_questions}: {user_input}'")
+```
+
+Gemini가 반환한 JSON에서 점수를 읽어 사용자에게 표시한다:
+
+```
+출력 예시:
+  "📊 현재 모호성: 71%
+   - 목표: 50% 명확 (어떤 인증 방식?)
+   - 제약: 20% 명확 (기술 스택 미정)
+   - 기준: 10% 명확 (완료 조건 없음)
+   → Stage 1: Clarify부터 시작합니다."
+```
+
+### Step 2: 5단계 인터뷰 (모호성 < 20%까지)
+
+각 단계에서 Claude가 AskUserQuestion으로 질문하고, 사용자 응답을 Gemini에 전달하여 분석 및 다음 질문을 생성한다.
+
+흐름: `Claude(질문) → 사용자(응답) → Gemini(분석+재계산) → Claude(다음 질문 제시)`
+
+#### Stage 1: Clarify (명확화) — goal 개선
+
+```
+질문 방향:
+  - "정확히 무엇을 달성하려는가?"
+  - "이 작업의 범위는 어디까지인가?"
+  - "완료 후 어떤 상태가 되어야 하는가?"
+```
+
+```bash
+# 응답 수집 후 Gemini에 분석 위임
+Bash("bash scripts/tfx-route.sh gemini exec 'Stage 1 response analysis. Previous context: {context}. User answer: {answer}. Calculate updated ambiguity score and generate next stage questions. Return JSON.'")
+```
+
+```
+응답 후: Gemini JSON에서 goal 점수 읽기 → ambiguity 재계산 결과 사용자에게 표시
+```
+
+#### Stage 2: Decompose (분해) — constraints 개선
+
+```
+질문 방향:
+  - "이것을 어떤 하위 문제로 나눌 수 있는가?"
+  - "기술적 제약 조건은? (스택, 호환성, 성능)"
+  - "의존하는 외부 시스템이나 API는?"
+```
+
+```bash
+# 응답 수집 후 Gemini에 분석 위임
+Bash("bash scripts/tfx-route.sh gemini exec 'Stage 2 response analysis. Previous context: {context}. User answer: {answer}. Calculate updated ambiguity score and generate next stage questions. Return JSON.'")
+```
+
+```
+응답 후: Gemini JSON에서 constraints 점수 읽기 → ambiguity 재계산 결과 사용자에게 표시
+```
+
+#### Stage 3: Challenge (반론) — 숨은 제약 발견
+
+```
+질문 방향:
+  - "이 접근의 약점은?"
+  - "실패할 수 있는 시나리오는?"
+  - "6개월 후 유지보수 관점에서 문제될 부분은?"
+```
+
+```bash
+# 응답 수집 후 Gemini에 분석 위임
+Bash("bash scripts/tfx-route.sh gemini exec 'Stage 3 response analysis. Previous context: {context}. User answer: {answer}. Calculate updated ambiguity score and generate next stage questions. Return JSON.'")
+```
+
+```
+응답 후: Gemini JSON에서 constraints + criteria 점수 읽기 → ambiguity 재계산 결과 사용자에게 표시
+```
+
+#### Stage 4: Alternatives (대안) — criteria 정밀화
+
+```
+질문 방향:
+  - "다른 방법은 없는가?"
+  - "시간이 절반이라면 어떤 방식을 택하겠는가?"
+  - "각 대안의 trade-off는?"
+```
+
+```bash
+# 응답 수집 후 Gemini에 분석 위임
+Bash("bash scripts/tfx-route.sh gemini exec 'Stage 4 response analysis. Previous context: {context}. User answer: {answer}. Calculate updated ambiguity score and generate next stage questions. Return JSON.'")
+```
+
+```
+응답 후: Gemini JSON에서 criteria 점수 읽기 → ambiguity 재계산 결과 사용자에게 표시
+```
+
+#### Stage 5: Synthesize (종합) — 최종 확인
+
+```
+질문 방향:
+  - "지금까지의 논의를 종합하면 최적 경로는?"
+  - "첫 번째로 실행할 단계는?"
+  - "이 결정에 대한 확신도는? (1-10)"
+```
+
+```bash
+# 응답 수집 후 Gemini에 최종 분석 위임
+Bash("bash scripts/tfx-route.sh gemini exec 'Stage 5 response analysis. Previous context: {context}. User answer: {answer}. Calculate updated ambiguity score and generate next stage questions. Return JSON.'")
+```
+
+```
+응답 후: Gemini JSON에서 전체 점수 읽기 → 최종 ambiguity score 사용자에게 표시
+```
+
+### Step 3: 조기 종료 판단
+
+매 질문 후 ambiguity를 재계산하고, < 20%이면 남은 단계를 건너뛰고 종합 단계로 이동한다:
+
+```
+질문 후 재계산:
+  if ambiguity < 0.20:
+    → "📊 모호성 {score}% — 충분히 명확합니다. 종합 단계로 이동합니다."
+    → Step 4로 직행
+  elif ambiguity < 0.40:
+    → "📊 모호성 {score}% — 거의 명확합니다. 핵심 질문 1-2개만 더."
+  else:
+    → 다음 단계 진행
+```
+
+### Step 4: 산출물 생성
+
+Gemini가 인터뷰 전체 컨텍스트를 바탕으로 구조화된 문서 초안을 생성하고, Claude가 파일로 저장한다:
+
+```bash
+# Gemini에 산출물 초안 생성 위임
+Bash("bash scripts/tfx-route.sh gemini exec 'Generate a structured interview output document based on the following interview context: {full_context}. Return the complete markdown document.'")
+```
+
+Claude는 Gemini가 반환한 마크다운을 Write 도구로 저장한다.
+
+저장 위치: `.omc/plans/interview-{timestamp}.md`
+
+산출물 형식:
+
+```markdown
+# Interview: {topic}
+Date: {date} | Final Ambiguity: {score}%
+
+## Ambiguity Breakdown
+| 요소 | 초기 | 최종 | 개선 |
+|------|------|------|------|
+| Goal | {init}% | {final}% | +{delta}% |
+| Constraints | {init}% | {final}% | +{delta}% |
+| Criteria | {init}% | {final}% | +{delta}% |
+
+## Goal
+{1문장 목표}
+
+## Constraints
+{제약 조건 목록}
+
+## Success Criteria
+{성공 기준 목록}
+
+## Risks & Challenges
+{식별된 위험}
+
+## Alternatives Considered
+| 대안 | 장점 | 단점 | 채택 |
+|------|------|------|------|
+| ... | ... | ... | Y/N |
+
+## Decision
+{최종 결정 + 근거}
+
+## Action Plan
+1. {단계 1} → 검증: {check}
+2. {단계 2} → 검증: {check}
+3. ...
+```
+
+## 동작 규칙
+
+1. 각 단계에서 반드시 사용자 응답을 수집한 후 다음으로 이동한다.
+2. 매 응답 후 ambiguity score를 재계산하여 진행률을 표시한다.
+3. ambiguity < 20%이면 남은 단계를 건너뛰어도 된다.
+4. 5단계를 모두 거쳐도 ambiguity >= 20%이면 추가 질문 라운드를 진행한다 (최대 2회).
+5. 인터뷰 시작 시 코드베이스를 탐색하여 관련 컨텍스트를 확보한다.
+6. 이전 단계 답변을 다음 단계 질문에 반영한다 (대화형 연결).
+
+## 토큰 예산
+
+| 단계 | Claude | Gemini |
+|------|--------|--------|
+| 초기 평가 (모호성 분석) | ~0.2K | ~1K |
+| 5단계 인터뷰 (질문 제시) | ~1K | ~10K |
+| 산출물 초안 생성 | — | ~2K |
+| 최종 파일 저장 | ~0.5K | — |
+| 코드베이스 탐색 | ~0.3K | — |
+| **총합** | **~2K** | **~13K** |
+
+Fallback: Gemini 호출 실패 시 Claude Opus가 분석을 직접 처리한다 (총합 ~15K).
+
+## 사용 예
+
+```
+/tfx-interview "인증 시스템 리팩터링"
+/tfx-interview "실시간 알림 기능 추가"
+/요구사항 분석 "데이터 파이프라인 설계"
+/인터뷰 "레거시 API를 REST에서 GraphQL로 마이그레이션"
+```

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

@@ -0,0 +1,183 @@
+---
+name: tfx-multi
+description: >
+  멀티-CLI 팀 모드. Claude Native Agent Teams + Codex/Gemini 멀티모델 오케스트레이션.
+  '멀티로', '팀 모드', '다중 CLI', '3개 다 동원', 'multi' 같은 요청에 반드시 사용.
+  Claude+Codex+Gemini 협업이 필요한 모든 상황에 적극 활용.
+triggers:
+  - tfx-multi
+argument-hint: '"작업 설명" | --agents codex,gemini "작업" | --tmux "작업" | status | stop'
+---
+
+# tfx-multi v3 — 파이프라인 기반 멀티-CLI 팀 오케스트레이터
+
+> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
+> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
+
+
+> **인프라**: 다른 스킬이 내부적으로 사용. 직접 호출할 필요 없음.
+> Claude Code Native Teams의 Shift+Down 네비게이션을 복원한다.
+> Codex/Gemini 워커마다 최소 프롬프트(~100 토큰)의 슬림 Agent 래퍼를 spawn하여 네비게이션에 등록하고,
+> 실제 작업은 `tfx-route.sh`가 수행한다. task 상태는 `team_task_list`를 truth source로 검증한다.
+> v3 — `--thorough`(기본: plan→prd→exec→verify→fix loop) + `--quick`(경량 모드).
+
+> **Lead 고토큰 MCP 직접 사용 금지**
+> Lead(Claude Opus)는 웹 서치(brave-search, exa, tavily), 외부 서비스(Notion, Jira/Confluence, Calendar, Gmail),
+> 대량 조회를 직접 호출하지 않는다. Codex `scientist`/`document-specialist` 워커에 위임하면 Claude 토큰을 절약할 수 있다.
+> 단건 조회(이슈 1개 확인 등)는 Lead 직접 허용하되, 3회 이상 반복 호출 시 위임 전환.
+
+## 사용법
+
+```
+/tfx-multi "인증 리팩터링 + UI 개선 + 보안 리뷰"           # --thorough (기본)
+/tfx-multi --quick "인증 리팩터링 + UI 개선 + 보안 리뷰"    # 경량 모드 (plan/verify 생략)
+/tfx-multi --agents codex,gemini "프론트+백엔드"
+/tfx-multi --tmux "작업"         # 레거시 tmux 모드
+/tfx-multi status
+/tfx-multi stop
+```
+
+## 실행 워크플로우
+
+### Phase 0: 사전 점검 (출력 최소화 + 즉시 spawn)
+
+preflight와 Agent 생성을 병렬로 실행하여 사용자 체감 지연을 최소화한다.
+
+- **수동 모드:** Phase 1 파싱 → Phase 3a~3c(TeamCreate + Agent spawn) + Phase 0(preflight) **동시 병렬**
+- **자동 모드:** Phase 0(preflight) + Phase 2(triage) **동시 병렬** → Phase 3
+- 리드에는 요약 한 줄만 노출. 예: `preflight: ok (route/hub)`
+- 권장 체크: `curl -sf http://127.0.0.1:27888/status >/dev/null && test -f ~/.claude/scripts/tfx-route.sh && echo "preflight: ok" || echo "preflight: FAIL"`
+- 실패 시에만 상세 노출 (tfx-route.sh 없음, Hub 비정상, CLI 미설치)
+
+### Phase 1: 입력 파싱
+
+인자 없이 호출되면 "어떤 작업을 실행할까요?" 등으로 입력 요청. TeamCreate/Agent spawn을 시작하지 않는다.
+
+```
+""(빈 문자열)          → 사용자에게 작업 입력 요청
+"3:codex 리뷰"         → 수동 모드: N=3, agent=codex
+"인증 + UI + 테스트"    → 자동 모드 (--thorough 기본): Codex 분류 → Opus 분해 → Pipeline
+"--quick 인증 + UI"    → 경량 모드: plan/verify 생략, 즉시 실행
+"--tmux 인증 + UI"     → Phase 3-mux 분기
+"status" / "stop"      → Bash("node bin/triflux.mjs multi {cmd}") 직행
+```
+
+**모드 결정:**
+- `--quick` 명시 → quick 모드 (Phase 2.5-2.6, 3.5-3.7 생략)
+- `--thorough` 명시 또는 플래그 없음 → thorough 모드 (기본, 전체 파이프라인)
+- 커맨드 숏컷 (tfx-auto 경유 단일 실행) → quick 유지 (오버헤드 불필요)
+
+### Phase 2: 트리아지 (tfx-auto와 동일)
+
+**자동 모드:**
+1. Codex `exec --skip-git-repo-check` 분류 → JSON `{parts: [{description, agent}]}`
+2. Opus 인라인 분해 → 서브태스크 배열 `[{cli, subtask, role}]`
+3. Codex 분류 실패 시 → Opus가 직접 분류+분해
+
+**수동 모드:** Codex 분류 건너뜀 → Opus가 직접 N개 서브태스크 분해.
+
+### Phase 2.5–2.6 + 3.5–3.7: 파이프라인 (기본)
+
+> `--thorough`(기본) 모드에서 실행된다. `--quick` 플래그 시 건너뛴다.
+> 상세는 → [`references/thorough-pipeline.md`](references/thorough-pipeline.md) 참조.
+
+### Phase 3: Lead-Direct Headless 실행 (v6.0.0, 기본)
+
+> **MANDATORY: CLI 워커는 headless 엔진으로 실행**
+> CLI 워커(Codex/Gemini)는 반드시 아래 `Bash()` 명령으로 headless 엔진을 통해 실행한다.
+> `Bash(tfx-route.sh)` 개별 호출이나 `Agent()` CLI 래핑은 PreToolUse 훅이 자동 차단/변환한다.
+> headless 엔진이 psmux 세션 생성 → WT 자동 팝업 → CLI dispatch → 결과 수집을 전부 처리한다.
+
+**실행 명령 (Lead가 호출하는 유일한 명령):**
+
+```
+Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'codex:{프롬프트1}:{역할1}' --assign 'gemini:{프롬프트2}:{역할2}' --timeout 600")
+```
+
+**예시:**
+
+```
+Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'codex:코드 리뷰하고 개선 사항 제안:reviewer' --assign 'gemini:API 문서 작성:writer' --assign 'codex:보안 취약점 분석:security' --timeout 600")
+```
+
+**Claude 워커가 Read/Edit 필요한 경우 (하이브리드):**
+
+Claude 워커는 headless에서 실행 불가 (Read/Edit 도구 필요). CLI 워커만 headless로 보내고 Claude 워커는 Agent로 병렬 실행.
+
+```
+# 1. CLI 워커를 headless로 dispatch
+Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'codex:{프롬프트}:{역할}' --assign 'gemini:{프롬프트}:{역할}' --timeout 600")
+
+# 2. Claude 워커를 Agent로 병렬 실행 (headless Bash와 동시에 spawn)
+Agent(subagent_type="...", prompt="...", run_in_background=true)
+```
+
+**결정 로직:**
+```
+if 모든 워커가 CLI (codex/gemini):
+  → Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign ...")
+elif CLI + Claude 혼합:
+  → CLI 워커: Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign ...")
+  → Claude 워커: Agent(subagent_type, run_in_background=true)
+elif psmux 미설치:
+  → Phase 3-fallback (아래)
+```
+
+**headless 엔진이 자동으로 수행하는 것:**
+- psmux 세션 생성 + progressive split-window
+- Windows Terminal 자동 팝업 (autoAttach)
+- `--dashboard` TUI 대시보드 자동 표시 (headless-guard가 기본 주입)
+- triflux 테마 적용 (Catppuccin Mocha status bar)
+- 워커 요약 dashboard 스플릿
+- CLI 명령 dispatch + 완료 토큰 폴링
+- 결과 수집 + JSON stdout 출력
+- 세션 정리
+
+**출력 파싱:** headless 완료 후 stdout에 JSON 결과가 출력된다. 성공/실패 워커 수, 각 워커 출력을 파싱.
+**크래시 복구:** 세션 사망 시 `{sessionDead: true}` 반환 (throw 대신).
+**실수로 닫아도:** psmux 세션은 독립적. `psmux attach -t 세션이름`으로 재연결.
+
+### Phase 4: 결과 수집 + 정리
+
+headless stdout 출력에서 성공/실패 워커를 파싱.
+실패 워커(`exitCode !== 0`)는 Claude fallback 재시도.
+
+### Phase 3-fallback: Native Teams (psmux 미설치 시)
+
+psmux가 없는 환경에서만 사용. Agent slim wrapper로 CLI를 실행.
+`hub/team/native.mjs`의 `buildSlimWrapperPrompt()` 기반.
+
+**팀 이름 생성 (`generateTeamName`):**
+`tfx-${Date.now().toString(36).slice(-4)}${Math.random().toString(36).slice(2, 6)}`
+타임스탬프 base36 끝 4자 + 난수 4자 조합. 예: `tfx-p1q2r3s4`.
+
+> 래퍼 규칙 상세 → [`references/agent-wrapper-rules.md`](references/agent-wrapper-rules.md)
+
+## 전제 조건
+
+- **CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1** — `tfx setup`이 자동 설정
+- **codex/gemini CLI** — 해당 에이전트 사용 시
+- **Hub 활성 상태** — Named Pipe 우선, HTTP `127.0.0.1:27888` fallback. Hub 미실행 시 nativeProxy fallback.
+
+## 에러 처리
+
+| 에러 | 처리 |
+|------|------|
+| TeamCreate 실패 / Agent Teams 비활성 | `--psmux/--tmux` 폴백 |
+| tfx-route.sh 없음 | `tfx setup` 실행 안내 |
+| CLI 미설치 (codex/gemini) | claude 워커로 대체 |
+| Codex 분류 실패 | Opus 직접 분류+분해 |
+| Bash 실행 실패 | `completed` + `metadata.result: "failed"` 마킹 후 Claude fallback |
+| claude fallback 실패 | 실패 목록/원인 요약 후 사용자 승인 대기 |
+
+> TaskUpdate 상태값: `pending`, `in_progress`, `completed`, `deleted`만 지원. `failed` 사용 금지.
+
+## 관련
+
+| 항목 | 설명 |
+|------|------|
+| `scripts/tfx-route.sh` | 팀 통합 라우터 (v2.5: `--async`/`--job-wait`/`--job-status`/`--job-result`) |
+| `hub/team/native.mjs` | Native Teams 래퍼 (프롬프트 템플릿) |
+| `hub/pipeline/` | 파이프라인 상태 기계 (`--thorough` 모드) |
+| `tfx-auto` | one-shot 실행 오케스트레이터 |
+| `tfx-hub` | MCP 메시지 버스 관리 |

package/skills/tfx-multi/skill.json

@@ -1,8 +1,6 @@
 {
   "name": "tfx-multi",
   "description": "멀티-CLI 팀 모드. Claude Native Agent Teams + Codex/Gemini 멀티모델 오케스트레이션. '멀티로', '팀 모드', '다중 CLI', '3개 다 동원', 'multi' 같은 요청에 반드시 사용. Claude+Codex+Gemini 협업이 필요한 모든 상황에 적극 활용.",
-  "triggers": [
-    "tfx-multi"
-  ],
+  "triggers": ["tfx-multi"],
   "argument_hint": "\"작업 설명\" | --agents codex,gemini \"작업\" | --tmux \"작업\" | status | stop"
 }

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

@@ -0,0 +1,189 @@
+---
+internal: true
+name: tfx-panel
+description: "여러 전문가의 의견이 필요한 복잡한 결정에 사용한다. 'panel', '패널', '전문가 의견', 'expert panel', '다양한 관점', '전문가한테 물어봐' 같은 요청에 반드시 사용. 아키텍처, 보안, 비즈니스 전략 등 전문가 시뮬레이션이 필요할 때 적극 활용."
+triggers:
+  - panel
+  - 패널
+  - 전문가 토론
+  - expert panel
+  - 전문가 패널
+argument-hint: "<토론 주제>"
+---
+
+# {{SKILL_NAME}} — Virtual Expert Panel Simulation
+
+> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
+> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
+
+
+> SuperClaude spec-panel + business-panel 오마주. 실제 전문가 5-10명의 관점을 시뮬레이션하여 다각적 분석.
+> "한 사람의 시야는 좁다. 패널의 시야는 넓다."
+
+## 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 | 기술 구현 전문가 | 아키텍처, 마이크로서비스, 클라우드 |
+| Gemini | 통합/비즈니스 전문가 | 통합 패턴, 경쟁 전략, 프로덕트 |
+
+## 전문가 풀
+
+주제에 따라 5-10명을 자동 선정한다. 고정 풀이 아니라 주제 맥락에서 최적 전문가를 결정한다.
+
+### 기술 전문가 (예시)
+
+| 전문가 | 전문 분야 | 관점 |
+|--------|----------|------|
+| Martin Fowler | 리팩터링, 패턴 | 코드 설계 품질, 기술 부채 |
+| Sam Newman | 마이크로서비스 | 서비스 경계, 분산 시스템 |
+| Kent Beck | TDD, XP | 테스트, 점진적 설계 |
+| Gregor Hohpe | 통합 패턴 | 메시징, 이벤트 아키텍처 |
+| Brendan Burns | 클라우드 네이티브 | 컨테이너, 오케스트레이션 |
+
+### 비즈니스/전략 전문가 (예시)
+
+| 전문가 | 전문 분야 | 관점 |
+|--------|----------|------|
+| Michael Porter | 경쟁 전략 | 시장 포지셔닝, 가치 사슬 |
+| Karl Wiegers | 요구사항 공학 | 요구사항 완전성, 우선순위 |
+| Eric Ries | 린 스타트업 | MVP, 검증된 학습 |
+| Marty Cagan | 프로덕트 | 가치, 실현 가능성, 비즈니스 |
+
+## EXECUTION STEPS
+
+### Step 0: 패널 도메인 선택
+
+주제 인자가 없으면 사용자에게 도메인을 선택받는다:
+
+```
+1. 소프트웨어 아키텍처 (Fowler, Newman, Vernon, Evans)
+2. 보안 (OWASP, Trail of Bits, Schneier)
+3. 비즈니스 전략 (Porter, Christensen, Drucker)
+4. DevOps/SRE (Humble, Kim, Forsgren)
+5. 프론트엔드/UX (Nielsen, Cooper, Krug)
+6. 직접 구성
+```
+
+"직접 구성" 선택 시 사용자가 전문가 이름/역할을 직접 지정한다.
+
+### Step 1: 주제 분석 및 전문가 선정
+
+사용자 입력에서 주제를 파싱하고 관련 도메인을 식별한다. 5-10명의 전문가를 선정하여 3개 CLI에 분배한다.
+
+분배 예시 (`"우리 모놀리스를 마이크로서비스로 전환해야 할까?"`):
+- Claude 담당: Martin Fowler (리팩터링), Kent Beck (점진적 설계)
+- Codex 담당: Sam Newman (마이크로서비스), Michael Porter (전략)
+- Gemini 담당: Gregor Hohpe (통합 패턴), Karl Wiegers (요구사항)
+
+주제가 모호하면 AskUserQuestion으로 명확화한다.
+
+### Step 2: 독립 분석 (Anti-Herding)
+
+**아래 2개 도구를 반드시 같은 응답에서 동시에 호출하라.**
+
+Claude (Agent, background):
+```
+Agent(
+  subagent_type="claude-sonnet-4-5",
+  model="opus",
+  run_in_background=true,
+  prompt="당신은 {claude_expert_1}({role_1})과 {claude_expert_2}({role_2})입니다.
+주제: {topic}
+각 전문가의 고유 관점에서 독립적으로 분석하세요. 상대 전문가의 입장을 참조하지 마세요.
+JSON 형식으로 응답:
+{ 'experts': [{ 'name': string, 'position': string, 'reasoning': string, 'concerns': string[], 'recommendation': string, 'confidence': number }] }"
+)
+```
+
+Codex + Gemini (Bash, background):
+```
+Bash("tfx multi --teammate-mode headless --auto-attach --dashboard \
+  --assign 'codex:당신은 {codex_expert_1}({role_3})과 {codex_expert_2}({role_4})입니다. 주제: {topic}. 각 전문가의 고유 관점에서 독립 분석. 상호 참조 금지. JSON: {experts:[{name,position,reasoning,concerns,recommendation,confidence}]}:analyst' \
+  --assign 'gemini:당신은 {gemini_expert_1}({role_5})과 {gemini_expert_2}({role_6})입니다. 주제: {topic}. 각 전문가의 고유 관점에서 독립 분석. 상호 참조 금지. JSON: {experts:[{name,position,reasoning,concerns,recommendation,confidence}]}:analyst' \
+  --timeout 600")
+```
+
+### Step 3: 패널 토론 시뮬레이션
+
+3개 CLI 결과 수집 후 Claude Opus가 패널 모더레이터로 교차 토론을 시뮬레이션한다:
+
+1. 각 전문가 의견 정리 — 합의점 / 분쟁점 식별
+2. 분쟁점에 대해 가상 반론 생성:
+   - "{expert_A}은 {position_A}를 주장하지만, {expert_B}는 {position_B}를 권고합니다. {expert_A}의 반론은? {expert_B}의 재반론은?"
+3. 2차 라운드: 반론을 반영한 수정 의견 도출
+
+### Step 4: 합의 종합
+
+tfx-consensus 프로토콜 적용:
+
+- 과반(50%+) 합의 → "패널 합의" (근거 포함)
+- 소수 의견 → "소수 견해" (근거 포함)
+- 대립 → "미해결 쟁점" (양측 근거 병기)
+
+### Step 5: 최종 패널 보고서 출력
+
+```markdown
+## 전문가 패널 보고서: {topic}
+
+### 패널 구성
+| # | 전문가 | 역할 | 핵심 입장 |
+|---|--------|------|----------|
+| 1 | {name} | {role} | {position} |
+
+### 패널 합의 (Consensus Score: {score}%)
+- [합의 1] — {N}/{total} 합의
+- [합의 2] — {N}/{total} 합의
+
+### 소수 견해
+- {expert}: {dissenting_view} — 근거: {reason}
+
+### 핵심 추천
+{패널 종합 추천}
+
+### 리스크 및 완화 방안
+{전문가들이 식별한 리스크와 대응책}
+
+### 미해결 쟁점
+{패널 내 해소되지 않은 논쟁}
+
+### 다음 단계 (Action Items)
+1. {action_1}
+2. {action_2}
+```
+
+## ERROR RECOVERY
+
+- Codex/Gemini 타임아웃(600s 초과) → Claude Agent로 해당 전문가 재분석
+- 결과 파싱 실패 → 원문 그대로 Step 3에 투입하여 모더레이터가 정리
+- 전문가 선정 불확실 → AskUserQuestion으로 사용자 확인 후 진행
+
+## TOKEN BUDGET
+
+| 단계 | 토큰 |
+|------|------|
+| Step 1 (주제 분석 + 선정) | ~2K |
+| Step 2 (3x 독립 분석) | ~15K |
+| Step 3 (패널 토론) | ~8K |
+| Step 4 (합의 종합) | ~2K |
+| Step 5 (보고서) | ~3K |
+| **총합** | **~30K** |
+
+## 사용 예
+
+```
+/tfx-panel "우리 모놀리스를 마이크로서비스로 전환해야 할까?"
+/tfx-panel "React vs Svelte vs Solid for our next frontend"
+/tfx-panel "이 레거시 시스템의 리팩터링 전략"
+/tfx-panel "B2B SaaS 가격 모델: 사용량 기반 vs 티어 기반"
+```

package/skills/tfx-panel/skill.json

@@ -1,13 +1,7 @@
 {
   "name": "tfx-panel",
   "description": "여러 전문가의 의견이 필요한 복잡한 결정에 사용한다. 'panel', '패널', '전문가 의견', 'expert panel', '다양한 관점', '전문가한테 물어봐' 같은 요청에 반드시 사용. 아키텍처, 보안, 비즈니스 전략 등 전문가 시뮬레이션이 필요할 때 적극 활용.",
-  "triggers": [
-    "panel",
-    "패널",
-    "전문가 토론",
-    "expert panel",
-    "전문가 패널"
-  ],
+  "triggers": ["panel", "패널", "전문가 토론", "expert panel", "전문가 패널"],
   "argument_hint": "<토론 주제>",
   "internal": true
 }