triflux 8.2.3 → 8.3.1

package/skills/tfx-panel/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: tfx-panel
+description: "여러 전문가의 의견이 필요한 복잡한 결정에 사용한다. 'panel', '패널', '전문가 의견', 'expert panel', '다양한 관점', '전문가한테 물어봐' 같은 요청에 반드시 사용. 아키텍처, 보안, 비즈니스 전략 등 전문가 시뮬레이션이 필요할 때 적극 활용."
+triggers:
+  - panel
+  - 패널
+  - 전문가 토론
+  - expert panel
+  - 전문가 패널
+argument-hint: "<토론 주제>"
+---
+
+# tfx-panel — Virtual Expert Panel Simulation
+
+> SuperClaude spec-panel + business-panel 오마주. 실제 전문가 5-10명의 관점을 시뮬레이션하여 다각적 분석.
+> "한 사람의 시야는 좁다. 패널의 시야는 넓다."
+
+## 용도
+
+- 아키텍처 설계에서 다관점 검토가 필요할 때
+- 기술 전략 결정 (마이그레이션, 프레임워크 선택, 인프라 전환)
+- 요구사항이 모호하여 여러 전문 분야의 시각이 필요할 때
+- 리팩터링 범위와 방향에 대한 전문가 합의 도출
+- 비즈니스 + 기술 관점을 동시에 고려해야 할 때
+
+## 전문가 풀
+
+주제에 따라 5-10명을 자동 선정한다. 고정 풀이 아니라 주제 맥락에서 최적 전문가를 결정한다.
+
+### 기술 전문가 (예시)
+
+| 전문가 | 전문 분야 | 관점 |
+|--------|----------|------|
+| Martin Fowler | 리팩터링, 패턴 | 코드 설계 품질, 기술 부채 |
+| Sam Newman | 마이크로서비스 | 서비스 경계, 분산 시스템 |
+| Kent Beck | TDD, XP | 테스트, 점진적 설계 |
+| Gregor Hohpe | 통합 패턴 | 메시징, 이벤트 아키텍처 |
+| Brendan Burns | 클라우드 네이티브 | 컨테이너, 오케스트레이션 |
+
+### 비즈니스/전략 전문가 (예시)
+
+| 전문가 | 전문 분야 | 관점 |
+|--------|----------|------|
+| Michael Porter | 경쟁 전략 | 시장 포지셔닝, 가치 사슬 |
+| Karl Wiegers | 요구사항 공학 | 요구사항 완전성, 우선순위 |
+| Eric Ries | 린 스타트업 | MVP, 검증된 학습 |
+| Marty Cagan | 프로덕트 | 가치, 실현 가능성, 비즈니스 |
+
+## 워크플로우
+
+### Step 0: 패널 도메인 선택
+
+AskUserQuestion으로 전문가 패널의 도메인을 선택받는다:
+
+```
+AskUserQuestion:
+  "패널 도메인을 선택하세요:"
+  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에서 해당 분야의 전문가를 우선 선정한다.
+"직접 구성"을 선택하면 사용자가 전문가 이름/역할을 직접 지정할 수 있다.
+
+### Step 1: 주제 분석 및 전문가 선정
+
+사용자 입력에서 주제를 파싱하고, 관련 전문 분야를 식별하여 5-10명의 전문가를 선정한다.
+
+```
+입력: "우리 모놀리스를 마이크로서비스로 전환해야 할까?"
+분석: {
+  topic: "모놀리스 → 마이크로서비스 전환",
+  domains: ["아키텍처", "운영", "조직", "비즈니스"],
+  selected_experts: [
+    { name: "Sam Newman", role: "마이크로서비스 아키텍트", cli: "codex" },
+    { name: "Martin Fowler", role: "리팩터링 전문가", cli: "claude" },
+    { name: "Gregor Hohpe", role: "통합 패턴 전문가", cli: "gemini" },
+    { name: "Michael Porter", role: "전략 분석가", cli: "codex" },
+    { name: "Kent Beck", role: "점진적 설계 옹호자", cli: "claude" },
+    { name: "Karl Wiegers", role: "요구사항 검증자", cli: "gemini" }
+  ]
+}
+```
+
+모호하면 AskUserQuestion으로 주제 명확화.
+
+### Step 2: 독립 분석 (CLI 분담, Anti-Herding)
+
+전문가를 3개 CLI에 분배하고, 각 CLI가 담당 전문가 관점으로 독립 분석한다. **상호 결과 비공개.**
+
+```
+Claude (Agent, background):
+  "당신은 {expert_1.name}({expert_1.role})과 {expert_2.name}({expert_2.role})입니다.
+   주제: {topic}
+   각 전문가의 고유 관점에서 분석하세요.
+   JSON: { experts: [{ name, position, reasoning, concerns, recommendation, confidence }] }"
+
+Codex (Bash, background):
+  codex exec --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check \
+    "당신은 {expert_3.name}과 {expert_4.name}입니다. {topic}에 대해 각 전문가 관점으로..."
+
+Gemini (Bash, background):
+  gemini -y -p \
+    "당신은 {expert_5.name}과 {expert_6.name}입니다. {topic}에 대해 각 전문가 관점으로..."
+```
+
+### Step 3: 패널 토론 시뮬레이션
+
+3개 CLI 결과를 수집한 후, 전문가 간 교차 토론을 시뮬레이션한다:
+
+```
+Claude Opus가 패널 모더레이터 역할:
+
+1. 각 전문가 의견 정리 (합의점 / 분쟁점 식별)
+2. 분쟁점에 대해 가상 반론 생성:
+   "Newman은 서비스 분리를 주장하지만, Fowler는 '모놀리스 우선'을 권고합니다.
+    Newman의 반론은? Fowler의 재반론은?"
+3. 2차 라운드: 반론을 반영한 수정 의견 도출
+```
+
+### Step 4: 합의 종합
+
+```
+tfx-consensus 프로토콜 적용:
+
+전문가별 최종 입장 교차검증:
+  - 과반(50%+) 합의 → "패널 합의"
+  - 소수 의견 → "소수 견해" (근거 포함)
+  - 대립 → "미해결 쟁점" (양측 근거 병기)
+```
+
+### Step 5: 최종 패널 보고서
+
+```markdown
+## 전문가 패널 보고서: {topic}
+
+### 패널 구성
+| # | 전문가 | 역할 | 핵심 입장 |
+|---|--------|------|----------|
+| 1 | Sam Newman | 마이크로서비스 아키텍트 | 점진적 분리 찬성 |
+| 2 | Martin Fowler | 리팩터링 전문가 | 모놀리스 우선 정리 |
+| ... | ... | ... | ... |
+
+### 패널 합의 (Consensus Score: {score}%)
+- [합의 1] — {N}/{total} 합의
+- [합의 2] — {N}/{total} 합의
+
+### 소수 견해
+- {expert}: {dissenting_view} — 근거: {reason}
+
+### 핵심 추천
+{패널 종합 추천}
+
+### 리스크 및 완화 방안
+{전문가들이 식별한 리스크와 대응책}
+
+### 미해결 쟁점
+{패널 내 해소되지 않은 논쟁}
+
+### 다음 단계 (Action Items)
+1. {action_1}
+2. {action_2}
+```
+
+## 토큰 예산
+
+| 단계 | 토큰 |
+|------|------|
+| 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-persist/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: tfx-persist
+description: "작업이 완전히 끝날 때까지 멈추지 않고 반복 실행해야 할 때 사용한다. 'ralph', '끝까지 해', '멈추지 마', 'don't stop', '완료될 때까지', '다 될 때까지 계속' 같은 요청에 반드시 사용. 여러 기준을 모두 충족해야 하는 복잡한 구현 작업에 적극 활용."
+triggers:
+  - ralph
+  - don't stop
+  - 끝까지
+  - until done
+  - 멈추지 마
+argument-hint: "<완료할 작업 설명>"
+---
+
+# tfx-persist — Tri-Verified Persistence Loop
+
+> OMC ralph 오마주. 핵심 차별점: 검증자가 단일 agent가 아니라 **3-CLI consensus**.
+> The boulder never stops — but it stops being wrong.
+
+## 핵심 원리
+
+OMC ralph는 단일 verifier(code-reviewer 또는 critic)가 검증한다.
+tfx-persist는 Claude/Codex/Gemini **3자 독립 검증**으로 편향 없는 완료 판단을 보장한다.
+
+## 워크플로우
+
+### Step 1: Goal Definition
+
+```
+사용자 요청에서 완료 기준(acceptance criteria)을 추출:
+{
+  "goal": "JWT 인증 미들웨어 구현",
+  "criteria": [
+    "로그인 엔드포인트 /api/auth/login 작동",
+    "JWT 토큰 발급/검증 로직",
+    "보호된 라우트에 미들웨어 적용",
+    "refresh 토큰 지원",
+    "테스트 커버리지 80%+"
+  ]
+}
+```
+
+자동 추출된 기준을 AskUserQuestion으로 사용자에게 확인받는다:
+
+```
+AskUserQuestion:
+  "다음 완료 기준이 맞나요?"
+  {추출된 criteria 목록 표시}
+  1. 맞습니다 — 진행
+  2. 수정 필요 — 기준 편집
+  3. 추가 필요 — 기준 추가
+```
+
+- 1번 선택 → Step 2로 진행
+- 2번 선택 → 사용자가 수정할 기준 번호와 내용을 입력, 반영 후 재확인
+- 3번 선택 → 사용자가 추가 기준을 입력, 반영 후 재확인
+
+### Step 2: Execution Loop
+
+```
+WHILE (NOT all criteria verified):
+
+  2a. 현재 상태 평가
+      - 어떤 기준이 미완료인지 확인
+      - 다음 작업 결정
+
+  2b. 구현 실행
+      - 단순 작업 → Codex exec 직접 실행
+      - 복잡 작업 → tfx-auto로 분해 후 실행
+      - 파일 수정, 테스트 작성, 빌드 등
+
+  2c. 3자 독립 검증 (매 기준 완료 시)
+      Claude: "다음 기준이 충족되었는가? 코드를 직접 읽고 판단하라: {criterion}"
+      Codex:  "다음 기준 충족 여부를 코드 실행/테스트로 검증하라: {criterion}"
+      Gemini: "다음 기준 충족 여부를 코드 리뷰로 판단하라: {criterion}"
+
+      결과: 2/3 이상 "통과" → 기준 확정
+             1/3만 "통과" → 재작업 필요
+             0/3 "통과" → 즉시 재작업
+
+  2d. 진행 보고
+      "🪨 Ralph: {완료}/{전체} 기준 충족. 현재: {작업 중인 것}. 다음: {예정}"
+
+END WHILE
+```
+
+### Step 3: Final Verification
+
+모든 기준이 개별 검증을 통과한 후, 전체 통합 검증:
+
+```
+3자 독립 통합 검증:
+  "모든 acceptance criteria가 충족되었는지 전체적으로 검증하라.
+   기준 목록: {criteria}
+   코드를 직접 읽고, 테스트를 실행하고, 회귀 여부를 확인하라."
+
+Consensus Score >= 70 → 완료 선언
+Consensus Score < 70 → 미달 항목 재작업 후 재검증
+```
+
+### Step 4: Deslop Pass (선택적)
+
+검증 통과 후, 변경된 파일에 대해 슬롭 제거:
+```
+변경된 파일 목록 → 3자 독립 슬롭 감지 → 합의된 슬롭만 제거 → 회귀 검증
+```
+
+### Step 5: 완료
+
+```
+모든 기준 3자 검증 통과 + 통합 검증 통과 → 완료 보고:
+
+"🪨 Ralph 완료: {전체}/{전체} 기준 충족 (Consensus Score: {score}%)
+ 변경 파일: {count}개
+ 테스트: {pass}/{total} 통과
+ 검증: Claude ✓ Codex ✓ Gemini ✓"
+```
+
+## Anti-Stuck 메커니즘
+
+```
+같은 기준에서 3회 연속 검증 실패 시:
+  1. 접근법 변경 시도
+  2. 변경 후에도 실패 → AskUserQuestion으로 사용자 도움 요청
+  3. 사용자 지시 받은 후 재시도
+
+같은 전체 루프가 5회 반복 시:
+  → 강제 진행 상황 보고 + 사용자 판단 요청
+```
+
+## 토큰 예산
+
+기준당: ~8K (구현 ~3K + 3자검증 ~5K)
+전체: 기준 수 × 8K + 통합검증 15K
+예: 5개 기준 → ~55K tokens
+
+## 사용 예
+
+```
+/tfx-persist "JWT 인증 미들웨어 구현. 로그인, 토큰 발급/검증, 리프레시, 테스트 80%+"
+/tfx-persist "이 버그 수정해. PR #42의 모든 코멘트 해결될 때까지"
+/tfx-persist "데이터베이스 마이그레이션 완료. 기존 데이터 무손실, 롤백 가능"
+```

package/skills/tfx-plan/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: tfx-plan
+description: "구현 계획이 필요할 때 사용한다. '계획 세워줘', 'plan', '플랜', '어떻게 구현하지', '태스크 분해', '작업 순서' 같은 요청에 반드시 사용. 기능 구현 전 영향 범위 파악과 태스크 분해가 필요할 때 적극 활용."
+triggers:
+  - plan
+  - 계획
+  - 플랜
+  - 설계
+argument-hint: "<구현할 기능 설명>"
+---
+
+# tfx-plan — Light Implementation Plan
+
+> Claude Opus 단독 빠른 계획. 복잡한 합의 없이 즉시 태스크 분해.
+
+## 워크플로우
+
+### Step 1: 요구사항 파싱
+사용자 입력 + 프로젝트 컨텍스트(PROJECT_INDEX.md 있으면 활용)에서 핵심 추출.
+
+### Step 2: Claude Opus 계획 수립
+```
+"소프트웨어 아키텍트로서 다음 기능의 구현 계획을 수립하라:
+ 기능: {feature}
+ 프로젝트 컨텍스트: {context}
+
+ 출력 형식:
+ 1. 영향 범위 (수정할 파일 목록)
+ 2. 태스크 분해 (순서대로, 각 태스크에 검증 방법 포함)
+ 3. 리스크 및 의존성
+ 4. 예상 복잡도 (low/medium/high)"
+```
+
+### Step 3: 구조화된 계획 출력
+```markdown
+## 구현 계획: {feature}
+
+### 영향 범위
+- `src/auth/middleware.ts` — 신규 생성
+- `src/routes/index.ts` — 수정 (라우트 추가)
+
+### 태스크
+1. [ ] {태스크1} → 검증: {확인 방법}
+2. [ ] {태스크2} → 검증: {확인 방법}
+3. [ ] {태스크3} → 검증: {확인 방법}
+
+### 리스크
+- {리스크1}: 완화 방안 — {방안}
+
+### 복잡도: {level}
+```
+
+## 토큰: ~8K

package/skills/tfx-profile/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: tfx-profile
+description: >
+  Codex CLI 프로파일/모델 관리 인터랙티브 UI. tfx-route가 사용하는
+  프로파일 목록 조회, 모델 변경, effort 조정, 추가/삭제를 AskUserQuestion 기반
+  인터랙티브 선택지로 수행합니다.
+  Use when: codex profile, codex model, 프로파일 변경, 모델 변경, effort 변경,
+  codex 설정, profile manager, 프로파일 관리, 어떤 모델, tfx profile
+triggers:
+  - tfx-profile
+argument-hint: "[--list]"
+---
+
+# codex-profile — Codex 프로파일 매니저
+
+> Codex CLI 프로파일의 모델/effort를 AskUserQuestion 선택지로 관리합니다.
+
+## 워크플로우
+
+### Step 1: config.toml 읽기 + 현재 상태 표시
+
+`~/.codex/config.toml`을 Read 도구로 읽고 프로파일 테이블을 마크다운으로 출력한다:
+
+```
+| 프로파일 | 모델 | Effort |
+|----------|------|--------|
+| fast | gpt-5.3-codex | low |
+| ...  | ...           | ...  |
+```
+
+기본 모델(top-level `model`)과 기본 effort도 함께 표시.
+
+### Step 2: 작업 선택 (AskUserQuestion)
+
+AskUserQuestion으로 메인 메뉴를 제시한다:
+
+```
+question: "어떤 작업을 하시겠습니까?"
+header: "작업"
+options:
+  - label: "프로파일 모델 변경"
+    description: "기존 프로파일의 모델/effort를 수정"
+  - label: "기본 모델 변경"
+    description: "top-level default 모델/effort 수정"
+  - label: "프로파일 추가"
+    description: "새 프로파일 생성"
+  - label: "프로파일 삭제"
+    description: "기존 프로파일 제거"
+```
+
+### Step 3: 선택에 따른 세부 플로우
+
+#### 프로파일 모델 변경
+
+1. AskUserQuestion으로 프로파일 선택 (현재 프로파일 목록에서 2-4개씩 나눠서, 또는 "Other"로 직접 입력)
+2. AskUserQuestion으로 모델 선택:
+   ```
+   question: "모델을 선택하세요"
+   header: "Model"
+   options:
+     - label: "gpt-5.4"
+       description: "최신 플래그십"
+     - label: "gpt-5.3-codex"
+       description: "코딩 특화 (Recommended)"
+     - label: "gpt-5.1-codex-mini"
+       description: "경량 Spark"
+     - label: "o3"
+       description: "추론 특화"
+   ```
+3. AskUserQuestion으로 effort 선택:
+   ```
+   question: "Reasoning Effort 레벨을 선택하세요"
+   header: "Effort"
+   options:
+     - label: "low"
+       description: "빠른 응답, 최소 추론"
+     - label: "medium"
+       description: "균형 잡힌 추론"
+     - label: "high"
+       description: "깊은 추론"
+     - label: "xhigh"
+       description: "최대 추론 (느림)"
+   ```
+4. 변경 diff를 preview로 보여주고 Edit 도구로 config.toml 수정
+
+#### 기본 모델 변경
+
+위와 동일한 모델/effort 선택 후 top-level `model`, `model_reasoning_effort` 수정.
+
+#### 프로파일 추가
+
+1. AskUserQuestion(Other)으로 프로파일 이름 입력
+2. 모델 선택 → effort 선택
+3. config.toml 끝에 새 `[profiles.name]` 섹션 추가
+
+#### 프로파일 삭제
+
+1. 프로파일 선택
+2. AskUserQuestion 확인: "정말 삭제하시겠습니까?"
+3. 해당 섹션 제거
+
+### Step 4: 결과 확인
+
+변경된 config.toml을 다시 읽어 업데이트된 테이블 표시.
+"계속하시겠습니까?" AskUserQuestion → 반복 또는 종료.
+
+## config.toml 수정 규칙
+
+- **백업 필수**: 수정 전 원본 내용을 기억해둘 것 (rollback 가능하도록)
+- **프로파일 섹션 형식**: `[profiles.name]\nmodel = "..."\nmodel_reasoning_effort = "..."`
+- **다른 섹션 건드리지 않기**: `[notice]`, `[features]`, `[mcp_servers.*]`, `[projects.*]` 등은 절대 수정 금지
+- **Edit 도구 사용**: old_string → new_string으로 정확한 섹션만 치환
+
+## 참조
+
+### 알려진 모델
+
+| 모델 | 용도 |
+|------|------|
+| gpt-5.4 | 최신 플래그십 |
+| gpt-5.3-codex | 코딩 특화 |
+| gpt-5.1-codex-mini | 경량 Spark |
+| o3 | 추론 특화 |
+| o4-mini | 추론 경량 |
+
+### Effort 레벨
+
+| 레벨 | 설명 |
+|------|------|
+| low | 빠른 응답, 최소 추론 |
+| medium | 균형 잡힌 추론 |
+| high | 깊은 추론 |
+| xhigh | 최대 추론 (느림) |
+
+### config.toml 경로
+
+`~/.codex/config.toml` (`$HOME/.codex/config.toml`)
+
+## 에러 처리
+
+| 상황 | 처리 |
+|------|------|
+| config.toml 미존재 | `/tfx-setup` 안내 |
+| 파싱 실패 | 백업 후 수동 수정 안내 |
+| 중복 프로파일명 | 이미 존재함 알림, 기존 편집으로 전환 |
+
+## standalone TUI
+
+터미널에서 직접 실행도 가능: `node tui/codex-profile.mjs` (arrow key 방식)