triflux 8.3.0 → 8.3.1

package/skills/tfx-forge/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: tfx-forge
+description: "새 스킬을 만들거나 기존 스킬을 수정할 때 사용한다. 'forge', '스킬 만들기', 'create skill', '새 스킬', '스킬 생성', 'SKILL.md 작성' 같은 요청에 반드시 사용. 반복 작업을 스킬로 자동화하고 싶을 때 적극 활용."
+triggers:
+  - forge
+  - 스킬 만들기
+  - create skill
+  - 스킬 생성
+  - new skill
+argument-hint: "[스킬 이름 또는 설명]"
+---
+
+# tfx-forge — Skill Authoring Meta-Skill
+
+> Superpowers skill authoring 오마주. 스킬을 만드는 스킬.
+> "메타 레벨에서 자동화하라."
+
+## 용도
+
+- 새 tfx 스킬의 SKILL.md를 대화형으로 생성
+- 기존 스킬 형식과 품질 기준을 자동 준수
+- YAML frontmatter + 본문 구조를 일관되게 유지
+- 스킬 작성 시행착오 최소화
+
+## 워크플로우
+
+### Step 1: 요구사항 수집 (대화형)
+
+AskUserQuestion으로 필수 정보를 순서대로 수집한다. 사용자가 초기 입력에 일부 정보를 포함했으면 해당 항목은 건너뛴다.
+
+**먼저 스킬 유형을 선택받는다:**
+
+```
+AskUserQuestion:
+  "스킬 유형을 선택하세요:"
+  1. Light (경량, 단일 CLI, 토큰 절약)
+  2. Deep (딥, 3-CLI 합의, 정확도 우선)
+  3. Core (인프라, 다른 스킬이 내부 호출)
+```
+
+선택된 유형에 따라 이후 수집 항목과 템플릿이 달라진다:
+- **Light**: 단일 CLI 워크플로우, 낮은 토큰 예산
+- **Deep**: 3-CLI 병렬 + tfx-consensus 통합, 높은 토큰 예산
+- **Core**: 외부 호출 인터페이스 정의, 내부 API 문서화 포함
+
+**이후 나머지 정보를 순서대로 수집한다:**
+
+```
+수집 항목 (순서대로):
+
+1. 이름 (name)
+   "스킬 이름은? (예: tfx-myskill)"
+   → 접두사 'tfx-' 자동 부여 (없으면)
+
+2. 한줄 설명 (description)
+   "이 스킬이 무엇을 하는지 한 문장으로?"
+
+3. 트리거 (triggers)
+   "어떤 키워드로 이 스킬을 호출? (쉼표 구분)"
+
+4. 토큰 예산
+   "예상 토큰 예산은? (예: ~10K)"
+
+5. 핵심 워크플로우
+   "주요 단계를 간략히 설명해주세요. (3-5 단계)"
+
+6. 사용 예시
+   "사용 예시 1-3개를 알려주세요."
+```
+
+### Step 2: 기존 스킬 분석
+
+프로젝트 내 기존 SKILL.md를 참조하여 형식과 품질 기준을 확인한다:
+
+```
+Glob("skills/**/SKILL.md")로 기존 스킬 목록 수집
+→ 유사한 타입(Deep/Light)의 스킬 1-2개를 Read하여 형식 참조
+→ YAML frontmatter 구조, 본문 섹션 패턴, 토큰 예산 표 형식 추출
+```
+
+### Step 3: SKILL.md 생성
+
+수집된 정보로 SKILL.md를 자동 생성한다:
+
+```yaml
+# YAML Frontmatter 템플릿
+---
+name: {name}
+description: {description}
+triggers:
+  - {trigger_1}
+  - {trigger_2}
+  - ...
+argument-hint: "{hint}"
+---
+```
+
+```markdown
+# 본문 템플릿
+
+# {name} — {short_title}
+
+> {한줄 설명 또는 오마주}
+
+## 용도
+
+- {use_case_1}
+- {use_case_2}
+- {use_case_3}
+
+## 워크플로우
+
+### Step 1: {step_title}
+{step_description}
+
+### Step 2: {step_title}
+{step_description}
+
+...
+
+## 토큰 예산
+
+| 단계 | 토큰 |
+|------|------|
+| {step} | ~{N}K |
+| **총합** | **~{total}K** |
+
+## 사용 예
+
+```
+/{name} "{example_1}"
+/{name} "{example_2}"
+```
+```
+
+### Step 4: 디렉토리 생성 및 저장
+
+```
+mkdir -p skills/{name}/
+Write → skills/{name}/SKILL.md
+```
+
+### Step 5: 검증
+
+생성된 파일을 읽어 검증한다:
+
+```
+검증 항목:
+  - [ ] YAML frontmatter 파싱 가능
+  - [ ] name, description, triggers 필수 필드 존재
+  - [ ] 본문에 용도, 워크플로우, 토큰 예산, 사용 예 섹션 존재
+  - [ ] 파일 크기 < 800줄
+  - [ ] 기존 스킬과 트리거 충돌 없음
+```
+
+충돌 발견 시 AskUserQuestion으로 트리거 조정 요청.
+
+## 동작 규칙
+
+1. 사용자가 이름만 제공해도 나머지는 대화형으로 수집한다.
+2. 사용자가 상세 설명을 한꺼번에 제공하면 확인만 받고 즉시 생성한다.
+3. Deep 타입 선택 시 tfx-consensus 통합 포인트를 본문에 자동 포함한다.
+4. 생성 후 반드시 사용자에게 결과를 보여주고 수정 요청을 받는다.
+5. 기존 SKILL.md가 있으면 덮어쓰기 전 사용자 확인을 받는다.
+
+## 토큰 예산
+
+| 단계 | 토큰 |
+|------|------|
+| 요구사항 수집 | ~2K |
+| 기존 스킬 분석 | ~3K |
+| SKILL.md 생성 | ~3K |
+| 검증 | ~2K |
+| **총합** | **~10K** |
+
+## 사용 예
+
+```
+/tfx-forge
+/tfx-forge tfx-myskill
+/tfx-forge "CI/CD 파이프라인 자동 생성 스킬"
+/스킬 만들기 "코드 마이그레이션 도우미"
+```

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-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            # 특정 디렉토리만
+```