triflux 10.3.4 → 10.7.0

package/skills/tfx-deep-interview/SKILL.md.tmpl

@@ -0,0 +1,203 @@
+---
+name: tfx-deep-interview
+description: >
+  구현 전 소크라테스식 질의로 요구사항 깊이 탐색.
+  5단계 인터뷰를 통해 요구사항을 명확히 하고 최적 구현 경로를 도출합니다.
+triggers:
+  - deep-interview
+  - 딥인터뷰
+  - 소크라테스
+  - 깊이 탐색
+  - 요구사항 분석
+argument-hint: "<topic>"
+---
+
+# {{SKILL_NAME}} — 소크라테스식 깊이 탐색
+
+> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
+> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
+
+
+> 구현 전에 질문을 통해 요구사항의 깊이를 탐색합니다.
+> "좋은 답은 좋은 질문에서 나온다."
+
+## 사용법
+
+```
+/deep-interview 인증 시스템 리팩터링
+/deep-interview JWT 기반 세션 관리
+/딥인터뷰 데이터 파이프라인 설계
+```
+
+## 위임 패턴
+
+Claude 토큰을 절약하기 위해 분석 작업은 Gemini CLI에 위임합니다.
+
+- **Claude 담당**: AskUserQuestion (사용자 상호작용), 산출물 저장
+- **Gemini 담당**: 질문 생성, 응답 분석, 종합 문서 초안 작성
+
+각 단계에서 Claude는 누적 컨텍스트를 Gemini에 전달하고, Gemini가 반환한 질문을 AskUserQuestion으로 사용자에게 제시합니다. 사용자 답변은 다음 단계 Gemini 호출의 입력으로 전달됩니다.
+
+**Fallback**: Gemini 호출이 실패하면 Claude Opus가 모든 분석을 직접 수행합니다 (원래 동작 유지).
+
+## 토큰 예산
+
+| 담당 | 토큰 | 역할 |
+|------|------|------|
+| Claude | ~2K | 오케스트레이션 + AskUserQuestion만 |
+| Gemini | ~10K | 분석 + 질문 생성 + 문서 초안 |
+
+## 5단계 인터뷰 프로세스
+
+인터뷰는 반드시 아래 5단계를 순서대로 진행합니다. 각 단계에서 사용자 응답을 수집한 후 다음 단계로 이동합니다.
+
+### Stage 1: Clarify (명확화)
+
+> "정확히 무엇을 달성하려는가?"
+
+목표를 한 문장으로 정의하고, 성공 기준과 현재 상태의 차이를 파악합니다.
+
+**단계 진입 시 Gemini 위임:**
+
+```
+Bash("bash scripts/tfx-route.sh gemini exec 'Deep interview Stage 1: Clarify. Topic: {topic}. Previous answers: none. Generate 3 probing questions for this stage and analyze prior responses. Return JSON: {analysis, questions, key_insights}'")
+```
+
+Gemini가 반환한 `questions` 배열을 AskUserQuestion으로 사용자에게 제시합니다.
+
+**질문 템플릿 (Gemini 실패 시 Fallback):**
+
+1. "이 작업의 핵심 목표를 한 문장으로 설명해주세요."
+2. "완료 후 어떤 상태가 되어야 성공인가요?"
+3. "현재 상태에서 가장 큰 문제점은 무엇인가요?"
+
+### Stage 2: Decompose (분해)
+
+> "이것을 어떤 하위 문제로 나눌 수 있는가?"
+
+대상을 3-5개의 독립적 하위 문제로 분해하고, 의존성과 우선순위를 결정합니다.
+
+**단계 진입 시 Gemini 위임:**
+
+```
+Bash("bash scripts/tfx-route.sh gemini exec 'Deep interview Stage 2: Decompose. Topic: {topic}. Previous answers: {stage1_answers}. Generate 3 probing questions for this stage and analyze prior responses. Return JSON: {analysis, questions, key_insights}'")
+```
+
+Gemini가 반환한 `questions` 배열을 AskUserQuestion으로 사용자에게 제시합니다.
+
+**질문 템플릿 (Gemini 실패 시 Fallback):**
+
+1. "이 작업을 3-5개의 독립된 단계로 나눈다면?"
+2. "각 단계 사이에 의존성이 있나요?"
+3. "가장 먼저 해결해야 할 핵심 문제는?"
+
+### Stage 3: Challenge (반론)
+
+> "이 접근의 약점은?"
+
+선택한 접근 방식의 단점을 식별하고, 실패 시나리오와 기술 부채 가능성을 탐색합니다.
+
+**단계 진입 시 Gemini 위임:**
+
+```
+Bash("bash scripts/tfx-route.sh gemini exec 'Deep interview Stage 3: Challenge. Topic: {topic}. Previous answers: {stage1_answers} {stage2_answers}. Generate 3 probing questions for this stage and analyze prior responses. Return JSON: {analysis, questions, key_insights}'")
+```
+
+Gemini가 반환한 `questions` 배열을 AskUserQuestion으로 사용자에게 제시합니다.
+
+**질문 템플릿 (Gemini 실패 시 Fallback):**
+
+1. "이 방식이 실패할 수 있는 시나리오는?"
+2. "6개월 후 이 코드를 유지보수할 때 문제가 될 부분은?"
+3. "이 접근이 다른 시스템에 미치는 영향은?"
+
+### Stage 4: Alternatives (대안)
+
+> "다른 방법은?"
+
+최소 2개의 대안을 검토하고, 각 대안의 trade-off를 비교합니다.
+
+**단계 진입 시 Gemini 위임:**
+
+```
+Bash("bash scripts/tfx-route.sh gemini exec 'Deep interview Stage 4: Alternatives. Topic: {topic}. Previous answers: {stage1_answers} {stage2_answers} {stage3_answers}. Generate 3 probing questions for this stage and analyze prior responses. Return JSON: {analysis, questions, key_insights}'")
+```
+
+Gemini가 반환한 `questions` 배열을 AskUserQuestion으로 사용자에게 제시합니다.
+
+**질문 템플릿 (Gemini 실패 시 Fallback):**
+
+1. "같은 목표를 달성할 수 있는 완전히 다른 접근은?"
+2. "시간이 절반밖에 없다면 어떤 방식을 택하겠습니까?"
+3. "이 기술 대신 다른 것을 사용하면 어떤 trade-off가 있나요?"
+
+### Stage 5: Synthesize (종합)
+
+> "최적 경로는?"
+
+인터뷰 결과를 종합하여 실행 계획을 도출하고, 구조화된 요구사항 문서를 생성합니다.
+
+**단계 진입 시 Gemini 위임:**
+
+```
+Bash("bash scripts/tfx-route.sh gemini exec 'Deep interview Stage 5: Synthesize. Topic: {topic}. Previous answers: {stage1_answers} {stage2_answers} {stage3_answers} {stage4_answers}. Generate 3 probing questions for this stage and analyze prior responses. Return JSON: {analysis, questions, key_insights}'")
+```
+
+Gemini가 반환한 `questions` 배열을 AskUserQuestion으로 사용자에게 제시합니다.
+
+**질문 템플릿 (Gemini 실패 시 Fallback):**
+
+1. "지금까지의 논의를 종합하면, 최적의 접근 방식은?"
+2. "첫 번째 단계로 무엇을 실행하시겠습니까?"
+3. "이 결정에 대해 확신하는 정도는? (1-10)"
+
+## 산출물
+
+인터뷰 완료 후 Gemini가 전체 인터뷰 문서 초안을 생성하고, Claude가 Write 툴로 `.tfx/plans/interview-{timestamp}.md`에 저장합니다.
+
+**산출물 생성 Gemini 위임:**
+
+```
+Bash("bash scripts/tfx-route.sh gemini exec 'Deep interview complete. Topic: {topic}. All answers: {all_answers}. Generate a structured requirements document draft. Return the full markdown document.'")
+```
+
+Gemini 실패 시 Claude가 직접 아래 형식으로 문서를 작성합니다.
+
+### 산출물 형식
+
+```markdown
+# Interview: {topic}
+Date: {date}
+
+## Goal
+{1문장 목표}
+
+## Decomposition
+{하위 문제 목록}
+
+## Risks & Challenges
+{식별된 위험}
+
+## Alternatives Considered
+| 대안 | 장점 | 단점 |
+|------|------|------|
+| ... | ... | ... |
+
+## Decision
+{최종 결정 + 근거}
+
+## Action Plan
+1. {단계 1}
+2. {단계 2}
+3. ...
+```
+
+## 동작 규칙
+
+1. 각 단계에서 반드시 사용자 응답을 수집한 후 다음 단계로 이동합니다.
+2. 사용자가 명확한 답을 못 할 경우, 후속 질문으로 유도합니다.
+3. 단계를 건너뛰지 않습니다 (5단계 모두 필수).
+4. 이전 단계의 답변을 다음 단계 질문에 반영합니다 (대화형 연결).
+5. 최종 산출물은 항상 `.tfx/plans/interview-{timestamp}.md`에 마크다운 파일로 저장합니다.
+6. 인터뷰 시작 시 현재 주제와 관련된 코드베이스를 탐색하여 컨텍스트를 확보합니다.
+7. 각 단계 전환 시 이전 단계 요약을 한 줄로 보여줍니다.

package/skills/tfx-deep-plan/SKILL.md.tmpl

@@ -0,0 +1,282 @@
+---
+internal: true
+name: tfx-deep-plan
+description: "중요한 기능의 구현 계획을 3자 합의로 수립할 때 사용한다. 'deep plan', '합의 계획', 'ralplan', '철저한 계획', '제대로 설계하고 시작하자' 같은 요청에 사용. 마이크로서비스 도입, 대규모 리팩터링 등 리스크가 큰 작업의 사전 계획에 적극 활용."
+triggers:
+  - deep plan
+  - 합의 계획
+  - consensus plan
+  - deep-plan
+  - 철저한 계획
+  - ralplan
+argument-hint: "<구현할 기능 설명>"
+---
+
+# {{SKILL_NAME}} — Tri-Model Consensus Planning
+
+> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
+> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
+
+
+> **Light 버전**: tfx-plan. 기본값. 깊이 수정자 없으면 Light 선택.
+3개 모델(Opus 4.6 · GPT 5.4 · Gemini)이 독립 설계 후 교차검증하여 합의된 계획을 도출한다.
+
+---
+
+## 전제조건 프로브 및 Tier Degradation
+
+> **진입 즉시 실행** — 10초 내 가시적 출력을 보장한다. 빈 stdout + exit 0 **금지**.
+
+### 환경 프로브
+
+워크플로우 진입 전, 아래 프로브를 실행하여 가용 환경을 감지한다:
+
+```bash
+psmux --version 2>/dev/null && \
+  curl -sf http://127.0.0.1:27888/status >/dev/null && \
+  codex --version 2>/dev/null && \
+  gemini --version 2>/dev/null
+```
+
+### Tier 판정
+
+| Tier | 조건 | 실행 방식 |
+|------|------|----------|
+| **Tier 1** | psmux + Hub + Codex + Gemini 전부 정상 | 기존 headless multi (변경 없음) |
+| **Tier 2** | 일부 CLI만 가용 (Codex 또는 Gemini 중 하나) | 가용 CLI + Claude Agent 조합 |
+| **Tier 3** | headless 불가 또는 `claude -p` one-shot | Claude Agent only |
+
+```
+IF claude -p (one-shot 모드):
+  → Tier 3 즉시 fallback
+
+IF psmux 없음 OR Hub 미응답:
+  → Tier 3
+
+IF Codex 없음 AND Gemini 없음:
+  → Tier 3
+
+IF Codex 없음 OR Gemini 없음:
+  → Tier 2
+
+ELSE:
+  → Tier 1
+```
+
+### Tier 3 진입 시 필수 출력
+
+```
+⚠ [Tier 3] headless multi 환경 미충족 — single-model 모드로 실행합니다 (consensus 미적용)
+  누락: {missing_components}
+  권장: psmux, Hub, Codex CLI, Gemini CLI 설치 후 재실행
+```
+
+Tier 3에서는 모든 headless dispatch(`tfx multi ...`)를 **Claude Agent**(subagent)로 대체한다.
+Tier 2에서는 누락된 CLI만 Claude Agent로 대체한다.
+
+## HARD RULES
+
+> headless-guard가 이 규칙 위반을 **자동 차단**한다. 우회 불가.
+
+1. **`codex exec` / `gemini -p` 직접 호출 절대 금지**
+2. Codex·Gemini 작업은 반드시 아래 형식으로만 실행:
+   `Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'cli:프롬프트:역할' --timeout 600")`
+3. Claude 작업은 `Agent(run_in_background=true)`
+4. Step 2, Step 4에서 **Bash + Agent를 같은 메시지에서 동시 호출**하여 3개 모델 병렬 실행
+
+## MODEL ROLES
+
+| Model | Profile | 역할 | 강점 |
+|-------|---------|------|------|
+| **Claude Opus 4.6** | Agent(model="opus") | Planner | 전략적 아키텍처 비전, 리스크 통합 판단 |
+| **Codex GPT 5.4** | `--assign 'codex:...:architect'` (gpt54_xhigh) | Architect | 구현 설계, API 인터페이스, 파일 구조 |
+| **Gemini** | `--assign 'gemini:...:critic'` | Critic | 엣지케이스, 보안 위협, 테스트 전략 |
+
+---
+
+## EXECUTION — 아래 Step을 순서대로 실행하라
+
+사용자 입력을 `TASK`로 참조한다.
+
+### Step 1: 코드베이스 정찰
+
+TASK와 관련된 코드베이스를 파악한다. 결과를 `RECON`으로 기억한다.
+
+도구 호출:
+```
+Agent(
+  subagent_type="Explore",
+  model="haiku",
+  description="codebase recon",
+  prompt="다음 기능과 관련된 코드베이스를 탐색하라: [TASK 삽입]
+  보고할 것: (1) 관련 파일/디렉토리 (2) 기존 아키텍처 패턴 (3) 주요 의존성/인터페이스. bullet point로 간결하게."
+)
+```
+
+### Step 2: Round 1 — 독립 설계 (Anti-Herding)
+
+3개 모델이 서로의 결과를 **보지 않고** 동시에 독립 분석한다.
+**아래 2개 도구를 반드시 같은 응답에서 동시에 호출하라.**
+
+#### 2a. Claude Opus — Planner (Agent, background)
+
+```
+Agent(
+  subagent_type="oh-my-claudecode:architect",
+  model="opus",
+  run_in_background=true,
+  name="planner-r1",
+  description="deep-plan R1 Planner",
+  prompt="소프트웨어 아키텍트로서 구현 계획을 수립하라.
+
+기능: [TASK 삽입]
+코드베이스: [RECON 삽입]
+
+아래 JSON으로 응답하라:
+{
+  \"vision\": \"설계 방향 1-2문장\",
+  \"tasks\": [{\"id\": \"T1\", \"title\": \"...\", \"desc\": \"...\", \"deps\": [], \"complexity\": \"low|med|high\"}],
+  \"order\": [\"T1\", \"T2\"],
+  \"risks\": [{\"id\": \"R1\", \"desc\": \"...\", \"severity\": \"critical|high|med|low\", \"mitigation\": \"...\"}],
+  \"files\": [{\"path\": \"...\", \"action\": \"create|modify|delete\", \"reason\": \"...\"}],
+  \"confidence\": 0.85,
+  \"reasoning\": \"핵심 결정 이유\"
+}"
+)
+```
+
+#### 2b. Codex + Gemini — Architect + Critic (headless)
+
+`TASK`와 `RECON`을 프롬프트에 삽입하여 아래 Bash를 호출한다.
+프롬프트 안의 작은따옴표는 `'\''`로 이스케이프한다.
+
+```
+Bash("tfx multi --teammate-mode headless --auto-attach --dashboard \
+  --assign 'codex:시니어 엔지니어로서 기술적 설계를 작성하라. 기능: [TASK]. 코드베이스: [RECON]. JSON 응답: {\"architecture\": \"패턴+이유\", \"components\": [{\"name\": \"\", \"responsibility\": \"\", \"interfaces\": []}], \"data_models\": [{\"name\": \"\", \"fields\": [], \"relations\": []}], \"api\": [{\"endpoint\": \"\", \"method\": \"\", \"desc\": \"\"}], \"files\": [{\"path\": \"\", \"purpose\": \"\"}], \"impl_notes\": [], \"confidence\": 0.85}:architect' \
+  --assign 'gemini:QA 보안 전문가로서 구현 리스크를 분석하라. 기능: [TASK]. 코드베이스: [RECON]. JSON 응답: {\"edge_cases\": [{\"id\": \"E1\", \"scenario\": \"\", \"impact\": \"\", \"fix\": \"\"}], \"security\": [{\"id\": \"S1\", \"threat\": \"\", \"severity\": \"critical|high|med|low\", \"mitigation\": \"\"}], \"performance\": [{\"id\": \"P1\", \"bottleneck\": \"\", \"optimization\": \"\"}], \"test_strategy\": {\"unit\": [], \"integration\": [], \"edge_case\": []}, \"missing_reqs\": [], \"risk_level\": \"low|med|high|critical\", \"confidence\": 0.85}:critic' \
+  --timeout 600")
+```
+
+### Step 3: 결과 수집
+
+- `RESULT_PLANNER`: planner-r1 Agent 결과 (SendMessage로 수신 또는 완료 알림 대기)
+- `RESULT_ARCHITECT` + `RESULT_CRITIC`: headless stdout JSON에서 각 워커 출력 추출
+
+**실패 워커 처리**: 워커가 실패하면 Claude Agent로 해당 역할을 대체 실행한다.
+
+### Step 4: Round 2 — 교차 검토
+
+각 모델에게 다른 두 모델의 Round 1 결과를 제시하고 수용/수정/반박을 요청한다.
+**아래 2개 도구를 반드시 같은 응답에서 동시에 호출하라.**
+
+#### 4a. Claude Opus — 계획 수정 (Agent, background)
+
+```
+Agent(
+  subagent_type="oh-my-claudecode:critic",
+  model="opus",
+  run_in_background=true,
+  name="planner-r2",
+  description="deep-plan R2 cross-review",
+  prompt="Round 1 결과를 교차 검토하고 계획을 수정하라.
+
+네 계획: [RESULT_PLANNER 삽입]
+Architect(Codex) 설계: [RESULT_ARCHITECT 삽입]
+Critic(Gemini) 분석: [RESULT_CRITIC 삽입]
+
+각 항목에 대해:
+- ACCEPT: 수용 (이유)
+- MODIFY: 부분 수정 (원안→수정안, 이유)
+- REJECT: 반박 (근거)
+
+JSON: {\"revisions\": [{\"source\": \"codex|gemini\", \"item\": \"...\", \"action\": \"accept|modify|reject\", \"reason\": \"...\"}], \"updated_plan\": {같은 스키마}}"
+)
+```
+
+#### 4b. Codex + Gemini — 교차 검토 (headless)
+
+3개 Round 1 결과를 각 프롬프트에 삽입한다. 결과가 길면 핵심만 요약하여 삽입.
+
+```
+Bash("tfx multi --teammate-mode headless --auto-attach --dashboard \
+  --assign 'codex:교차 검토하라. Planner 계획: [RESULT_PLANNER 요약]. 네 설계: [RESULT_ARCHITECT 요약]. Critic 분석: [RESULT_CRITIC 요약]. 각 항목 ACCEPT/MODIFY/REJECT + 이유. JSON: {\"revisions\": [...], \"updated_design\": {같은 스키마}}:architect' \
+  --assign 'gemini:교차 검토하라. Planner 계획: [RESULT_PLANNER 요약]. Architect 설계: [RESULT_ARCHITECT 요약]. 네 분석: [RESULT_CRITIC 요약]. 우려 해소 여부 판단. JSON: {\"resolved\": [...], \"still_concerned\": [...], \"new_concerns\": [...], \"updated_test_strategy\": {...}}:critic' \
+  --timeout 600")
+```
+
+### Step 5: 합의 점수 산출
+
+Round 2 결과를 모아 Claude가 직접 계산한다 (Agent 불필요):
+
+```
+모든 고유 항목에 대해:
+  동의 수 = 해당 항목에 동의한 모델 수 (ACCEPT 또는 유사 제안)
+
+  >= 2 동의 → CONSENSUS (합의)
+  == 1 동의 → DISPUTED (미합의)
+
+consensus_score = CONSENSUS / 전체_고유_항목 * 100
+
+분기:
+  >= 80% → Step 6 확정
+  60-79% → Round 3 진행 (미합의 항목만 재토론, 같은 headless 패턴)
+  < 60%  → AskUserQuestion으로 핵심 불일치 제시, 사용자 판단 요청
+```
+
+### Step 6: 합의된 계획 출력
+
+아래 형식으로 최종 결과를 출력한다:
+
+```markdown
+## 합의된 구현 계획: [TASK]
+
+**Consensus**: {score}% | **Rounds**: {count} | **Models**: Opus 4.6 + GPT 5.4 + Gemini
+
+### 설계 방향
+{3자 합의된 아키텍처 결정}
+
+### 태스크
+| # | 태스크 | 복잡도 | 합의 | 비고 |
+|---|--------|--------|------|------|
+| T1 | {title} | {complexity} | P:✓ A:✓ C:✓ | {notes} |
+
+### 파일 변경
+| 파일 | 작업 | 이유 |
+|------|------|------|
+| {path} | {action} | {reason} |
+
+### 리스크 & 완화
+| 리스크 | 심각도 | 완화 | 합의 |
+|--------|--------|------|------|
+| {risk} | {severity} | {mitigation} | {n}/3 |
+
+### 테스트 전략 (Critic 주도)
+{Gemini가 제안하고 나머지가 합의한 테스트 계획}
+
+### 미합의 사항
+| 항목 | Planner(Opus) | Architect(GPT5.4) | Critic(Gemini) |
+|------|---------------|---------------------|----------------|
+| {item} | {position} | {position} | {position} |
+```
+
+---
+
+## ERROR RECOVERY
+
+| 상황 | 대응 |
+|------|------|
+| headless timeout (600s) | Claude Agent로 해당 역할 대체 실행 |
+| Codex 워커 실패 | `Agent(subagent_type="oh-my-claudecode:architect", model="opus")` 대체 |
+| Gemini 워커 실패 | `Agent(subagent_type="oh-my-claudecode:critic", model="sonnet")` 대체 |
+| consensus < 60% | AskUserQuestion → 사용자 방향 결정 후 해당 방향으로 확정 |
+| 프롬프트 quoting 오류 | 작은따옴표 → `'\''` 이스케이프. 줄바꿈 → 공백 치환 |
+
+## TOKEN BUDGET
+
+| Phase | Tokens |
+|-------|--------|
+| Step 1: Recon (Haiku) | ~2K |
+| Step 2: Round 1 (3 parallel) | ~15K |
+| Step 4: Round 2 (3 parallel) | ~12K |
+| Step 5-6: Consensus + Output | ~3K |
+| **Total** | **~25-32K** |

package/skills/tfx-deep-qa/SKILL.md.tmpl

@@ -0,0 +1,165 @@
+---
+internal: true
+name: tfx-deep-qa
+description: "보안, 성능, 접근성까지 포함한 철저한 검증이 필요할 때 사용한다. 'deep qa', '심층 검증', '철저히 테스트', '보안까지 확인', '전방위 검증' 같은 요청에 사용. 프로덕션 배포 전 다각도 품질 검증에 적극 활용."
+triggers:
+  - deep qa
+  - 심층 검증
+  - thorough test
+  - deep-qa
+argument-hint: "[테스트 대상 경로 또는 기능 설명]"
+---
+
+# {{SKILL_NAME}} — Tri-CLI Deep Verification
+
+> **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여
+> 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다.
+
+
+> **Light 버전**: tfx-qa. 기본값. 깊이 수정자 없으면 Light 선택.
+> 3-CLI 독립 검증 → 교차검증 → 2+ 합의 항목만 보고. false-positive 87% 감소.
+
+## 핵심 원리
+
+**Anti-Herding**: 3개 CLI가 서로의 결과를 보지 않고 독립 검증.
+**Consensus Only**: 2개 이상 CLI가 동일 이슈를 지적한 항목만 최종 보고.
+
+## 용도
+
+- 릴리스 전 전면 검증
+- 보안/성능/접근성을 동시에 다각도 점검
+- 단일 CLI 검증으로는 놓치는 교차 영역 결함 탐지
+- false-positive 최소화가 필요한 QA 게이트
+
+## HARD RULES
+
+> headless-guard가 이 규칙 위반을 **자동 차단**한다. 우회 불가.
+
+1. **`codex exec` / `gemini -p` 직접 호출 절대 금지**
+2. Codex·Gemini → `Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'cli:프롬프트:역할' --timeout 600")` **만** 사용
+3. Claude → `Agent(run_in_background=true)`
+4. Bash + Agent를 같은 메시지에서 동시 호출하여 병렬 실행
+
+## MODEL ROLES
+
+| CLI | 역할 | 관점 |
+|-----|------|------|
+| Claude Opus | 기능검증 | 기능 정확성, 엣지케이스, 누락 테스트 |
+| Codex | 보안+성능 | OWASP Top 10, O(n²) 복잡도, 메모리 누수, 입력 검증 |
+| Gemini | UX+접근성 | API 응답 일관성, 에러 메시지, WCAG 2.1 AA |
+
+## EXECUTION STEPS
+
+### Step 1: 검증 대상 수집
+
+대상을 다음 우선순위로 결정한다:
+1. 사용자 지정 파일/경로 → 해당 범위
+2. `git diff` (staged + unstaged) → 변경된 파일
+3. 지정 없음 → 프로젝트 전체 테스트
+
+수집 항목: 변경 파일 목록 + diff, 관련 테스트 파일, 영향 받는 모듈/의존성
+
+### Step 2: 3-CLI 독립 검증 — 아래 2개 도구를 반드시 같은 응답에서 동시에 호출하라.
+
+**Claude Agent (기능검증):**
+```
+Agent(
+  subagent_type="oh-my-claudecode:verifier",
+  model="opus",
+  run_in_background=true,
+  name="qa-functional",
+  description="기능 정확성 및 엣지케이스 검증",
+  prompt="QA 엔지니어로서 다음 코드의 기능 정확성을 검증하라. 테스트를 실행하고 결과를 보고하라. 누락된 엣지 케이스를 식별하라 (null, 빈 입력, 경계값, 동시성). 누락된 테스트 케이스를 제안하라. JSON으로 응답하라: { test_result: {pass, fail, skip}, findings: [{id, file, line, category, severity, description, test_scenario}], edge_case_tests: [...], overall_verdict: 'pass'|'fail' }"
+)
+```
+
+**Codex + Gemini headless dispatch (보안+성능+UX):**
+```
+Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'codex:보안/성능 전문가로서 이 코드를 검증하라. OWASP Top 10을 체크하라. O(n²) 이상 복잡도를 탐지하라. 메모리 누수 패턴을 찾아라. 입력 검증 누락을 확인하라. JSON으로 응답하라: { findings: [{id, file, line, category, severity, description, fix}], overall_verdict: \"pass\"|\"fail\" }:verifier' --assign 'gemini:UX/접근성 전문가로서 이 코드를 검증하라. API 응답 형식 일관성을 확인하라. 에러 메시지의 사용자 친화성을 평가하라. WCAG 2.1 AA 준수를 검토하라 (UI 관련 시). 문서와 실제 동작 일치 여부를 확인하라. JSON으로 응답하라: { findings: [{id, file, line, category, severity, description, suggestion}], overall_verdict: \"pass\"|\"fail\" }:verifier' --timeout 600")
+```
+
+### Step 3: Consensus Scoring
+
+모든 findings를 수집하여 유사도를 비교한다:
+- 동일 파일+라인±5 + 유사 카테고리 → 동일 이슈로 간주
+- 3/3 합의 → CONFIRMED (severity 유지)
+- 2/3 합의 → LIKELY (severity 유지, 반대 의견 첨부)
+- 1/3만 지적 → UNVERIFIED (참고용, 별도 섹션)
+
+`consensus_score = consensus_items / total_unique_items × 100`
+
+### Step 4: 실패 수정 — 합의된 Critical/High 항목에 대해서만 실행
+
+```
+Bash("tfx multi --teammate-mode headless --auto-attach --dashboard --assign 'codex:다음 합의된 이슈들을 수정하라. 각 이슈에 대해 최소한의 변경으로 수정하고 수정 후 테스트를 재실행하여 통과 여부를 확인하라. 이슈 목록: {consensus_findings}:fixer' --timeout 300")
+```
+
+### Step 5: 종합 보고서 작성
+
+아래 형식으로 보고서를 출력한다:
+
+```markdown
+## Deep QA Report: {target}
+**Consensus Score**: {score}% | **Verifiers**: Claude/Codex/Gemini
+**Verdict**: PASS / CONDITIONAL PASS / FAIL
+
+### Critical (3/3 합의)
+- [C1] `{file}:{line}` — {description}
+  - Claude: {detail} | Codex: {detail} | Gemini: {detail}
+  - **Fix**: {applied_fix}
+
+### High (2/3 합의)
+- [H1] `{file}:{line}` — {description}
+  - 합의: {agreers} | 반대: {dissenter}: "{reason}"
+
+### Verified Medium
+- ...
+
+### 엣지 케이스 테스트 제안
+| 시나리오 | 입력 | 기대 결과 | 제안자 |
+|---------|------|----------|--------|
+| {scenario} | {input} | {expected} | Claude |
+
+### Unverified (1/3만 지적, 참고용)
+- [U1] `{file}:{line}` — {description} (by {single_cli})
+
+### 수정 요약
+- 수정된 파일: {list}
+- 테스트 재실행 결과: {pass}/{total}
+
+### 검증 통계
+| CLI | 영역 | 발견 수 | 합의 기여율 |
+|-----|------|---------|------------|
+| Claude | 기능/엣지케이스 | {n} | {%} |
+| Codex | 보안/성능 | {n} | {%} |
+| Gemini | UX/접근성 | {n} | {%} |
+```
+
+## ERROR RECOVERY
+
+| 오류 | 조치 |
+|------|------|
+| headless dispatch 타임아웃 | `--timeout` 값을 900으로 올려 재시도 |
+| Agent 결과 미수신 | Step 2를 Agent만 단독 재실행 |
+| consensus 0% | 대상 범위가 너무 넓음 — 파일 단위로 분할 후 재실행 |
+| tfx multi 명령 실패 | `tfx status`로 teammate 연결 상태 확인 |
+
+## 토큰 예산
+
+| 단계 | 토큰 |
+|------|------|
+| Step 1 (수집) | ~1K |
+| Step 2 (3x 독립 검증) | ~15K |
+| Step 3 (Consensus) | ~3K |
+| Step 4 (수정) | ~3K |
+| Step 5 (보고) | ~3K |
+| **총합** | **~25K** |
+
+## 사용 예
+
+```
+/tfx-deep-qa
+/tfx-deep-qa "src/auth/ 디렉토리 전체"
+/tfx-deep-qa "최근 커밋 변경사항 심층 검증"
+/tfx-deep-qa "결제 모듈 배포 전 최종 검증"
+```

package/skills/tfx-deep-qa/skill.json

@@ -1,12 +1,7 @@
 {
   "name": "tfx-deep-qa",
   "description": "보안, 성능, 접근성까지 포함한 철저한 검증이 필요할 때 사용한다. 'deep qa', '심층 검증', '철저히 테스트', '보안까지 확인', '전방위 검증' 같은 요청에 사용. 프로덕션 배포 전 다각도 품질 검증에 적극 활용.",
-  "triggers": [
-    "deep qa",
-    "심층 검증",
-    "thorough test",
-    "deep-qa"
-  ],
+  "triggers": ["deep qa", "심층 검증", "thorough test", "deep-qa"],
   "argument_hint": "[테스트 대상 경로 또는 기능 설명]",
   "internal": true
 }