triflux 8.5.1 → 8.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bin/triflux.mjs +6 -4
- package/hub/team/backend.mjs +1 -1
- package/hub/team/psmux.mjs +1 -1
- package/package.json +1 -1
- package/scripts/demo-tui.mjs +59 -0
- package/scripts/headless-guard.mjs +1 -1
- package/scripts/tfx-route-worker.mjs +6 -2
- package/skills/tfx-analysis/SKILL.md +101 -101
- package/skills/tfx-autopilot/SKILL.md +112 -112
- package/skills/tfx-autoroute/SKILL.md +184 -184
- package/skills/tfx-consensus/SKILL.md +114 -112
- package/skills/tfx-debate/SKILL.md +9 -9
- package/skills/tfx-deep-analysis/SKILL.md +191 -186
- package/skills/tfx-deep-plan/SKILL.md +20 -16
- package/skills/tfx-deep-qa/SKILL.md +14 -13
- package/skills/tfx-deep-research/SKILL.md +9 -9
- package/skills/tfx-deep-review/SKILL.md +96 -91
- package/skills/tfx-fullcycle/SKILL.md +18 -19
- package/skills/tfx-panel/SKILL.md +6 -6
- package/skills/tfx-qa/SKILL.md +117 -117
- package/skills/tfx-review/SKILL.md +51 -51
package/bin/triflux.mjs
CHANGED
|
@@ -735,7 +735,7 @@ function previewMcpRegistrationActions(mcpUrl) {
|
|
|
735
735
|
type: "mcp-register",
|
|
736
736
|
cli: "claude",
|
|
737
737
|
target: "tfx-hub",
|
|
738
|
-
path: join(
|
|
738
|
+
path: join(process.cwd(), ".claude", "mcp.json"),
|
|
739
739
|
url: mcpUrl,
|
|
740
740
|
change: "check",
|
|
741
741
|
});
|
|
@@ -2161,16 +2161,18 @@ function autoRegisterMcp(mcpUrl) {
|
|
|
2161
2161
|
info("Gemini: 미설치 (건너뜀)");
|
|
2162
2162
|
}
|
|
2163
2163
|
|
|
2164
|
-
// Claude —
|
|
2164
|
+
// Claude — .claude/mcp.json에 등록 (Claude Code 공식 경로)
|
|
2165
2165
|
try {
|
|
2166
|
-
const
|
|
2166
|
+
const claudeDir = join(process.cwd(), ".claude");
|
|
2167
|
+
if (!existsSync(claudeDir)) mkdirSync(claudeDir, { recursive: true });
|
|
2168
|
+
const mcpJsonPath = join(claudeDir, "mcp.json");
|
|
2167
2169
|
let mcpJson = {};
|
|
2168
2170
|
if (existsSync(mcpJsonPath)) mcpJson = JSON.parse(readFileSync(mcpJsonPath, "utf8"));
|
|
2169
2171
|
if (!mcpJson.mcpServers) mcpJson.mcpServers = {};
|
|
2170
2172
|
if (!mcpJson.mcpServers["tfx-hub"]) {
|
|
2171
2173
|
mcpJson.mcpServers["tfx-hub"] = { type: "url", url: mcpUrl };
|
|
2172
2174
|
writeFileSync(mcpJsonPath, JSON.stringify(mcpJson, null, 2) + "\n");
|
|
2173
|
-
ok("Claude: .mcp.json에 등록 완료");
|
|
2175
|
+
ok("Claude: .claude/mcp.json에 등록 완료");
|
|
2174
2176
|
} else {
|
|
2175
2177
|
ok("Claude: 이미 등록됨");
|
|
2176
2178
|
}
|
package/hub/team/backend.mjs
CHANGED
|
@@ -32,7 +32,7 @@ export class GeminiBackend {
|
|
|
32
32
|
command() { return "gemini"; }
|
|
33
33
|
|
|
34
34
|
buildArgs(prompt, resultFile, opts = {}) {
|
|
35
|
-
return `gemini
|
|
35
|
+
return `gemini --prompt ${prompt} --output-format text > '${resultFile}' 2>'${resultFile}.err'`;
|
|
36
36
|
}
|
|
37
37
|
|
|
38
38
|
env() { return {}; }
|
package/hub/team/psmux.mjs
CHANGED
|
@@ -758,7 +758,7 @@ export function startCapture(sessionName, paneNameOrTarget) {
|
|
|
758
758
|
* CLI 명령(codex/gemini)이 psmux pane의 PowerShell 환경에서 단축 플래그 충돌을
|
|
759
759
|
* 일으키는 문제를 방지하기 위해 bash -c '...' 로 감싼다.
|
|
760
760
|
* - codex -o flag → PS -OutVariable/OutBuffer 충돌
|
|
761
|
-
* - gemini -p
|
|
761
|
+
* - gemini --prompt flag (v8.6.0: -p → --prompt, PS 충돌 해소)
|
|
762
762
|
* @param {string} cmd
|
|
763
763
|
* @returns {string}
|
|
764
764
|
*/
|
package/package.json
CHANGED
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
// TUI 대시보드 데모 — 5초간 시뮬레이션 후 자동 종료
|
|
3
|
+
import { createLogDashboard } from "../hub/team/tui.mjs";
|
|
4
|
+
|
|
5
|
+
const tui = createLogDashboard({ refreshMs: 200, forceTTY: true });
|
|
6
|
+
|
|
7
|
+
// Phase 1: 워커 시작
|
|
8
|
+
tui.updateWorker("worker-1", {
|
|
9
|
+
cli: "codex", role: "executor", status: "running",
|
|
10
|
+
progress: 0.1, confidence: "low", tokens: "0.3k",
|
|
11
|
+
snapshot: "analyzing codebase...",
|
|
12
|
+
detail: "mcp: serena/activate_project started",
|
|
13
|
+
});
|
|
14
|
+
tui.updateWorker("worker-2", {
|
|
15
|
+
cli: "gemini", role: "writer", status: "running",
|
|
16
|
+
progress: 0.05, confidence: "low",
|
|
17
|
+
snapshot: "loading context...",
|
|
18
|
+
detail: "initializing gemini session",
|
|
19
|
+
});
|
|
20
|
+
|
|
21
|
+
// Phase 2: 진행
|
|
22
|
+
setTimeout(() => {
|
|
23
|
+
tui.updateWorker("worker-1", {
|
|
24
|
+
progress: 0.45, tokens: "1.2k", confidence: "medium",
|
|
25
|
+
snapshot: "mcp: serena/read_file (completed)",
|
|
26
|
+
detail: "mcp: serena/activate_project (completed)\nmcp: serena/read_file started\nmcp: serena/read_file (completed)\nmcp: serena/find_symbol started",
|
|
27
|
+
});
|
|
28
|
+
tui.updateWorker("worker-2", {
|
|
29
|
+
progress: 0.3, tokens: "0.8k",
|
|
30
|
+
snapshot: "writing README section...",
|
|
31
|
+
detail: "initializing gemini session\nreading existing docs\nwriting README section...",
|
|
32
|
+
});
|
|
33
|
+
}, 1500);
|
|
34
|
+
|
|
35
|
+
// Phase 3: worker-2 완료
|
|
36
|
+
setTimeout(() => {
|
|
37
|
+
tui.updateWorker("worker-1", {
|
|
38
|
+
progress: 0.78, tokens: "2.1k", confidence: "high",
|
|
39
|
+
snapshot: "applying fix to tui.mjs",
|
|
40
|
+
detail: "mcp: serena/activate_project (completed)\nmcp: serena/read_file (completed)\nmcp: serena/find_symbol (completed)\nmcp: serena/replace_symbol_body started\napplying fix to tui.mjs",
|
|
41
|
+
handoff: { files_changed: ["hub/team/tui.mjs"] },
|
|
42
|
+
});
|
|
43
|
+
tui.updateWorker("worker-2", {
|
|
44
|
+
status: "completed", progress: 1, tokens: "1.5k", confidence: "high",
|
|
45
|
+
handoff: { status: "ok", verdict: "documentation updated", confidence: "high", files_changed: ["README.md"] },
|
|
46
|
+
});
|
|
47
|
+
}, 3000);
|
|
48
|
+
|
|
49
|
+
// Phase 4: 전부 완료
|
|
50
|
+
setTimeout(() => {
|
|
51
|
+
tui.updateWorker("worker-1", {
|
|
52
|
+
status: "completed", progress: 1, tokens: "3.4k", confidence: "high",
|
|
53
|
+
handoff: { status: "ok", verdict: "fix applied and verified", confidence: "high", files_changed: ["hub/team/tui.mjs", "tests/unit/tui.test.mjs"] },
|
|
54
|
+
});
|
|
55
|
+
tui.updatePipeline({ phase: "verify" });
|
|
56
|
+
}, 4500);
|
|
57
|
+
|
|
58
|
+
// 종료
|
|
59
|
+
setTimeout(() => { tui.close(); process.exit(0); }, 6000);
|
|
@@ -15,7 +15,7 @@
|
|
|
15
15
|
*
|
|
16
16
|
* 동작:
|
|
17
17
|
* - psmux 설치 + Bash(tfx-route.sh) → updatedInput: tfx multi --headless --assign
|
|
18
|
-
* - psmux 설치 + Bash(codex exec / gemini
|
|
18
|
+
* - psmux 설치 + Bash(codex exec / gemini --prompt) → deny
|
|
19
19
|
* - psmux 설치 + Agent(codex/gemini CLI 래핑) → deny
|
|
20
20
|
* - psmux 미설치 → 전부 통과
|
|
21
21
|
* - tfx-multi 활성 + Agent(work) before dispatch → deny (A: gate)
|
|
@@ -121,8 +121,12 @@ function readPromptFromStdin() {
|
|
|
121
121
|
}
|
|
122
122
|
|
|
123
123
|
function resolveDefaultMcpConfig(cwd) {
|
|
124
|
-
const
|
|
125
|
-
|
|
124
|
+
const primary = resolve(cwd, '.claude', 'mcp.json');
|
|
125
|
+
if (existsSync(primary)) return [primary];
|
|
126
|
+
const legacy = resolve(cwd, '.mcp.json');
|
|
127
|
+
if (existsSync(legacy)) return [legacy];
|
|
128
|
+
process.stderr.write('[tfx-route-worker] warning: no MCP config found, hub unavailable\n');
|
|
129
|
+
return [];
|
|
126
130
|
}
|
|
127
131
|
|
|
128
132
|
const args = parseArgs(process.argv.slice(2));
|
|
@@ -1,101 +1,101 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: tfx-analysis
|
|
3
|
-
description: "코드나 아키텍처를 분석해야 할 때 사용한다. '코드 분석', 'code analysis', '아키텍처 분석', '이 코드 어떻게 돌아가?', '구조 파악' 같은 요청에 반드시 사용. 코드 품질, 보안, 성능, 복잡도 분석이 필요한 모든 상황에 적극 활용."
|
|
4
|
-
triggers:
|
|
5
|
-
- 코드 분석
|
|
6
|
-
- code analysis
|
|
7
|
-
- 아키텍처 분석
|
|
8
|
-
- analysis
|
|
9
|
-
argument-hint: "<분석 대상 — 파일, 디렉토리, 또는 주제>"
|
|
10
|
-
---
|
|
11
|
-
|
|
12
|
-
# tfx-analysis — Light Code Analysis
|
|
13
|
-
|
|
14
|
-
> Codex 단일 분석으로 빠른 인사이트. SuperClaude sc:analyze 영감.
|
|
15
|
-
|
|
16
|
-
## 용도
|
|
17
|
-
|
|
18
|
-
- 코드 품질 빠른 점검
|
|
19
|
-
- 모듈/파일 구조 분석
|
|
20
|
-
- 의존성 관계 파악
|
|
21
|
-
- 성능 병목 후보 식별
|
|
22
|
-
- 기술 부채 탐지
|
|
23
|
-
- "이 코드 어떤 상태야?" 류의 질문
|
|
24
|
-
|
|
25
|
-
## 워크플로우
|
|
26
|
-
|
|
27
|
-
### Step 1: 분석 대상 식별
|
|
28
|
-
|
|
29
|
-
```
|
|
30
|
-
우선순위:
|
|
31
|
-
1. 사용자가 파일/디렉토리 지정 → 해당 범위
|
|
32
|
-
2. 사용자가 주제 지정 (예: "인증 모듈") → 관련 파일 탐색
|
|
33
|
-
3. 지정 없음 → 프로젝트 전체 고수준 분석
|
|
34
|
-
|
|
35
|
-
분석 유형 자동 감지:
|
|
36
|
-
파일 1개 → 코드 품질 + 로직 분석
|
|
37
|
-
디렉토리 → 구조 + 의존성 + 모듈 분석
|
|
38
|
-
프로젝트 전체 → 아키텍처 + 기술 부채 분석
|
|
39
|
-
```
|
|
40
|
-
|
|
41
|
-
### Step 2: Codex 분석 실행
|
|
42
|
-
|
|
43
|
-
```bash
|
|
44
|
-
|
|
45
|
-
"시니어 소프트웨어 엔지니어로서 다음을 분석하라:
|
|
46
|
-
대상: {target}
|
|
47
|
-
유형: {analysis_type}
|
|
48
|
-
|
|
49
|
-
분석 항목:
|
|
50
|
-
1. 구조 — 파일/모듈 구성, 계층, 의존성 방향
|
|
51
|
-
2. 복잡도 — 순환 복잡도 높은 함수, 깊은 중첩
|
|
52
|
-
3. 품질 — SOLID 위반, 코드 냄새, 중복
|
|
53
|
-
4. 성능 — O(n²) 패턴, 불필요한 연산, 캐싱 부재
|
|
54
|
-
5. 기술 부채 — TODO/FIXME, deprecated API, 하드코딩
|
|
55
|
-
6. 테스트 — 커버리지 추정, 테스트 부재 영역
|
|
56
|
-
|
|
57
|
-
구조화된 보고서로 출력하라."
|
|
58
|
-
```
|
|
59
|
-
|
|
60
|
-
### Step 3: 결과 포맷
|
|
61
|
-
|
|
62
|
-
```markdown
|
|
63
|
-
## 분석 결과: {target}
|
|
64
|
-
|
|
65
|
-
### 구조 개요
|
|
66
|
-
{파일/모듈 구조 요약 또는 의존성 다이어그램}
|
|
67
|
-
|
|
68
|
-
### 주요 발견
|
|
69
|
-
| # | 카테고리 | 심각도 | 설명 | 위치 |
|
|
70
|
-
|---|---------|--------|------|------|
|
|
71
|
-
| 1 | 복잡도 | high | {설명} | `{file}:{line}` |
|
|
72
|
-
| 2 | 성능 | medium | {설명} | `{file}:{line}` |
|
|
73
|
-
|
|
74
|
-
### 메트릭
|
|
75
|
-
- 파일 수: {n} | 총 라인: {n}
|
|
76
|
-
- 평균 복잡도: {n} | 최대 복잡도: {n} (`{file}:{function}`)
|
|
77
|
-
- TODO/FIXME: {n}개
|
|
78
|
-
- 테스트 커버리지 추정: {n}%
|
|
79
|
-
|
|
80
|
-
### 개선 권장사항
|
|
81
|
-
1. **{우선순위 1}** — {구체적 제안}
|
|
82
|
-
2. **{우선순위 2}** — {구체적 제안}
|
|
83
|
-
3. **{우선순위 3}** — {구체적 제안}
|
|
84
|
-
```
|
|
85
|
-
|
|
86
|
-
## 토큰 예산
|
|
87
|
-
|
|
88
|
-
| 단계 | 토큰 |
|
|
89
|
-
|------|------|
|
|
90
|
-
| Step 1 (식별) | ~500 |
|
|
91
|
-
| Step 2 (Codex 분석) | ~5K |
|
|
92
|
-
| Step 3 (포맷) | ~2K |
|
|
93
|
-
| **총합** | **~8K** |
|
|
94
|
-
|
|
95
|
-
## 사용 예
|
|
96
|
-
|
|
97
|
-
```
|
|
98
|
-
/tfx-analysis "src/auth/"
|
|
99
|
-
/tfx-analysis "이 프로젝트 전체 아키텍처 분석"
|
|
100
|
-
/tfx-analysis "src/utils/parser.ts 코드 품질"
|
|
101
|
-
```
|
|
1
|
+
---
|
|
2
|
+
name: tfx-analysis
|
|
3
|
+
description: "코드나 아키텍처를 분석해야 할 때 사용한다. '코드 분석', 'code analysis', '아키텍처 분석', '이 코드 어떻게 돌아가?', '구조 파악' 같은 요청에 반드시 사용. 코드 품질, 보안, 성능, 복잡도 분석이 필요한 모든 상황에 적극 활용."
|
|
4
|
+
triggers:
|
|
5
|
+
- 코드 분석
|
|
6
|
+
- code analysis
|
|
7
|
+
- 아키텍처 분석
|
|
8
|
+
- analysis
|
|
9
|
+
argument-hint: "<분석 대상 — 파일, 디렉토리, 또는 주제>"
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# tfx-analysis — Light Code Analysis
|
|
13
|
+
|
|
14
|
+
> Codex 단일 분석으로 빠른 인사이트. SuperClaude sc:analyze 영감.
|
|
15
|
+
|
|
16
|
+
## 용도
|
|
17
|
+
|
|
18
|
+
- 코드 품질 빠른 점검
|
|
19
|
+
- 모듈/파일 구조 분석
|
|
20
|
+
- 의존성 관계 파악
|
|
21
|
+
- 성능 병목 후보 식별
|
|
22
|
+
- 기술 부채 탐지
|
|
23
|
+
- "이 코드 어떤 상태야?" 류의 질문
|
|
24
|
+
|
|
25
|
+
## 워크플로우
|
|
26
|
+
|
|
27
|
+
### Step 1: 분석 대상 식별
|
|
28
|
+
|
|
29
|
+
```
|
|
30
|
+
우선순위:
|
|
31
|
+
1. 사용자가 파일/디렉토리 지정 → 해당 범위
|
|
32
|
+
2. 사용자가 주제 지정 (예: "인증 모듈") → 관련 파일 탐색
|
|
33
|
+
3. 지정 없음 → 프로젝트 전체 고수준 분석
|
|
34
|
+
|
|
35
|
+
분석 유형 자동 감지:
|
|
36
|
+
파일 1개 → 코드 품질 + 로직 분석
|
|
37
|
+
디렉토리 → 구조 + 의존성 + 모듈 분석
|
|
38
|
+
프로젝트 전체 → 아키텍처 + 기술 부채 분석
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
### Step 2: Codex 분석 실행
|
|
42
|
+
|
|
43
|
+
```bash
|
|
44
|
+
bash ~/.claude/scripts/tfx-route.sh codex \
|
|
45
|
+
"시니어 소프트웨어 엔지니어로서 다음을 분석하라:
|
|
46
|
+
대상: {target}
|
|
47
|
+
유형: {analysis_type}
|
|
48
|
+
|
|
49
|
+
분석 항목:
|
|
50
|
+
1. 구조 — 파일/모듈 구성, 계층, 의존성 방향
|
|
51
|
+
2. 복잡도 — 순환 복잡도 높은 함수, 깊은 중첩
|
|
52
|
+
3. 품질 — SOLID 위반, 코드 냄새, 중복
|
|
53
|
+
4. 성능 — O(n²) 패턴, 불필요한 연산, 캐싱 부재
|
|
54
|
+
5. 기술 부채 — TODO/FIXME, deprecated API, 하드코딩
|
|
55
|
+
6. 테스트 — 커버리지 추정, 테스트 부재 영역
|
|
56
|
+
|
|
57
|
+
구조화된 보고서로 출력하라." analyze
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
### Step 3: 결과 포맷
|
|
61
|
+
|
|
62
|
+
```markdown
|
|
63
|
+
## 분석 결과: {target}
|
|
64
|
+
|
|
65
|
+
### 구조 개요
|
|
66
|
+
{파일/모듈 구조 요약 또는 의존성 다이어그램}
|
|
67
|
+
|
|
68
|
+
### 주요 발견
|
|
69
|
+
| # | 카테고리 | 심각도 | 설명 | 위치 |
|
|
70
|
+
|---|---------|--------|------|------|
|
|
71
|
+
| 1 | 복잡도 | high | {설명} | `{file}:{line}` |
|
|
72
|
+
| 2 | 성능 | medium | {설명} | `{file}:{line}` |
|
|
73
|
+
|
|
74
|
+
### 메트릭
|
|
75
|
+
- 파일 수: {n} | 총 라인: {n}
|
|
76
|
+
- 평균 복잡도: {n} | 최대 복잡도: {n} (`{file}:{function}`)
|
|
77
|
+
- TODO/FIXME: {n}개
|
|
78
|
+
- 테스트 커버리지 추정: {n}%
|
|
79
|
+
|
|
80
|
+
### 개선 권장사항
|
|
81
|
+
1. **{우선순위 1}** — {구체적 제안}
|
|
82
|
+
2. **{우선순위 2}** — {구체적 제안}
|
|
83
|
+
3. **{우선순위 3}** — {구체적 제안}
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
## 토큰 예산
|
|
87
|
+
|
|
88
|
+
| 단계 | 토큰 |
|
|
89
|
+
|------|------|
|
|
90
|
+
| Step 1 (식별) | ~500 |
|
|
91
|
+
| Step 2 (Codex 분석) | ~5K |
|
|
92
|
+
| Step 3 (포맷) | ~2K |
|
|
93
|
+
| **총합** | **~8K** |
|
|
94
|
+
|
|
95
|
+
## 사용 예
|
|
96
|
+
|
|
97
|
+
```
|
|
98
|
+
/tfx-analysis "src/auth/"
|
|
99
|
+
/tfx-analysis "이 프로젝트 전체 아키텍처 분석"
|
|
100
|
+
/tfx-analysis "src/utils/parser.ts 코드 품질"
|
|
101
|
+
```
|
|
@@ -1,112 +1,112 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: tfx-autopilot
|
|
3
|
-
description: "간단한 작업을 자율적으로 구현해야 할 때 사용한다. 'autopilot', '자동으로', '알아서 해', '그냥 해줘', 'auto' 같은 요청에 반드시 사용. 명확한 단일 작업을 빠르게 자동 구현+검증할 때 적극 활용."
|
|
4
|
-
triggers:
|
|
5
|
-
- autopilot
|
|
6
|
-
- 자동
|
|
7
|
-
- 알아서 해
|
|
8
|
-
- auto
|
|
9
|
-
argument-hint: "<구현할 작업 설명>"
|
|
10
|
-
---
|
|
11
|
-
|
|
12
|
-
# tfx-autopilot — Light Autonomous Execution
|
|
13
|
-
|
|
14
|
-
> Codex 직접 구현 → Claude 검증. 최소 토큰으로 빠른 자율 실행.
|
|
15
|
-
|
|
16
|
-
## 용도
|
|
17
|
-
|
|
18
|
-
- 명확한 단일 작업을 빠르게 자동 구현
|
|
19
|
-
- 보일러플레이트 생성 + 검증
|
|
20
|
-
- 간단한 버그 수정 자동화
|
|
21
|
-
- 린트/포맷/리팩터 자동 적용
|
|
22
|
-
- "알아서 해줘" 류의 명확한 요청
|
|
23
|
-
|
|
24
|
-
## 워크플로우
|
|
25
|
-
|
|
26
|
-
### Step 1: 작업 파싱
|
|
27
|
-
|
|
28
|
-
사용자 입력에서 구현 범위와 완료 기준을 추출한다:
|
|
29
|
-
|
|
30
|
-
```
|
|
31
|
-
입력: "로그인 API에 rate limiting 추가"
|
|
32
|
-
파싱: {
|
|
33
|
-
task: "로그인 API에 rate limiting 추가",
|
|
34
|
-
scope: ["src/routes/auth.ts", "src/middleware/"],
|
|
35
|
-
criteria: [
|
|
36
|
-
"rate limiter 미들웨어 생성",
|
|
37
|
-
"로그인 엔드포인트에 적용",
|
|
38
|
-
"기존 테스트 통과"
|
|
39
|
-
]
|
|
40
|
-
}
|
|
41
|
-
```
|
|
42
|
-
|
|
43
|
-
모호하면 AskUserQuestion으로 명확화.
|
|
44
|
-
|
|
45
|
-
### Step 2: Codex 직접 구현
|
|
46
|
-
|
|
47
|
-
```bash
|
|
48
|
-
|
|
49
|
-
"다음 작업을 구현하라:
|
|
50
|
-
작업: {task}
|
|
51
|
-
프로젝트 컨텍스트: {context}
|
|
52
|
-
완료 기준: {criteria}
|
|
53
|
-
|
|
54
|
-
1. 관련 파일을 읽고 구조를 파악하라
|
|
55
|
-
2. 필요한 코드를 작성/수정하라
|
|
56
|
-
3. 기존 테스트를 실행하여 회귀가 없는지 확인하라
|
|
57
|
-
4. 변경 사항을 요약하라"
|
|
58
|
-
```
|
|
59
|
-
|
|
60
|
-
### Step 3: Claude 검증
|
|
61
|
-
|
|
62
|
-
Codex 실행 완료 후, Claude가 변경 사항을 검증한다:
|
|
63
|
-
|
|
64
|
-
```
|
|
65
|
-
검증 항목:
|
|
66
|
-
1. 파일 변경 확인 — git diff로 실제 변경 내용 확인
|
|
67
|
-
2. 완료 기준 충족 — 각 criterion 대조
|
|
68
|
-
3. 회귀 여부 — 테스트 결과 확인
|
|
69
|
-
4. 코드 품질 — 명백한 결함 여부 (깊은 리뷰는 아님)
|
|
70
|
-
|
|
71
|
-
판정:
|
|
72
|
-
PASS → 완료 보고
|
|
73
|
-
FAIL → Codex에 수정 지시 (1회 재시도)
|
|
74
|
-
재시도 FAIL → 사용자에게 문제 보고
|
|
75
|
-
```
|
|
76
|
-
|
|
77
|
-
### Step 4: 완료 보고
|
|
78
|
-
|
|
79
|
-
```markdown
|
|
80
|
-
## Autopilot 완료: {task}
|
|
81
|
-
|
|
82
|
-
### 변경 사항
|
|
83
|
-
- `{file1}` — {변경 요약}
|
|
84
|
-
- `{file2}` — {변경 요약}
|
|
85
|
-
|
|
86
|
-
### 검증
|
|
87
|
-
- 완료 기준: {pass}/{total} 충족
|
|
88
|
-
- 테스트: {pass}/{total} 통과
|
|
89
|
-
- 검증: Claude ✓
|
|
90
|
-
|
|
91
|
-
### 다음 단계 (선택)
|
|
92
|
-
- {추가 권장 사항이 있으면}
|
|
93
|
-
```
|
|
94
|
-
|
|
95
|
-
## 토큰 예산
|
|
96
|
-
|
|
97
|
-
| 단계 | 토큰 |
|
|
98
|
-
|------|------|
|
|
99
|
-
| Step 1 (파싱) | ~500 |
|
|
100
|
-
| Step 2 (Codex 구현) | ~5K |
|
|
101
|
-
| Step 3 (Claude 검증) | ~3K |
|
|
102
|
-
| Step 4 (보고) | ~500 |
|
|
103
|
-
| 재시도 (필요 시) | +4K |
|
|
104
|
-
| **총합** | **~10K** |
|
|
105
|
-
|
|
106
|
-
## 사용 예
|
|
107
|
-
|
|
108
|
-
```
|
|
109
|
-
/tfx-autopilot "이 함수에 입력 검증 추가해줘"
|
|
110
|
-
/tfx-autopilot "ESLint 경고 전부 수정"
|
|
111
|
-
/tfx-autopilot "알아서 해 — 이 TODO 코멘트 3개 구현"
|
|
112
|
-
```
|
|
1
|
+
---
|
|
2
|
+
name: tfx-autopilot
|
|
3
|
+
description: "간단한 작업을 자율적으로 구현해야 할 때 사용한다. 'autopilot', '자동으로', '알아서 해', '그냥 해줘', 'auto' 같은 요청에 반드시 사용. 명확한 단일 작업을 빠르게 자동 구현+검증할 때 적극 활용."
|
|
4
|
+
triggers:
|
|
5
|
+
- autopilot
|
|
6
|
+
- 자동
|
|
7
|
+
- 알아서 해
|
|
8
|
+
- auto
|
|
9
|
+
argument-hint: "<구현할 작업 설명>"
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# tfx-autopilot — Light Autonomous Execution
|
|
13
|
+
|
|
14
|
+
> Codex 직접 구현 → Claude 검증. 최소 토큰으로 빠른 자율 실행.
|
|
15
|
+
|
|
16
|
+
## 용도
|
|
17
|
+
|
|
18
|
+
- 명확한 단일 작업을 빠르게 자동 구현
|
|
19
|
+
- 보일러플레이트 생성 + 검증
|
|
20
|
+
- 간단한 버그 수정 자동화
|
|
21
|
+
- 린트/포맷/리팩터 자동 적용
|
|
22
|
+
- "알아서 해줘" 류의 명확한 요청
|
|
23
|
+
|
|
24
|
+
## 워크플로우
|
|
25
|
+
|
|
26
|
+
### Step 1: 작업 파싱
|
|
27
|
+
|
|
28
|
+
사용자 입력에서 구현 범위와 완료 기준을 추출한다:
|
|
29
|
+
|
|
30
|
+
```
|
|
31
|
+
입력: "로그인 API에 rate limiting 추가"
|
|
32
|
+
파싱: {
|
|
33
|
+
task: "로그인 API에 rate limiting 추가",
|
|
34
|
+
scope: ["src/routes/auth.ts", "src/middleware/"],
|
|
35
|
+
criteria: [
|
|
36
|
+
"rate limiter 미들웨어 생성",
|
|
37
|
+
"로그인 엔드포인트에 적용",
|
|
38
|
+
"기존 테스트 통과"
|
|
39
|
+
]
|
|
40
|
+
}
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
모호하면 AskUserQuestion으로 명확화.
|
|
44
|
+
|
|
45
|
+
### Step 2: Codex 직접 구현
|
|
46
|
+
|
|
47
|
+
```bash
|
|
48
|
+
bash ~/.claude/scripts/tfx-route.sh codex \
|
|
49
|
+
"다음 작업을 구현하라:
|
|
50
|
+
작업: {task}
|
|
51
|
+
프로젝트 컨텍스트: {context}
|
|
52
|
+
완료 기준: {criteria}
|
|
53
|
+
|
|
54
|
+
1. 관련 파일을 읽고 구조를 파악하라
|
|
55
|
+
2. 필요한 코드를 작성/수정하라
|
|
56
|
+
3. 기존 테스트를 실행하여 회귀가 없는지 확인하라
|
|
57
|
+
4. 변경 사항을 요약하라" implement
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
### Step 3: Claude 검증
|
|
61
|
+
|
|
62
|
+
Codex 실행 완료 후, Claude가 변경 사항을 검증한다:
|
|
63
|
+
|
|
64
|
+
```
|
|
65
|
+
검증 항목:
|
|
66
|
+
1. 파일 변경 확인 — git diff로 실제 변경 내용 확인
|
|
67
|
+
2. 완료 기준 충족 — 각 criterion 대조
|
|
68
|
+
3. 회귀 여부 — 테스트 결과 확인
|
|
69
|
+
4. 코드 품질 — 명백한 결함 여부 (깊은 리뷰는 아님)
|
|
70
|
+
|
|
71
|
+
판정:
|
|
72
|
+
PASS → 완료 보고
|
|
73
|
+
FAIL → Codex에 수정 지시 (1회 재시도)
|
|
74
|
+
재시도 FAIL → 사용자에게 문제 보고
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
### Step 4: 완료 보고
|
|
78
|
+
|
|
79
|
+
```markdown
|
|
80
|
+
## Autopilot 완료: {task}
|
|
81
|
+
|
|
82
|
+
### 변경 사항
|
|
83
|
+
- `{file1}` — {변경 요약}
|
|
84
|
+
- `{file2}` — {변경 요약}
|
|
85
|
+
|
|
86
|
+
### 검증
|
|
87
|
+
- 완료 기준: {pass}/{total} 충족
|
|
88
|
+
- 테스트: {pass}/{total} 통과
|
|
89
|
+
- 검증: Claude ✓
|
|
90
|
+
|
|
91
|
+
### 다음 단계 (선택)
|
|
92
|
+
- {추가 권장 사항이 있으면}
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
## 토큰 예산
|
|
96
|
+
|
|
97
|
+
| 단계 | 토큰 |
|
|
98
|
+
|------|------|
|
|
99
|
+
| Step 1 (파싱) | ~500 |
|
|
100
|
+
| Step 2 (Codex 구현) | ~5K |
|
|
101
|
+
| Step 3 (Claude 검증) | ~3K |
|
|
102
|
+
| Step 4 (보고) | ~500 |
|
|
103
|
+
| 재시도 (필요 시) | +4K |
|
|
104
|
+
| **총합** | **~10K** |
|
|
105
|
+
|
|
106
|
+
## 사용 예
|
|
107
|
+
|
|
108
|
+
```
|
|
109
|
+
/tfx-autopilot "이 함수에 입력 검증 추가해줘"
|
|
110
|
+
/tfx-autopilot "ESLint 경고 전부 수정"
|
|
111
|
+
/tfx-autopilot "알아서 해 — 이 TODO 코멘트 3개 구현"
|
|
112
|
+
```
|