tfx-interviewlisted

# tfx-interview — Quantified Socratic Requirements Exploration > **ARGUMENTS 처리**: 이 스킬이 `ARGUMENTS: <값>`과 함께 호출되면, 해당 값을 사용자 입력으로 취급하여 > 워크플로우의 첫 단계 입력으로 사용한다. ARGUMENTS가 비어있거나 없으면 기존 절차대로 사용자에게 입력을 요청한다. > OMC deep-interview + ouroboros 오마주. 모호성을 숫자로 측정하고 20% 미만까지 질문한다. > "측정할 수 없으면 개선할 수 없다." > > **Gemini 위임**: 분석·점수 계산·산출물 초안은 Gemini CLI에 위임하여 Claude 토큰을 절약한다. > 위임 패턴: `Bash("bash scripts/tfx-route.sh gemini exec '{prompt}'")` ## 위임 패턴 Claude와 Gemini의 역할을 분리하여 토큰을 최적화한다. | 담당 | 작업 | |------|------| | **Claude** | AskUserQuestion (사용자 상호작용), 최종 파일 저장 | | **Gemini** | 모호성 점수 계산, 질문 생성, 응답 분석, 산출물 초안 | ```bash # 위임 호출 형태 Bash("bash scripts/tfx-route.sh gemini exec '{prompt}'") ``` Gemini 실패 시 Fallback: Claude Opus가 분석을 직�� 처리한다. ## 용도 - 구현 전 요구사항 명확화 - 모호한 요청을 정량적으로 분석하여 실행 가능한 수준으로 구체화 - 빠진 제약 조건, 성공 기준, 경계 조건을 체계적으로 발견 - 과잉 구현/과소 구현 방지 ## 핵심: 모호성 점수 (Ambiguity Score) 요구사항의 모호성을 수학적으로 측정한다: ``` ambiguity = 1 - (goal × 0.40 + constraints × 0.30 + criteria × 0.30) 각 요소 (0.0 ~ 1.0): goal — 목표 명확도. "무엇을 달성하려는가?"가 명확한가? constraints — 제약 조건 명확도. 범위, 기술 스택, 시간, 호환성 등 criteria — 성공 기준 명확도. "어떻게 되면 완료인가?" 예시: 입력: "인증 기능 추가해" goal = 0.5 (인증이 무슨 인증? OAuth? JWT? 세션?) constraints = 0.2 (기술 스택? 기존 시스템 연동?) criteria = 0.1 (테스트? 성능? 보안 수준?) ambiguity = 1 - (0.5×0.40 + 0.2×0.30 + 0.1×0.30) = 1 - 0.29 = 0.71 (71%) 목표: ambiguity < 0.20 (20% 미만)이 될 때까지 질문 반복. ``` ## 워크플로우 ### Step 1: 초기 모호성 평가 사용자 입력을 Gemini에 전달하여 초기 ambiguity score를 계산한다: ```bash #