triflux 4.2.9 → 5.0.0

package/skills/tfx-multi/SKILL.md

@@ -11,7 +11,7 @@ argument-hint: '"작업 설명" | --agents codex,gemini "작업" | --tmux "작
 > Claude Code Native Teams의 Shift+Down 네비게이션을 복원한다.
 > Codex/Gemini 워커마다 최소 프롬프트(~100 토큰)의 슬림 Agent 래퍼를 spawn하여 네비게이션에 등록하고,
 > 실제 작업은 `tfx-route.sh`가 수행한다. task 상태는 `team_task_list`를 truth source로 검증한다.
-> v3 — `--quick`(기본) + `--thorough`(전체 파이프라인: plan→prd→exec→verify→fix loop).
+> v3 — `--thorough`(기본: plan→prd→exec→verify→fix loop) + `--quick`(경량 모드).
 
 > **Lead 고토큰 MCP 직접 사용 금지**
 > Lead(Claude Opus)는 웹 서치(brave-search, exa, tavily), 외부 서비스(Notion, Jira/Confluence, Calendar, Gmail),
@@ -21,8 +21,8 @@ argument-hint: '"작업 설명" | --agents codex,gemini "작업" | --tmux "작
 ## 사용법
 
 ```
-/tfx-multi "인증 리팩터링 + UI 개선 + 보안 리뷰"           # --quick (기본)
-/tfx-multi --thorough "인증 리팩터링 + UI 개선 + 보안 리뷰"  # 전체 파이프라인
+/tfx-multi "인증 리팩터링 + UI 개선 + 보안 리뷰"           # --thorough (기본)
+/tfx-multi --quick "인증 리팩터링 + UI 개선 + 보안 리뷰"    # 경량 모드 (plan/verify 생략)
 /tfx-multi --agents codex,gemini "프론트+백엔드"
 /tfx-multi --tmux "작업"         # 레거시 tmux 모드
 /tfx-multi status
@@ -48,11 +48,17 @@ preflight와 Agent 생성을 병렬로 실행하여 사용자 체감 지연을
 ```
 ""(빈 문자열)          → 사용자에게 작업 입력 요청
 "3:codex 리뷰"         → 수동 모드: N=3, agent=codex
-"인증 + UI + 테스트"    → 자동 모드: Codex 분류 → Opus 분해
+"인증 + UI + 테스트"    → 자동 모드 (--thorough 기본): Codex 분류 → Opus 분해 → Pipeline
+"--quick 인증 + UI"    → 경량 모드: plan/verify 생략, 즉시 실행
 "--tmux 인증 + UI"     → Phase 3-mux 분기
 "status" / "stop"      → Bash("node bin/triflux.mjs multi {cmd}") 직행
 ```
 
+**모드 결정:**
+- `--quick` 명시 → quick 모드 (Phase 2.5-2.6, 3.5-3.7 생략)
+- `--thorough` 명시 또는 플래그 없음 → thorough 모드 (기본, 전체 파이프라인)
+- 커맨드 숏컷 (tfx-auto 경유 단일 실행) → quick 유지 (오버헤드 불필요)
+
 ### Phase 2: 트리아지 (tfx-auto와 동일)
 
 **자동 모드:**
@@ -62,9 +68,9 @@ preflight와 Agent 생성을 병렬로 실행하여 사용자 체감 지연을
 
 **수동 모드:** Codex 분류 건너뜀 → Opus가 직접 N개 서브태스크 분해.
 
-### Phase 2.5–2.6 + 3.5–3.7: `--thorough` 파이프라인
+### Phase 2.5–2.6 + 3.5–3.7: 파이프라인 (기본)
 
-> `--quick`(기본)에서는 건너뛴다. `--thorough` 모드에서만 실행.
+> `--thorough`(기본) 모드에서 실행된다. `--quick` 플래그 시 건너뛴다.
 > 상세는 → [`references/thorough-pipeline.md`](references/thorough-pipeline.md) 참조.
 
 ### Phase 3: Native Teams 실행

package/skills/tfx-multi/references/thorough-pipeline.md

@@ -1,24 +1,63 @@
-# --thorough 파이프라인 상세
+# 파이프라인 상세 (thorough 기본)
 
-> `--quick`(기본) 모드에서는 이 파일의 내용이 적용되지 않는다.
-> `--thorough` 모드에서만 Phase 2.5-2.6과 Phase 3.5-3.7이 실행된다.
+> `--thorough`(기본) 모드에서 Phase 2.5-2.6과 Phase 3.5-3.7이 실행된다.
+> `--quick` 플래그 시 이 파일의 내용은 적용되지 않는다.
+> tfx-auto 경유 시: `-t`/`--thorough` 플래그가 있을 때만 파이프라인이 활성화된다.
 
-## Phase 2.5: Plan (Codex architect)
+## Phase 2.5: Plan (Opus Lead + Codex Scout 협업)
 
-1. Hub pipeline 초기화:
-   ```bash
-   Bash("node hub/bridge.mjs pipeline-advance --team ${teamName} --status plan")
-   ```
-   — 또는 createPipeline(db, teamName) 직접 호출
-2. Codex architect로 작업 분석 + 접근법 설계:
-   ```bash
-   bash ~/.claude/scripts/tfx-route.sh architect "${task}" analyze
-   ```
-3. 결과를 파이프라인 artifact에 저장:
-   ```
-   pipeline.setArtifact('plan_path', planOutputPath)
-   ```
-4. pipeline advance: plan → prd
+> 기존: Codex architect(단독, one-shot)
+> 변경: Opus 설계 주도 + Codex scout(병렬 탐색) → 합산 판단 → 최종 계획
+
+### Step 2.5.1: Opus 과제 분석 → 탐색 목록 생성
+
+Lead(Opus)가 과제를 분석하고, 설계에 필요한 정보 탐색 목록을 인라인 생성한다:
+
+```json
+{
+  "questions": [
+    { "id": "q1", "question": "현재 인증 미들웨어 구조와 세션 관리 방식", "scope": "src/middleware/auth*" },
+    { "id": "q2", "question": "DB 스키마와 마이그레이션 현황", "scope": "db/migrations/" }
+  ]
+}
+```
+
+탐색 목록은 3-7개 항목 권장. 과도하면 Codex 비용이 아닌 Lead 컨텍스트가 팽창.
+
+### Step 2.5.2: Codex Scout 병렬 파견
+
+각 탐색 항목마다 Codex scout를 파견하여 코드베이스 탐색:
+
+```bash
+# 각 question마다 병렬 실행
+for each question:
+  bash ~/.claude/scripts/tfx-route.sh scientist "${question.question}. 탐색 범위: ${question.scope}" analyze
+```
+
+**scout 실행 규칙:**
+- scout는 **read-only** — 코드 수정 금지, 탐색+보고만
+- 병렬 실행 (run_in_background=true)
+- scope 힌트로 탐색 범위를 제한하여 정확도 향상
+- MCP 프로필: `analyze` (읽기 전용 도구만)
+- 팀 모드 시: slim wrapper Agent로 spawn (Shift+Down 네비게이션)
+- 단일 모드 시: tfx-route.sh 직접 호출
+
+### Step 2.5.3: Opus 종합 판단 → 최종 계획 작성
+
+Lead(Opus)가 scout 보고를 종합하고, 전략적 설계 결정을 내린다:
+
+1. scout 결과 수집 (모든 scout 완료 대기)
+2. 아키텍처 선택, 트레이드오프 판단, 리스크 평가
+3. 최종 계획 작성
+4. `pipeline.writePlanFile(planContent)` 저장
+5. pipeline advance: plan → prd
+
+### Step 2.5.4: 추가 질의 루프 (선택)
+
+계획 작성 중 추가 정보 필요 시:
+- 팀 모드: 피드백 루프(Phase 0 구현)를 활용하여 scout에 "재실행:" 메시지 전송
+- 단일 모드: 추가 tfx-route.sh 호출
+- maxIterations 내에서 반복 가능 (기본 2회)
 
 ## Phase 2.6: PRD (Codex analyst)