triflux 10.0.0-alpha.2 → 10.0.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "triflux",
-  "version": "10.0.0-alpha.2",
+  "version": "10.0.0",
   "description": "CLI-first multi-model orchestrator for Claude Code — route tasks to Codex, Gemini, and Claude",
   "type": "module",
   "bin": {

package/skills/merge-worktree/SKILL.md.tmpl

@@ -0,0 +1,144 @@
+---
+name: merge-worktree
+description: "워크트리 브랜치를 main으로 squash-merge + conventional commit 자동 생성. codex-swarm 워크트리 자동 인식. '머지해', 'merge worktree', '워크트리 머지', '결과 수집', 'squash merge' 요청에 사용."
+argument-hint: "[target-branch]"
+disable-model-invocation: true
+---
+
+# Merge Worktree
+
+워크트리 브랜치를 대상 브랜치로 squash-merge하고 conventional commit 메시지를 자동 작성한다.
+
+## Current context
+
+* Git dir: `!git rev-parse --git-dir`
+* Current branch: `!git branch --show-current`
+* Recent commits: `!git log --oneline -20`
+* Working tree status: `!git status --short`
+
+## Instructions
+
+### Phase 1: Validation
+
+1. **Worktree 확인**: `git rev-parse --git-dir` 출력에 `/worktrees/`가 포함되어야 한다. 아니면 중지.
+
+2. **현재 브랜치 확인**: `git branch --show-current`
+
+3. **대상 브랜치 결정**:
+   * `$ARGUMENTS`가 있으면 해당 브랜치 사용
+   * 없으면 `main` 존재 확인, 없으면 `master`
+
+4. **원본 레포 경로 확인**: `git rev-parse --git-common-dir`의 부모 디렉토리
+
+5. **클린 상태 확인**: `git status --porcelain`이 비어있어야 한다. 미커밋 변경이 있으면 먼저 커밋/스태시 안내.
+
+### Phase 2: Research
+
+1. **커밋 이력**: `git log --oneline <target>..HEAD`
+
+2. **변경 파일 요약**: `git diff <target>...HEAD --stat`
+
+3. **전체 diff**: `git diff <target>...HEAD` — 꼼꼼히 읽는다.
+
+4. **핵심 파일 읽기**: 가장 큰 변경, 신규 파일, 삭제 파일을 Read로 확인.
+
+5. **변경 분류**:
+   * Features (신규 기능)
+   * Fixes (버그 수정)
+   * Refactors (구조 변경)
+   * Tests (테스트)
+   * Docs (문서)
+   * Config/Chore (빌드, CI, 의존성)
+
+6. **dominant type 결정**: `feat`, `fix`, `refactor`, `docs`, `chore`, `test` 중 하나
+
+### Phase 3: 대상 브랜치 준비
+
+1. **대상 브랜치 최근 커밋 확인**: `git -C <원본레포> log --oneline -10 <target>`
+
+2. **WIP 커밋 감지**: `wip:`, `auto-commit`, `WIP` 시작 커밋이 있으면 사용자에게 경고.
+
+3. **최신 fetch**: `git -C <원본레포> fetch origin <target> 2>/dev/null`
+
+### Phase 4: Squash Merge
+
+1. **대상 브랜치 checkout**:
+   ```
+   git -C <원본레포> checkout <target>
+   ```
+
+2. **squash merge 실행**:
+   ```
+   git -C <원본레포> merge --squash <워크트리브랜치>
+   ```
+
+3. **충돌 처리**: 충돌 발생 시 충돌 파일 목록 + 마커를 보여주고 **중지**. 자동 해결 시도 금지.
+
+### Phase 5: 커밋 메시지 작성 + 커밋
+
+Phase 2 분석 기반으로 아래 구조의 커밋 메시지를 작성한다:
+
+```
+<type>: <명령형 요약, 72자 이내, 마침표 없음>
+
+<무엇을 왜 했는지 2-4문장. 동기와 접근 방식 중심.>
+
+Changes:
+* <그룹별 변경 사항>
+* <하위 항목은 서브 불릿>
+```
+
+**규칙:**
+* `<type>`은 `feat`, `fix`, `refactor`, `docs`, `chore`, `test` 중 하나
+* 여러 유형이 섞이면 dominant 사용
+* 요약: 명령형 ("add", "fix", "refactor"), 마침표 없음, 72자 제한
+* 본문: *왜*와 *맥락*, *무엇*만이 아님
+* Changes: 관련 항목 그룹핑, 중요한 것 먼저
+* Co-Authored-By 푸터 **절대 추가 금지** (글로벌 설정 `includeCoAuthoredBy: false`)
+
+**커밋 실행**:
+```bash
+git -C <원본레포> commit -m "$(cat <<'EOF'
+<커밋 메시지>
+EOF
+)"
+```
+
+### Phase 6: 정리 + 검증
+
+1. **커밋 확인**: `git -C <원본레포> log --oneline -3`
+
+2. **워크트리 자동 정리**:
+   ```bash
+   git -C <원본레포> worktree remove <워크트리경로>
+   git -C <원본레포> branch -d <워크트리브랜치>
+   ```
+
+3. **codex-swarm 정리 감지**: 워크트리 경로가 `.codex-swarm/wt-*` 패턴이면:
+   * 같은 `.codex-swarm/` 디렉토리에 다른 워크트리가 남아있는지 확인
+   * 모든 워크트리가 머지 완료되었으면 `.codex-swarm/` 전체 정리 제안
+   * `git worktree prune` 실행
+
+4. **결과 보고**:
+   * 커밋 해시 + 요약
+   * 머지 대상 브랜치
+   * 워크트리 정리 완료 여부
+   * push 안내 (`git push`)
+
+## codex-swarm 연동
+
+이 스킬은 `tfx-codex-swarm`의 Step 10 "결과 수집"에서 자동으로 호출된다.
+codex-swarm이 완료한 각 워크트리에 대해 순차적으로 실행:
+
+```
+각 워크트리에 대해:
+  1. 워크트리로 cd
+  2. /merge-worktree main
+  3. 다음 워크트리로 이동
+```
+
+## 주의사항
+
+* force-push, destructive 연산은 사용자 확인 없이 절대 실행 금지
+* pre-commit hook 건너뛰기(`--no-verify`) 금지
+* 예상치 못한 상황이면 추측하지 말고 **중지 후 설명**

package/skills/shared/arguments-processing.md

@@ -0,0 +1,2 @@
+> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
+> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.

package/skills/shared/mandatory-rules.md

@@ -0,0 +1,6 @@
+> headless-guard가 이 규칙 위반을 **자동 차단**한다. 우회 불가.
+
+1. **`codex exec` / `gemini -p` 직접 호출 절대 금지**
+2. Codex·Gemini 작업은 직접 CLI 대신 반드시 TFX 래퍼(이 계열 스킬에서는 `Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'cli:프롬프트:역할' --timeout 600")`)로만 실행
+3. Claude 작업은 `Agent(run_in_background=true)`
+4. 교차 검토/병렬 단계에서는 Bash + Agent를 같은 메시지에서 동시 호출

package/skills/shared/telemetry-segment.md

@@ -0,0 +1,6 @@
+> **Telemetry**
+>
+> - Skill: `{{SKILL_NAME}}`
+> - Description: `{{SKILL_DESCRIPTION}}`
+> - Session: 요청별 식별자를 유지해 단계별 실행 로그를 추적한다.
+> - Errors: 실패 시 원인/복구/재시도 여부를 구조화해 기록한다.

package/skills/star-prompt/SKILL.md.tmpl

@@ -0,0 +1,122 @@
+---
+name: star-prompt
+description: >-
+  CLI 프로젝트의 setup/postinstall 흐름에 GitHub 스타 요청 프롬프트를 추가한다.
+  gh CLI 인증 확인 → 이미 스타 여부 감지 → 인터랙티브 confirm → gh API로 자동 스타.
+  Apple 스타일 UX 카피 포함. 'star prompt', '스타 요청', '리포 스타', 'star request',
+  '깃헙 스타 넣어줘', 'star 눌러달라고', '응원 요청' 같은 요청에 사용한다.
+---
+
+# tfx-star-prompt — GitHub Star Request Prompt
+
+CLI 도구의 setup 완료 시점에 GitHub 리포 스타를 요청하는 프롬프트를 추가한다.
+사용자 경험을 해치지 않으면서, 이미 스타한 사용자에겐 감사를 표하고, 아직 안 한 사용자에겐 부담 없이 한 번 물어본다.
+
+## 동작 흐름
+
+```
+gh auth status ─── 실패 → URL만 표시 (비인터랙티브 폴백)
+       │
+       ✓ 인증됨
+       │
+gh api user/starred/{owner}/{repo} ─── 성공 → "이미 함께하고 계시군요. ⭐"
+       │
+       ✗ 미스타
+       │
+confirm("⭐ 하나가 큰 차이를 만듭니다.") ─── N → URL 조용히 표시
+       │
+       Y
+       │
+gh api -X PUT /user/starred/{owner}/{repo} → "함께해 주셔서 감사합니다. ⭐"
+       │
+       실패 → URL 폴백
+```
+
+## 구현 패턴
+
+### 인터랙티브 (TUI / readline confirm)
+
+setup 위저드 완료 후 호출. `confirm()` 으로 Y/n 입력 받고 `gh api`로 자동 스타.
+
+```javascript
+async function starRequest() {
+  let ghOk = false;
+  try {
+    execFileSync("gh", ["auth", "status"], {
+      timeout: 5000, encoding: "utf8", stdio: ["pipe", "pipe", "pipe"],
+    });
+    ghOk = true;
+  } catch {}
+
+  if (!ghOk) {
+    // gh 미설치/미인증 — URL만 표시
+    info(`⭐ 하나가 큰 차이를 만듭니다. https://github.com/{owner}/{repo}`);
+    return;
+  }
+
+  let alreadyStarred = false;
+  try {
+    execFileSync("gh", ["api", "user/starred/{owner}/{repo}"], {
+      timeout: 5000, encoding: "utf8", stdio: ["pipe", "pipe", "pipe"],
+    });
+    alreadyStarred = true;
+  } catch {}
+
+  if (alreadyStarred) {
+    ok(`이미 함께하고 계시군요. ⭐`);
+    return;
+  }
+
+  if (await confirm(`⭐ 하나가 큰 차이를 만듭니다.`, true)) {
+    try {
+      execFileSync("gh", ["api", "-X", "PUT", "/user/starred/{owner}/{repo}"], {
+        timeout: 5000, stdio: ["pipe", "pipe", "pipe"],
+      });
+      ok(`함께해 주셔서 감사합니다. ⭐`);
+    } catch {
+      info(`https://github.com/{owner}/{repo}`);
+    }
+  } else {
+    // 거절 시 URL만 조용히
+    console.log(`     https://github.com/{owner}/{repo}`);
+  }
+}
+```
+
+### 비인터랙티브 (postinstall / CLI banner)
+
+confirm 불가한 환경. 이미 스타 여부만 감지하고 메시지 분기.
+
+```javascript
+try {
+  execFileSync("gh", ["auth", "status"], { timeout: 5000, stdio: ["pipe","pipe","pipe"] });
+  try {
+    execFileSync("gh", ["api", "user/starred/{owner}/{repo}"], { timeout: 5000, stdio: ["pipe","pipe","pipe"] });
+    ok(`이미 함께하고 계시군요. ⭐`);
+  } catch {
+    info(`⭐ 하나가 큰 차이를 만듭니다. https://github.com/{owner}/{repo}`);
+  }
+} catch {
+  info(`⭐ 하나가 큰 차이를 만듭니다. https://github.com/{owner}/{repo}`);
+}
+```
+
+## 적용 시 규칙
+
+1. `{owner}/{repo}`를 대상 리포로 치환한다
+2. 프로젝트의 기존 ANSI 컬러 상수(AMBER, CYAN, RESET 등)를 사용한다
+3. setup 완료 직후, 최종 요약 다음에 호출한다 — 핵심 설정 흐름을 방해하지 않는다
+4. 모든 gh 호출은 `timeout: 5000`, `stdio: ["pipe","pipe","pipe"]`로 감싸서 실패해도 setup을 블로킹하지 않는다
+5. 거절 시 죄책감을 주지 않는다 — URL만 조용히 남긴다
+
+## UX 카피 톤
+
+Apple 스타일: 짧고, 자신감 있고, 부담 없이.
+
+| 상황 | 멘트 |
+|------|------|
+| 이미 스타 | `이미 함께하고 계시군요. ⭐` |
+| 요청 | `⭐ 하나가 큰 차이를 만듭니다.` |
+| 수락 후 | `함께해 주셔서 감사합니다. ⭐` |
+| 거절 | URL만 |
+| gh 없음 | `⭐ 하나가 큰 차이를 만듭니다.` + URL |

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

@@ -0,0 +1,106 @@
+---
+name: tfx-analysis
+description: "코드나 아키텍처를 분석해야 할 때 사용한다. '코드 분석', 'code analysis', '아키텍처 분석', '이 코드 어떻게 돌아가?', '구조 파악' 같은 요청에 반드시 사용. 코드 품질, 보안, 성능, 복잡도 분석이 필요한 모든 상황에 적극 활용."
+triggers:
+  - 코드 분석
+  - code analysis
+  - 아키텍처 분석
+  - analysis
+argument-hint: "<분석 대상 — 파일, 디렉토리, 또는 주제>"
+---
+
+# tfx-analysis — Light Code Analysis
+
+> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
+> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
+
+
+> **Deep 버전**: tfx-deep-analysis. "제대로/꼼꼼히" 수정자로 자동 에스컬레이션.
+> Codex 단일 분석으로 빠른 인사이트. SuperClaude sc:analyze 영감.
+
+## 용도
+
+- 코드 품질 빠른 점검
+- 모듈/파일 구조 분석
+- 의존성 관계 파악
+- 성능 병목 후보 식별
+- 기술 부채 탐지
+- "이 코드 어떤 상태야?" 류의 질문
+
+## 워크플로우
+
+### Step 1: 분석 대상 식별
+
+```
+우선순위:
+  1. 사용자가 파일/디렉토리 지정 → 해당 범위
+  2. 사용자가 주제 지정 (예: "인증 모듈") → 관련 파일 탐색
+  3. 지정 없음 → 프로젝트 전체 고수준 분석
+
+분석 유형 자동 감지:
+  파일 1개 → 코드 품질 + 로직 분석
+  디렉토리 → 구조 + 의존성 + 모듈 분석
+  프로젝트 전체 → 아키텍처 + 기술 부채 분석
+```
+
+### Step 2: Codex 분석 실행
+
+```bash
+bash ~/.claude/scripts/tfx-route.sh codex \
+  "시니어 소프트웨어 엔지니어로서 다음을 분석하라:
+   대상: {target}
+   유형: {analysis_type}
+
+   분석 항목:
+   1. 구조 — 파일/모듈 구성, 계층, 의존성 방향
+   2. 복잡도 — 순환 복잡도 높은 함수, 깊은 중첩
+   3. 품질 — SOLID 위반, 코드 냄새, 중복
+   4. 성능 — O(n²) 패턴, 불필요한 연산, 캐싱 부재
+   5. 기술 부채 — TODO/FIXME, deprecated API, 하드코딩
+   6. 테스트 — 커버리지 추정, 테스트 부재 영역
+
+   구조화된 보고서로 출력하라." analyze
+```
+
+### Step 3: 결과 포맷
+
+```markdown
+## 분석 결과: {target}
+
+### 구조 개요
+{파일/모듈 구조 요약 또는 의존성 다이어그램}
+
+### 주요 발견
+| # | 카테고리 | 심각도 | 설명 | 위치 |
+|---|---------|--------|------|------|
+| 1 | 복잡도 | high | {설명} | `{file}:{line}` |
+| 2 | 성능 | medium | {설명} | `{file}:{line}` |
+
+### 메트릭
+- 파일 수: {n} | 총 라인: {n}
+- 평균 복잡도: {n} | 최대 복잡도: {n} (`{file}:{function}`)
+- TODO/FIXME: {n}개
+- 테스트 커버리지 추정: {n}%
+
+### 개선 권장사항
+1. **{우선순위 1}** — {구체적 제안}
+2. **{우선순위 2}** — {구체적 제안}
+3. **{우선순위 3}** — {구체적 제안}
+```
+
+## 토큰 예산
+
+| 단계 | 토큰 |
+|------|------|
+| Step 1 (식별) | ~500 |
+| Step 2 (Codex 분석) | ~5K |
+| Step 3 (포맷) | ~2K |
+| **총합** | **~8K** |
+
+## 사용 예
+
+```
+/tfx-analysis "src/auth/"
+/tfx-analysis "이 프로젝트 전체 아키텍처 분석"
+/tfx-analysis "src/utils/parser.ts 코드 품질"
+```

package/skills/tfx-analysis/skill.json

@@ -0,0 +1,11 @@
+{
+  "name": "tfx-analysis",
+  "description": "코드나 아키텍처를 분석해야 할 때 사용한다. '코드 분석', 'code analysis', '아키텍처 분석', '이 코드 어떻게 돌아가?', '구조 파악' 같은 요청에 반드시 사용. 코드 품질, 보안, 성능, 복잡도 분석이 필요한 모든 상황에 적극 활용.",
+  "triggers": [
+    "코드 분석",
+    "code analysis",
+    "아키텍처 분석",
+    "analysis"
+  ],
+  "argument_hint": "<분석 대상 — 파일, 디렉토리, 또는 주제>"
+}

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

@@ -27,9 +27,10 @@ triggers:
 argument-hint: "<command|task> [args...]"
 ---
 
-# {{SKILL_NAME}} — 통합 CLI 오케스트레이터
+# tfx-auto — 통합 CLI 오케스트레이터
 
-{{> base}}
+> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
+> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
 
 
 > **MANDATORY RULES**

package/skills/tfx-auto/skill.json

@@ -0,0 +1,26 @@
+{
+  "name": "tfx-auto",
+  "description": "통합 CLI 오케스트레이터. 커맨드 숏컷(단일) + 자동 분류/분해(병렬) + 수동 병렬. tfx-route.sh 기반. '코드 짜줘', '구현해줘', '만들어줘', '수정해줘', '고쳐줘', 'implement', 'build', 'fix' 같은 구현/수정 요청에 사용. CLI 라우팅이 필요한 모든 작업에 적극 활용.",
+  "triggers": [
+    "tfx-auto",
+    "implement",
+    "build",
+    "research",
+    "brainstorm",
+    "design",
+    "test",
+    "analyze",
+    "troubleshoot",
+    "improve",
+    "cleanup",
+    "explain",
+    "document",
+    "pm",
+    "reflect",
+    "estimate",
+    "spec-panel",
+    "business-panel",
+    "index-repo"
+  ],
+  "argument_hint": "<command|task> [args...]"
+}

package/skills/{tfx-workspace/skill-snapshot/tfx-auto-codex/SKILL.md → tfx-auto-codex/SKILL.md.tmpl}

@@ -1,6 +1,8 @@
 ---
 name: tfx-auto-codex
-description: Codex 리드형 tfx-auto. Claude 네이티브 역할을 Codex로 치환하고 Gemini 사용은 유지합니다.
+description: >
+  Codex 리드형 tfx-auto. Claude 네이티브 역할을 Codex로 치환하고 Gemini 사용은 유지합니다.
+  '코덱스 리드', '코덱스가 주도', 'codex lead' 같은 요청에 사용.
 triggers:
   - tfx-auto-codex
 argument-hint: "\"작업 설명\" | N:agent_type \"작업 설명\""
@@ -8,6 +10,11 @@ argument-hint: "\"작업 설명\" | N:agent_type \"작업 설명\""
 
 # tfx-auto-codex — Codex 리드형 tfx-auto
 
+> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
+> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
+
+
+> **래퍼**: tfx-auto의 Codex 전용 바로가기. TFX_NO_CLAUDE_NATIVE=1.
 > 목적: 기존 `tfx-auto`의 오케스트레이션 패턴을 유지하면서
 > Claude 네이티브 역할(`explore`, `verifier`, `test-engineer`, `qa-tester`)을
 > Codex로 치환해 Codex/Gemini만으로 실행한다.
@@ -21,7 +28,7 @@ argument-hint: "\"작업 설명\" | N:agent_type \"작업 설명\""
 3. **Claude 네이티브 제거**
    - 실행 시 `TFX_NO_CLAUDE_NATIVE=1`로 강제.
 4. **고난도 설계는 xhigh**
-   - 설계/분해/비판 검토 성격의 작업은 `codex --profile xhigh` 기준으로 운용.
+   - 설계/분해/비판 검토 성격의 작업은 `codex --profile gpt54_xhigh` 기준으로 운용.
 
 ## 사용법
 
@@ -46,10 +53,31 @@ TFX_NO_CLAUDE_NATIVE=1 bash ~/.claude/scripts/tfx-route.sh {agent} '{prompt}' {m
 `TFX_NO_CLAUDE_NATIVE=1`일 때:
 
 - `explore` -> Codex `fast`
-- `verifier` -> Codex `thorough review`
+- `verifier` -> Codex `thorough review` (**기본값: 이미 Codex로 설정됨**)
 - `test-engineer` -> Codex `high`
 - `qa-tester` -> Codex `thorough review`
 
+> **참고:** `verifier`는 tfx-auto-codex의 기본 라우팅에서 이미 Codex로 실행된다.
+> 별도 오버라이드가 필요한 경우 `TFX_VERIFIER_OVERRIDE` 환경변수를 사용한다.
+
+### TFX_VERIFIER_OVERRIDE
+
+`verifier` 역할의 기본 Codex 라우팅을 재정의한다.
+
+```bash
+# Claude 네이티브 verifier로 실행 (예: 도구 접근이 필요한 경우)
+TFX_VERIFIER_OVERRIDE=claude-native /tfx-auto-codex "..."
+
+# 특정 Codex 프로필로 강제 지정
+TFX_VERIFIER_OVERRIDE=codex:xhigh /tfx-auto-codex "..."
+```
+
+| 값 | 동작 |
+|----|------|
+| 미설정 (기본) | Codex `thorough review` |
+| `codex:<profile>` | 지정 프로필로 Codex 실행 |
+| `claude-native` | Claude 네이티브 verifier로 폴백 |
+
 ## 트리아지 기준
 
 - `codex`: 코드 구현/수정/분석/리뷰/디버깅/테스트/검증/리서치

package/skills/tfx-auto-codex/skill.json

@@ -0,0 +1,8 @@
+{
+  "name": "tfx-auto-codex",
+  "description": "Codex 리드형 tfx-auto. Claude 네이티브 역할을 Codex로 치환하고 Gemini 사용은 유지합니다. '코덱스 리드', '코덱스가 주도', 'codex lead' 같은 요청에 사용.",
+  "triggers": [
+    "tfx-auto-codex"
+  ],
+  "argument_hint": "\\\"작업 설명\\\" | N:agent_type \\\"작업 설명\\\""
+}

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

@@ -0,0 +1,115 @@
+---
+name: tfx-autopilot
+description: "단일 파일/모듈 수준의 간단한 작업을 자율 구현할 때 사용한다. 구현+검증까지 5분 이내 완료 가능한 작업, '간단히', '빠르게', '하나만', '자동으로', '알아서 해', '그냥 해줘' 같은 수식어가 있을 때 사용. 복잡한 멀티파일 작업은 tfx-fullcycle을 사용하세요."
+triggers:
+  - autopilot
+  - 자동
+  - 알아서 해
+argument-hint: "<구현할 작업 설명>"
+---
+
+# tfx-autopilot — Light Autonomous Execution
+
+> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
+> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
+
+
+> Codex 직접 구현 → Claude 검증. 최소 토큰으로 빠른 자율 실행.
+
+## 용도
+
+- 명확한 단일 작업을 빠르게 자동 구현
+- 보일러플레이트 생성 + 검증
+- 간단한 버그 수정 자동화
+- 린트/포맷/리팩터 자동 적용
+- "알아서 해줘" 류의 명확한 요청
+
+## 워크플로우
+
+### Step 1: 작업 파싱
+
+사용자 입력에서 구현 범위와 완료 기준을 추출한다:
+
+```
+입력: "로그인 API에 rate limiting 추가"
+파싱: {
+  task: "로그인 API에 rate limiting 추가",
+  scope: ["src/routes/auth.ts", "src/middleware/"],
+  criteria: [
+    "rate limiter 미들웨어 생성",
+    "로그인 엔드포인트에 적용",
+    "기존 테스트 통과"
+  ]
+}
+```
+
+모호하면 AskUserQuestion으로 명확화.
+
+### Step 2: Codex 직접 구현
+
+```bash
+bash ~/.claude/scripts/tfx-route.sh codex \
+  "다음 작업을 구현하라:
+   작업: {task}
+   프로젝트 컨텍스트: {context}
+   완료 기준: {criteria}
+
+   1. 관련 파일을 읽고 구조를 파악하라
+   2. 필요한 코드를 작성/수정하라
+   3. 기존 테스트를 실행하여 회귀가 없는지 확인하라
+   4. 변경 사항을 요약하라" implement
+```
+
+### Step 3: Claude 검증
+
+Codex 실행 완료 후, Claude가 변경 사항을 검증한다:
+
+```
+검증 항목:
+  1. 파일 변경 확인 — git diff로 실제 변경 내용 확인
+  2. 완료 기준 충족 — 각 criterion 대조
+  3. 회귀 여부 — 테스트 결과 확인
+  4. 코드 품질 — 명백한 결함 여부 (깊은 리뷰는 아님)
+
+판정:
+  PASS → 완료 보고
+  FAIL → Codex에 수정 지시 (1회 재시도)
+  재시도 FAIL → 사용자에게 문제 보고
+```
+
+### Step 4: 완료 보고
+
+```markdown
+## Autopilot 완료: {task}
+
+### 변경 사항
+- `{file1}` — {변경 요약}
+- `{file2}` — {변경 요약}
+
+### 검증
+- 완료 기준: {pass}/{total} 충족
+- 테스트: {pass}/{total} 통과
+- 검증: Claude ✓
+
+### 다음 단계 (선택)
+- {추가 권장 사항이 있으면}
+```
+
+## 토큰 예산
+
+| 단계 | 토큰 |
+|------|------|
+| Step 1 (파싱) | ~500 |
+| Step 2 (Codex 구현) | ~5K |
+| Step 3 (Claude 검증) | ~3K |
+| Step 4 (보고) | ~500 |
+| 재시도 (필요 시) | +4K |
+| **총합** | **~10K** |
+
+## 사용 예
+
+```
+/tfx-autopilot "이 함수에 입력 검증 추가해줘"
+/tfx-autopilot "ESLint 경고 전부 수정"
+/tfx-autopilot "알아서 해 — 이 TODO 코멘트 3개 구현"
+```

package/skills/tfx-autopilot/skill.json

@@ -0,0 +1,10 @@
+{
+  "name": "tfx-autopilot",
+  "description": "단일 파일/모듈 수준의 간단한 작업을 자율 구현할 때 사용한다. 구현+검증까지 5분 이내 완료 가능한 작업, '간단히', '빠르게', '하나만', '자동으로', '알아서 해', '그냥 해줘' 같은 수식어가 있을 때 사용. 복잡한 멀티파일 작업은 tfx-fullcycle을 사용하세요.",
+  "triggers": [
+    "autopilot",
+    "자동",
+    "알아서 해"
+  ],
+  "argument_hint": "<구현할 작업 설명>"
+}

package/skills/tfx-autoresearch/SKILL.md

@@ -2,17 +2,16 @@
 name: tfx-autoresearch
 description: >
   자율 웹 리서치 → 실행 가능 계획 도출.
-  주제를 받아 웹 검색 → 정보 수집 → 분석 → 구조화된 리서치 보고서 생성.
-  '알아봐', '조사해', '리서치해줘', '검색하고 정리해', 'research and plan' 같은 요청에 반드시 사용.
-  웹 검색 후 실행 가능한 계획까지 도출이 필요할 때 적극 활용.
+  주제를 받아 웹 검색 → 정보 수집 → 분석 → 구조화된 리서치 보고서 + 실행 계획 생성.
+  '자율 리서치', 'autoresearch', '검색하고 정리해', 'research and plan' 같은 요청에 사용.
+  단순 검색은 tfx-research, 자율 리서치+계획 도출은 이 스킬.
 triggers:
   - autoresearch
   - 자율 리서치
   - 자동 리서치
   - 웹 리서치
-  - 조사해
-  - 알아봐
-  - research this
+  - research and plan
+  - 검색하고 정리해
 argument-hint: "<topic>"
 source: GAP 분석 P2 #8
 ---