triflux 8.2.3 → 8.3.1

package/skills/tfx-fullcycle/SKILL.md

@@ -0,0 +1,195 @@
+---
+name: tfx-fullcycle
+description: "복잡한 기능을 처음부터 끝까지 자율 개발해야 할 때 사용한다. 'deep autopilot', '풀 오토', '처음부터 끝까지', 'full auto', '전체 파이프라인으로' 같은 요청에 사용. 설계→계획→구현→QA→검증 전체 사이클이 필요한 대규모 기능에 적극 활용."
+triggers:
+  - deep autopilot
+  - 풀 오토
+  - 처음부터 끝까지
+  - full auto
+argument-hint: "<구현할 기능 전체 설명>"
+---
+
+# tfx-fullcycle — Full Development Pipeline with Tri-CLI Consensus
+
+> 5-Phase 파이프라인: Expansion → Planning → Execution → QA → Validation.
+> OMC autopilot + Superpowers TDD + MetaGPT SOP 영감. 처음부터 끝까지 자율 실행.
+
+## 핵심 원리
+
+단순 autopilot은 "구현 → 검증" 2단계. Deep autopilot은 **계획 단계부터 3자 합의**, **구현은 분업**, **검증은 3자 독립 리뷰** — 전체 소프트웨어 개발 SOP를 자동화한다.
+
+## 용도
+
+- 신규 기능 전체 구현 (설계 → 코드 → 테스트 → 검증)
+- 대규모 리팩터링
+- 복잡한 버그 수정 (재현 → 분석 → 수정 → 회귀 검증)
+- "처음부터 끝까지 알아서 해" 류의 복합 요청
+
+## 워크플로우
+
+### Phase 1: Expansion (Claude Opus)
+
+요구사항을 분석하고 구현 범위를 확장한다:
+
+```
+Claude Opus:
+  "소프트웨어 아키텍트로서 다음 요구사항을 분석하라:
+   요구사항: {user_request}
+   프로젝트 컨텍스트: {context from PROJECT_INDEX.md}
+
+   출력:
+   1. 요구사항 해석 및 범위 정의
+   2. 영향 받는 파일/모듈 목록
+   3. 엣지 케이스 및 고려사항
+   4. 암묵적 요구사항 (사용자가 언급하지 않았지만 필요한 것)
+   5. acceptance criteria 목록 (검증 가능한 형태)"
+```
+
+모호한 점이 있으면 AskUserQuestion으로 사용자 확인.
+
+### Phase 2: Planning (3자 합의)
+
+**3개 CLI가 동시에, 상호 결과를 보지 않고 독립 계획 수립.**
+
+```
+Claude Opus (Planner, background):
+  "다음 기능의 구현 계획을 수립하라:
+   기능: {expanded_requirements}
+   태스크 분해, 순서, 의존성, TDD 전략 포함.
+   JSON: { tasks, order, dependencies, tdd_strategy, risks }"
+
+Codex (Architect, background):
+  codex exec --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check \
+  "시니어 엔지니어로서 기술적 설계를 작성하라:
+   기능: {expanded_requirements}
+   파일 구조, API 인터페이스, 데이터 모델 포함.
+   JSON: { design, file_changes, interfaces, test_plan }"
+
+Gemini (Critic, background):
+  gemini -y -p \
+  "QA 전문가로서 구현 계획의 리스크를 분석하라:
+   기능: {expanded_requirements}
+   엣지 케이스, 보안, 성능, 접근성 우려 포함.
+   JSON: { edge_cases, security_risks, performance, accessibility, test_cases }"
+```
+
+3개 결과를 tfx-consensus 프로토콜로 합의 도출:
+```
+Consensus Score >= 70 → Phase 3 진행
+Consensus Score < 70 → Round 2 교차검토 → 재합의
+Round 2 후에도 < 60 → 사용자에게 불일치 제시 + 방향 결정 요청
+```
+
+### Phase 3: Execution (Codex + Gemini 분업)
+
+합의된 계획에 따라 태스크를 병렬 실행:
+
+```
+태스크 라우팅:
+  코드 구현/수정 → Codex exec --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check
+  테스트 작성 → Codex (TDD: 테스트 먼저 → RED 확인 → 구현 → GREEN)
+  UI/문서 → Gemini -y -p
+
+실행 순서:
+  1. 테스트 먼저 작성 (TDD RED phase)
+  2. 구현 코드 작성 (TDD GREEN phase)
+  3. 리팩터링 (TDD REFACTOR phase)
+  4. 통합 테스트 실행
+
+병렬 가능 태스크는 동시 실행:
+  독립 모듈 A (Codex pane 1) | 독립 모듈 B (Codex pane 2) | 문서 (Gemini)
+```
+
+각 태스크 완료 시 단순 검증 (테스트 통과 여부) 확인 후 다음 진행.
+
+### Phase 4: QA (3자 독립 리뷰)
+
+**전체 변경사항에 대해 3개 CLI가 독립 리뷰한다.**
+
+```
+Claude (기능 + 엣지케이스, background):
+  "다음 변경사항이 acceptance criteria를 충족하는지 검증하라:
+   criteria: {acceptance_criteria}
+   변경 파일: {changed_files}
+   각 criterion별 PASS/FAIL + 근거.
+   엣지 케이스 테스트 시나리오 제안.
+   JSON: { criteria_results, edge_case_findings, overall_pass }"
+
+Codex (보안 + 성능, background):
+  codex exec review --profile thorough \
+    --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check \
+  "보안/성능 관점에서 변경사항을 리뷰하라:
+   OWASP Top 10, 성능 병목, 에러 핸들링, 리소스 누수 확인.
+   JSON: { security_findings, performance_findings, overall_pass }"
+
+Gemini (UX + 접근성, background):
+  gemini -y -p \
+  "UX/접근성 관점에서 변경사항을 리뷰하라:
+   UI 변경 있으면: 접근성, 반응형, 사용성.
+   API 변경 있으면: DX, 문서화, 일관성.
+   JSON: { ux_findings, accessibility_findings, overall_pass }"
+```
+
+### Phase 5: Validation (Consensus >= 70)
+
+Phase 4 결과에 tfx-consensus 프로토콜 적용:
+
+```
+Consensus 판정:
+  Score >= 70 + Critical 0건 → 완료 확정
+  Score >= 70 + Critical 존재 → Critical만 수정 후 재검증
+  Score < 70 → 미합의 항목 수정 → Phase 4 재실행 (최대 2회)
+  2회 재실행 후에도 < 70 → 사용자에게 보고 + 판단 요청
+```
+
+### Final: 완료 보고
+
+```markdown
+# Deep Autopilot 완료: {feature}
+
+## Pipeline Summary
+| Phase | 상태 | 소요 |
+|-------|------|------|
+| Expansion | ✓ | {criteria_count}개 기준 도출 |
+| Planning | ✓ | Consensus {score}% (Round {n}) |
+| Execution | ✓ | {task_count}개 태스크, {file_count}개 파일 변경 |
+| QA | ✓ | 3자 독립 리뷰 완료 |
+| Validation | ✓ | Consensus {score}%, Critical 0건 |
+
+## 변경 사항
+| 파일 | 작업 | 설명 |
+|------|------|------|
+| {file} | 생성/수정 | {summary} |
+
+## Acceptance Criteria
+- [x] {criterion1} — 3/3 PASS
+- [x] {criterion2} — 2/3 PASS (Gemini: 조건부)
+
+## QA 결과
+- 보안: {findings_count}건 (모두 해결)
+- 성능: {findings_count}건 (모두 해결)
+- 테스트: {pass}/{total} 통과
+
+## 미합의 사항 (있으면)
+- {항목}: {각 CLI 입장}
+```
+
+## 토큰 예산
+
+| Phase | 토큰 |
+|-------|------|
+| Phase 1 (Expansion) | ~5K |
+| Phase 2 (Planning, 3x) | ~20K |
+| Phase 3 (Execution) | ~25K |
+| Phase 4 (QA, 3x) | ~18K |
+| Phase 5 (Validation) | ~5K |
+| 재시도 (필요 시) | +15K |
+| **총합** | **~73-88K** |
+
+## 사용 예
+
+```
+/tfx-fullcycle "JWT 인증 시스템 전체 구현. 로그인/로그아웃/리프레시/미들웨어/테스트"
+/tfx-fullcycle "풀 오토 — 결제 모듈을 Stripe에서 Toss Payments로 마이그레이션"
+/tfx-fullcycle "처음부터 끝까지 — REST API를 GraphQL로 점진적 전환, 기존 클라이언트 호환 유지"
+```

package/skills/tfx-hub/SKILL.md

@@ -36,7 +36,7 @@ Bash("bash ~/.claude/scripts/tfx-route.sh {에이전트} '{hub 컨텍스트 +
 
 # codex 직접 호출 시 — 반드시 exec 서브커맨드 포함
 Bash("codex exec --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check '{작업}'")
-Bash("codex --profile xhigh exec --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check '{작업}'")
+Bash("codex --profile gpt54_xhigh exec --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check '{작업}'")
 #          ↑ --profile은 exec 앞에, --skip-git-repo-check은 exec 뒤에
 
 # Claude 네이티브 (탐색/검증)

package/skills/tfx-index/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: tfx-index
+description: "프로젝트 구조를 빠르게 파악하거나 토큰을 절약할 때 사용한다. '인덱싱', '프로젝트 구조', '인덱스 만들어', '코드베이스 맵', '프로젝트 개요' 같은 요청에 사용. 새 프로젝트 온보딩, 세션 시작 시 컨텍스트 효율화에 적극 활용."
+triggers:
+  - 인덱싱
+  - 프로젝트 인덱스
+  - 인덱스
+  - tfx-index
+argument-hint: "[--update] [경로]"
+---
+
+# tfx-index — Project Indexing (94% Token Reduction)
+
+> SuperClaude index-repo 오마주. 1회 2K 토큰으로 인덱스 생성, 이후 세션마다 55K 토큰 절감.
+
+## 원리
+
+매 세션마다 프로젝트 구조를 파악하려면 수십 개 파일을 읽어야 한다 (~58K tokens).
+인덱스를 한 번 생성하면 3K 토큰짜리 PROJECT_INDEX.md만 읽으면 된다.
+
+**ROI**: 1회 투자 2K → 세션당 55K 절감 → 10세션이면 550K 절감
+
+## 워크플로우
+
+### Step 0: 인덱싱 모드 선택
+
+인자 없이 호출되거나 모드가 불명확한 경우, AskUserQuestion으로 모드를 선택받는다:
+
+```
+AskUserQuestion:
+  "인덱싱 모드를 선택하세요:"
+  1. 전체 인덱스 생성 (처음 또는 재생성)
+  2. 증분 업데이트 (변경분만)
+  3. 특정 디렉토리만
+```
+
+- 1번 선택 → Step 1부터 전체 실행
+- 2번 선택 → `--update` 모드로 전환 (기존 인덱스 필요, 없으면 1번으로 fallback)
+- 3번 선택 → 추가 AskUserQuestion으로 대상 디렉토리 경로 입력받음
+
+`--update` 플래그나 경로 인자가 이미 제공된 경우 이 단계를 건너뛴다.
+
+### Step 1: 파일 트리 스캔
+
+```
+병렬 Glob으로 전체 파일 트리 수집:
+  - **/*.{ts,js,mjs,tsx,jsx,py,go,rs,java} (소스)
+  - **/*.{md,json,yaml,toml} (설정/문서)
+  - **/package.json, **/tsconfig.json (프로젝트 메타)
+
+제외:
+  - node_modules/, .git/, dist/, build/, coverage/
+  - *.lock, *.log, *.map
+```
+
+### Step 2: 메타데이터 추출 (병렬)
+
+각 소스 파일에서 핵심 메타데이터만 추출 (전체 읽기 금지):
+
+```
+파일당 추출 항목:
+  - exports (함수, 클래스, 상수 이름)
+  - imports (의존성)
+  - 파일 크기 (라인 수)
+  - 주요 패턴 (테스트? 설정? 컴포넌트? 유틸?)
+
+추출 방법:
+  - Grep으로 export/import 문 추출 (파일당 ~20줄만)
+  - 전체 파일을 읽지 않음 → 토큰 절약
+```
+
+### Step 3: 인덱스 생성
+
+```markdown
+# PROJECT_INDEX.md
+Generated: {date} | Files: {count} | Lines: {total_lines}
+
+## Architecture
+{1-2줄 아키텍처 요약}
+
+## Directory Map
+```
+src/
+  ├─ hub/          # MCP 메시지 버스 (bridge, router, pipe)
+  │   ├─ team/     # 멀티-CLI 팀 모드 (headless, psmux, native)
+  │   └─ pipeline/ # 상태 관리 (state, transitions, gates)
+  ├─ skills/       # 스킬 정의 (tfx-*, SKILL.md)
+  └─ bin/          # CLI 진입점
+```
+
+## Key Files
+| File | Lines | Exports | Role |
+|------|-------|---------|------|
+| hub/bridge.mjs | 850 | BridgeServer, createBridge | MCP 프로토콜 브릿지 |
+| hub/router.mjs | 720 | Router, routeRequest | 요청/응답 라우팅 |
+| ... | ... | ... | ... |
+
+## Dependencies
+| Package | Version | Purpose |
+|---------|---------|---------|
+| express | 4.x | HTTP 서버 |
+| ... | ... | ... |
+
+## Entry Points
+- `bin/tfx` → CLI 메인
+- `hub/bridge.mjs` → MCP 서버
+- `skills/*/SKILL.md` → 스킬 정의
+```
+
+### Step 4: JSON 인덱스 (기계용)
+
+```json
+// PROJECT_INDEX.json (~10KB)
+{
+  "generated": "2026-03-29",
+  "stats": { "files": 45, "lines": 12500 },
+  "files": {
+    "hub/bridge.mjs": {
+      "lines": 850,
+      "exports": ["BridgeServer", "createBridge"],
+      "imports": ["express", "./router"],
+      "type": "server"
+    }
+  },
+  "graph": {
+    "hub/bridge.mjs": ["hub/router.mjs", "hub/pipe.mjs"],
+    "hub/router.mjs": ["hub/intent.mjs"]
+  }
+}
+```
+
+### Step 5: 검증
+
+```
+생성된 인덱스 검증:
+  - 파일 수 일치 확인
+  - 주요 진입점 포함 확인
+  - 인덱스 크기 < 5KB 확인
+```
+
+## --update 모드
+
+기존 인덱스가 있으면 git diff 기반 증분 업데이트:
+
+```
+변경된 파일만 재스캔 → 인덱스 부분 갱신
+신규 파일 추가, 삭제된 파일 제거
+전체 재생성 대비 ~80% 시간 절감
+```
+
+## 출력 위치
+
+```
+{project_root}/
+  PROJECT_INDEX.md    ← 사람용 (3KB)
+  PROJECT_INDEX.json  ← 기계용 (10KB)
+```
+
+## 토큰 예산
+
+| 작업 | 토큰 |
+|------|------|
+| 스캔+추출 | ~1.5K |
+| 인덱스 생성 | ~0.5K |
+| **총합** | **~2K** |
+| **세션당 절감** | **~55K** |
+
+## 사용 예
+
+```
+/tfx-index                    # 전체 인덱스 생성
+/tfx-index --update           # 증분 업데이트
+/tfx-index src/hub            # 특정 디렉토리만
+```

package/skills/tfx-interview/SKILL.md

@@ -0,0 +1,210 @@
+---
+name: tfx-interview
+description: "요구사항이 모호하거나 구현 전 명확화가 필요할 때 사용한다. 'interview', '인터뷰', '요구사항 정리', '뭘 만들어야 하는지 모르겠어', '명확하게 해줘' 같은 요청에 반드시 사용. 구현 시작 전 스펙을 확정하고 싶을 때 적극 활용."
+triggers:
+  - interview
+  - 인터뷰
+  - 요구사항 탐색
+  - tfx-interview
+  - 모호성 분석
+argument-hint: "<구현할 주제 또는 요구사항>"
+---
+
+# tfx-interview — Quantified Socratic Requirements Exploration
+
+> OMC deep-interview + ouroboros 오마주. 모호성을 숫자로 측정하고 20% 미만까지 질문한다.
+> "측정할 수 없으면 개선할 수 없다."
+
+## 용도
+
+- 구현 전 요구사항 명확화
+- 모호한 요청을 정량적으로 분석하여 실행 가능한 수준으로 구체화
+- 빠진 제약 조건, 성공 기준, 경계 조건을 체계적으로 발견
+- 과잉 구현/과소 구현 방지
+
+## 핵심: 모호성 점수 (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: 초기 모호성 평가
+
+사용자 입력을 분석하여 초기 ambiguity score를 계산한다:
+
+```
+입력 분석:
+  1. goal, constraints, criteria 각 요소의 현재 명확도 평가
+  2. ambiguity score 계산
+  3. 가장 불명확한 요소 식별 → 해당 단계부터 질문 시작
+
+출력:
+  "📊 현재 모호성: 71%
+   - 목표: 50% 명확 (어떤 인증 방식?)
+   - 제약: 20% 명확 (기술 스택 미정)
+   - 기준: 10% 명확 (완료 조건 없음)
+   → Stage 1: Clarify부터 시작합니다."
+```
+
+### Step 2: 5단계 인터뷰 (모호성 < 20%까지)
+
+각 단계에서 AskUserQuestion으로 질문하고, 응답 후 ambiguity score를 재계산한다.
+
+#### Stage 1: Clarify (명확화) — goal 개선
+
+```
+질문 방향:
+  - "정확히 무엇을 달성하려는가?"
+  - "이 작업의 범위는 어디까지인가?"
+  - "완료 후 어떤 상태가 되어야 하는가?"
+
+응답 후: goal 점수 재평가 → ambiguity 재계산
+```
+
+#### Stage 2: Decompose (분해) — constraints 개선
+
+```
+질문 방향:
+  - "이것을 어떤 하위 문제로 나눌 수 있는가?"
+  - "기술적 제약 조건은? (스택, 호환성, 성능)"
+  - "의존하는 외부 시스템이나 API는?"
+
+응답 후: constraints 점수 재평가 → ambiguity 재계산
+```
+
+#### Stage 3: Challenge (반론) — 숨은 제약 발견
+
+```
+질문 방향:
+  - "이 접근의 약점은?"
+  - "실패할 수 있는 시나리오는?"
+  - "6개월 후 유지보수 관점에서 문제될 부분은?"
+
+응답 후: constraints + criteria 재평가 → ambiguity 재계산
+```
+
+#### Stage 4: Alternatives (대안) — criteria 정밀화
+
+```
+질문 방향:
+  - "다른 방법은 없는가?"
+  - "시간이 절반이라면 어떤 방식을 택하겠는가?"
+  - "각 대안의 trade-off는?"
+
+응답 후: criteria 점수 재평가 → ambiguity 재계산
+```
+
+#### Stage 5: Synthesize (종합) — 최종 확인
+
+```
+질문 방향:
+  - "지금까지의 논의를 종합하면 최적 경로는?"
+  - "첫 번째로 실행할 단계는?"
+  - "이 결정에 대한 확신도는? (1-10)"
+
+응답 후: 전체 재평가 → 최종 ambiguity score
+```
+
+### Step 3: 조기 종료 판단
+
+매 질문 후 ambiguity를 재계산하고, < 20%이면 남은 단계를 건너뛰고 종합 단계로 이동한다:
+
+```
+질문 후 재계산:
+  if ambiguity < 0.20:
+    → "📊 모호성 {score}% — 충분히 명확합니다. 종합 단계로 이동합니다."
+    → Step 4로 직행
+  elif ambiguity < 0.40:
+    → "📊 모호성 {score}% — 거의 명확합니다. 핵심 질문 1-2개만 더."
+  else:
+    → 다음 단계 진행
+```
+
+### Step 4: 산출물 생성
+
+인터뷰 결과를 구조화된 문서로 저장한다:
+
+```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. ...
+```
+
+저장 위치: `.omc/plans/interview-{timestamp}.md`
+
+## 동작 규칙
+
+1. 각 단계에서 반드시 사용자 응답을 수집한 후 다음으로 이동한다.
+2. 매 응답 후 ambiguity score를 재계산하여 진행률을 표시한다.
+3. ambiguity < 20%이면 남은 단계를 건너뛰어도 된다.
+4. 5단계를 모두 거쳐도 ambiguity >= 20%이면 추가 질문 라운드를 진행한다 (최대 2회).
+5. 인터뷰 시작 시 코드베이스를 탐색하여 관련 컨텍스트를 확보한다.
+6. 이전 단계 답변을 다음 단계 질문에 반영한다 (대화형 연결).
+
+## 토큰 예산
+
+| 단계 | 토큰 |
+|------|------|
+| 초기 평가 | ~1K |
+| 5단계 인터뷰 (질문+분석) | ~10K |
+| 산출물 생성 | ~2K |
+| 코드베이스 탐색 | ~2K |
+| **총합** | **~15K** |
+
+## 사용 예
+
+```
+/tfx-interview "인증 시스템 리팩터링"
+/tfx-interview "실시간 알림 기능 추가"
+/요구사항 분석 "데이터 파이프라인 설계"
+/인터뷰 "레거시 API를 REST에서 GraphQL로 마이그레이션"
+```