tfx-deep-qalisted

# tfx-deep-qa — 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="기능 정확성 및 엣