triflux 10.3.4 → 10.7.0

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

@@ -0,0 +1,222 @@
+---
+name: star-prompt
+description: >-
+  CLI 프로젝트의 setup/postinstall 흐름에 GitHub 스타 요청을 추가한다.
+  기본: 모달 차단형 (AskUserQuestion). --soft: 부드러운 confirm 모드.
+  gh CLI 인증 확인 → 이미 스타 여부 감지 → 선택 강제 → gh API로 자동 스타.
+  'star prompt', '스타 요청', '리포 스타', 'star request', '깃헙 스타 넣어줘',
+  'star 눌러달라고', '응원 요청' 같은 요청에 사용한다.
+---
+
+# tfx-star-prompt — GitHub Star Request Prompt
+
+CLI 도구의 setup/postinstall 완료 시점에 GitHub 리포 스타 요청을 추가한다.
+기본 모드는 aggressive(모달 차단형)이며, `--soft`를 전달하면 기존 부드러운 confirm 모드로 폴백한다.
+CI/비인터랙티브 환경에서는 자동으로 soft 모드로 강등한다.
+
+## 동작 흐름
+
+```
+detectInteractive() ─── false → soft 모드 강제
+       │
+       ✓ true
+       │
+gh --version ─── 실패 → URL만 표시
+       │
+       ✓ 설치됨
+       │
+gh auth status ─── 실패 → URL만 표시
+       │
+       ✓ 인증됨
+       │
+gh api user/starred/{owner}/{repo}
+       ├─ 성공 → "이미 함께하고 계시군요. ⭐" + markPrompted()
+       ├─ 404  → 미스타로 진행
+       └─ 그 외 에러 → 프롬프트 없이 URL만 표시 (마커 남기지 않음)
+       │
+       ✗ 미스타
+       │
+이미 프롬프트 본 유저(마커 존재)면 즉시 스킵
+       │
+aggressive 기본: AskUserQuestion([예, 누를게요] / [아니오]) 블로킹 선택
+soft(--soft): confirm("⭐ 하나가 큰 차이를 만듭니다.")
+       │
+       ├─ 아니오 → aggressive: 안내 + URL / soft: URL만 + markPrompted()
+       └─ 예
+       │
+       Y
+       │
+gh api -X PUT /user/starred/{owner}/{repo}
+       ├─ 성공 → aggressive: "감사합니다! 여러분의 ⭐가 프로젝트를 성장시킵니다."
+       │         soft: "함께해 주셔서 감사합니다. ⭐"
+       └─ 실패 → URL 폴백
+       │
+모든 프롬프트 완료 경로는 markPrompted() 호출
+```
+
+## 구현 패턴
+
+### 유틸리티 계약
+
+- `ok(message)`: 성공 메시지 출력(초록/강조 톤)
+- `info(message)`: 일반 안내 메시지 출력
+- `warn(message)`: 경고/실패 폴백 메시지 출력
+- `confirm(message, defaultValue)`: soft 모드용 Y/n 확인
+- `askUserQuestion({ question, options })`: aggressive 모달 선택 UI
+  - 옵션은 정확히 `[예, 누를게요]`, `[아니오]`
+  - 선택 전까지 흐름을 블로킹한다
+
+### 전체 `starRequest` 교체 패턴
+
+아래 패턴으로 기존 `starRequest` 함수를 전면 교체한다.
+
+```javascript
+import fs from "node:fs";
+import os from "node:os";
+import path from "node:path";
+import { execFileSync } from "node:child_process";
+
+function detectInteractive() {
+  if (!process.stdout.isTTY) return false;
+  if (process.env.CI) return false;
+  if (process.env.TERM === "dumb") return false;
+  return true;
+}
+
+function runGh(args) {
+  return execFileSync("gh", args, {
+    timeout: 10000,
+    encoding: "utf8",
+    stdio: ["pipe", "pipe", "pipe"],
+  });
+}
+
+function getHttpStatus(error) {
+  const out = [error?.stdout, error?.stderr].filter(Boolean).join("\n");
+  const match = out.match(/HTTP\s+(\d{3})/i) || out.match(/\b(\d{3})\b/);
+  return match ? Number(match[1]) : null;
+}
+
+export async function starRequest({
+  owner,
+  repo,
+  soft = false,
+  askUserQuestion,
+  confirm,
+  ok,
+  info,
+  warn,
+}) {
+  const repoUrl = `https://github.com/${owner}/${repo}`;
+  const interactive = detectInteractive();
+  const useSoft = soft || !interactive;
+
+  const MARKER_DIR = path.join(os.homedir(), ".config", "star-prompt");
+  const MARKER = path.join(MARKER_DIR, `${owner}-${repo}.prompted`);
+
+  const markPrompted = () => {
+    fs.mkdirSync(MARKER_DIR, { recursive: true });
+    fs.writeFileSync(MARKER, new Date().toISOString(), "utf8");
+  };
+
+  if (fs.existsSync(MARKER)) return;
+
+  try {
+    runGh(["--version"]);
+  } catch {
+    info(repoUrl);
+    return;
+  }
+
+  try {
+    runGh(["auth", "status"]);
+  } catch {
+    info(repoUrl);
+    return;
+  }
+
+  let alreadyStarred = false;
+  try {
+    runGh(["api", `user/starred/${owner}/${repo}`]);
+    alreadyStarred = true;
+  } catch (error) {
+    const status = getHttpStatus(error);
+    if (status === 404) {
+      alreadyStarred = false;
+    } else {
+      // API 에러(404 외): 프롬프트 없이 URL만 출력, 마커 미기록
+      warn(repoUrl);
+      return;
+    }
+  }
+
+  if (alreadyStarred) {
+    ok("이미 함께하고 계시군요. ⭐");
+    markPrompted();
+    return;
+  }
+
+  let accepted = false;
+  if (useSoft) {
+    accepted = await confirm("⭐ 하나가 큰 차이를 만듭니다.", true);
+  } else {
+    const answer = await askUserQuestion({
+      question: "⭐ 이 프로젝트가 마음에 드셨나요? 스타를 누르시겠습니까?",
+      options: ["예, 누를게요", "아니오"],
+    });
+    accepted = answer === "예, 누를게요";
+  }
+
+  if (!accepted) {
+    if (useSoft) {
+      info(repoUrl);
+    } else {
+      info(`괜찮습니다. 나중에 마음이 바뀌시면: ${repoUrl}`);
+    }
+    markPrompted();
+    return;
+  }
+
+  try {
+    runGh(["api", "-X", "PUT", `/user/starred/${owner}/${repo}`]);
+    if (useSoft) {
+      ok("함께해 주셔서 감사합니다. ⭐");
+    } else {
+      ok("감사합니다! 여러분의 ⭐가 프로젝트를 성장시킵니다.");
+    }
+  } catch {
+    warn(repoUrl);
+  } finally {
+    markPrompted();
+  }
+}
+```
+
+## 적용 시 규칙
+
+1. 기본 모드는 aggressive이며 `--soft` 전달 시에만 soft 모드로 전환한다.
+2. CI/비인터랙티브 감지는 아래 조건으로 강제 soft 폴백한다.
+   - `!process.stdout.isTTY || process.env.CI || process.env.TERM === "dumb"`
+3. gh 설치 확인은 `which` 대신 `gh --version`으로 수행한다 (크로스플랫폼).
+4. gh 인증 확인은 `gh auth status`로 수행한다.
+5. 스타 여부 체크는 `gh api user/starred/{owner}/{repo}`를 사용하고, `404`만 미스타로 판단한다.
+6. 스타 체크 API 에러가 `404` 외 상태면 프롬프트를 띄우지 않고 URL만 출력하며 마커를 남기지 않는다.
+7. 중복 요청 방지를 위해 아래 마커를 사용한다.
+   - `~/.config/star-prompt/{owner}-{repo}.prompted`
+   - 이미 스타한 유저도 `markPrompted()`를 호출한다.
+8. 모든 gh 호출은 `timeout: 10000`, `stdio: ["pipe","pipe","pipe"]`를 사용한다.
+9. setup/postinstall의 핵심 성공/실패 처리 흐름을 막지 않도록, 스타 로직 실패는 모두 조용히 폴백한다.
+
+## UX 카피 테이블
+
+| 상황 | Aggressive (기본) | Soft (`--soft`) |
+|------|-------------------|-----------------|
+| 이미 스타 | `이미 함께하고 계시군요. ⭐` | (동일) |
+| 요청 | `AskUserQuestion: ⭐ 이 프로젝트가 마음에 드셨나요? 스타를 누르시겠습니까?` | `⭐ 하나가 큰 차이를 만듭니다.` |
+| 수락 후 | `감사합니다! 여러분의 ⭐가 프로젝트를 성장시킵니다.` | `함께해 주셔서 감사합니다. ⭐` |
+| 거절 | `괜찮습니다. 나중에 마음이 바뀌시면:` + URL | URL만 |
+| gh 미설치 | URL만 표시 | (동일) |
+| gh 미인증 | URL만 표시 | (동일) |
+| CI/비인터랙티브 | soft 자동 폴백 | (동일) |
+| API 에러 (404 외) | 프롬프트 없이 URL만 표시, 마커 안 남김 | (동일) |
+| 이미 프롬프트 본 유저 | 스킵 | (동일) |

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

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

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

package/skills/tfx-auto/SKILL.md

@@ -40,6 +40,7 @@ argument-hint: "<command|task> [args...]"
 > - Errors: 실패 시 원인/복구/재시도 여부를 구조화해 기록한다.
 
 
+
 ### Step 0: 스마트 라우팅 (tfx-auto 진입 시 자동 실행)
 
 preamble에서 routing-weights.json을 읽고, 사용자 입력을 분석하여 dispatch 결정.

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

@@ -0,0 +1,106 @@
+---
+internal: true
+name: tfx-auto-codex
+description: >
+  Codex 리드형 tfx-auto. Claude 네이티브 역할을 Codex로 치환하고 Gemini 사용은 유지합니다.
+  '코덱스 리드', '코덱스가 주도', 'codex lead' 같은 요청에 사용.
+triggers:
+  - tfx-auto-codex
+argument-hint: "\"작업 설명\" | N:agent_type \"작업 설명\""
+---
+
+# {{SKILL_NAME}} — 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만으로 실행한다.
+
+## 핵심 원칙
+
+1. **Codex 라우팅 유지**
+   - 구현/분석/리뷰/디버깅/검증은 Codex 우선.
+2. **Gemini 유지**
+   - `designer`, `writer`는 Gemini 경로를 그대로 사용.
+3. **Claude 네이티브 제거**
+   - 실행 시 `TFX_NO_CLAUDE_NATIVE=1`로 강제.
+4. **고난도 설계는 xhigh**
+   - 설계/분해/비판 검토 성격의 작업은 `codex --profile gpt54_xhigh` 기준으로 운용.
+
+## 사용법
+
+```bash
+/tfx-auto-codex "인증 리팩터링 + UI 개선 + 테스트 보강"
+/tfx-auto-codex 3:codex "src/api, src/auth, src/payment 병렬 리뷰"
+/tfx-auto-codex 2:gemini "온보딩 UI 카피 + 접근성 개선"
+```
+
+## 실행 규칙
+
+`tfx-auto` 워크플로우(입력 파싱 → 트리아지 → 분해 → DAG 실행 → 수집/보고)를 그대로 사용한다.
+
+단, **실행 명령은 아래 환경변수를 반드시 포함**한다:
+
+```bash
+TFX_NO_CLAUDE_NATIVE=1 bash ~/.claude/scripts/tfx-route.sh {agent} '{prompt}' {mcp_profile}
+```
+
+### 역할 치환 (자동)
+
+`TFX_NO_CLAUDE_NATIVE=1`일 때:
+
+- `explore` -> Codex `fast`
+- `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`: 코드 구현/수정/분석/리뷰/디버깅/테스트/검증/리서치
+- `gemini`: 문서/UI/디자인/멀티모달
+
+Claude 타입 반환은 기본적으로 허용하지 않는다.
+분류 결과에 `claude`가 포함되면 `codex`로 치환 후 분해를 진행한다.
+단, Codex CLI 미설치 환경에서는 실행 안전성을 위해 `claude-native` fallback이 유지될 수 있다.
+
+## 권장 프로필
+
+- 설계/계획/비판적 검토: `xhigh`
+- 일반 구현/수정: `high`
+- 리뷰: `thorough`
+- 빠른 탐색: `fast`
+
+## 의존성
+
+- `~/.claude/scripts/tfx-route.sh` 최신 동기화 상태
+- Codex CLI 설치
+- Gemini CLI 설치 (UI/문서 경로 사용 시)
+
+## Troubleshooting
+
+문제 발생 시 `/tfx-doctor` 실행. (`--fix` 자동 수정, `--reset` 캐시 초기화)

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

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

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

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

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