Imported from daekeun-ml/claude-ml-plugins (plugins/ml-research-toolkit/skills/deep-interview/SKILL.md). Install upstream with npx skills add daekeun-ml/claude-ml-plugins --skill deep-interview. Copyright stays with the author.

LLM/VLM 연구 컨텍스트에 특화:

모델 수정 아이디어: 새로운 모듈, 손실 함수, 학습 전략
실험 설계: 베이스라인, 어블레이션 축, 평가 프로토콜
구현 계획: 기존 코드베이스(VisEngram 등) 위에 추가/수정

출력은 3단계 파이프라인으로 연결됩니다: deep-interview → omc-plan (합의 정제) → autopilot (실행)

<Use_When>

연구 아이디어가 있지만 구체적인 구현 방법이 불명확할 때
"deep interview", "인터뷰", "아이디어 있는데 어떻게 구현하지?" 라고 말할 때
실험 설계 전에 가설-검증 구조를 명확히 하고 싶을 때
기존 코드(vlm.py, hash_table.py 등)에 어떻게 연결할지 모를 때
"그게 아니라는데" 결과를 방지하고 싶을 때 </Use_When>

<Do_Not_Use_When>

파일 경로, 함수 이름, 구체적인 수용 기준이 명시된 구체적인 요청 — 직접 실행
옵션 탐색 또는 브레인스토밍 — omc-plan 스킬 사용
간단한 버그 수정이나 단일 변경 — executor나 ralph에 위임
"그냥 해줘"라고 말할 때 — 의도를 존중
이미 PRD나 계획 파일이 있을 때 — ralph나 autopilot 사용 </Do_Not_Use_When>

<Why_This_Exists> AI는 무엇이든 구현할 수 있습니다. 어려운 부분은 무엇을 구현할지 아는 것입니다.

LLM/VLM 연구에서 모호한 아이디어로 바로 코드를 짜면:

잘못된 베이스라인과 비교 → 무효 결과
핵심 하이퍼파라미터 미정 → 재실험 낭비
평가 프로토콜 불일치 → 논문 리뷰에서 지적
기존 코드와의 인터페이스 불명확 → 리팩토링 반복

Deep Interview는 소크라테스 방식으로 이 가정들을 표면화하고, 수학적으로 명확도를 게이팅해 실행 전에 스펙을 완성합니다. </Why_This_Exists>

<Execution_Policy>

한 번에 질문 하나만 — 절대 여러 질문 묶음 금지
매 라운드 가장 약한 명확도 차원을 목표로
약한 차원 타겟팅을 명시적으로: 어떤 차원인지, 점수/갭, 왜 다음 질문이 거기를 겨냥하는지
코드베이스 사실은 explore 에이전트로 먼저 수집 후 질문
브라운필드 확인 질문은 repo 증거 인용 (파일 경로, 심볼, 패턴)
매 답변 후 모호도 점수 계산 — 투명하게 표시
모호도 ≤ 임계값 전까지 실행으로 진행하지 않음
모호도가 높아도 명확한 경고와 함께 조기 종료 허용
세션 중단 시 재개를 위해 인터뷰 상태 저장
특정 라운드 임계값에서 챌린지 에이전트 활성화 </Execution_Policy>

Phase 1: 초기화

사용자 아이디어 파싱 ({{ARGUMENTS}})
브라운필드 vs 그린필드 감지:
- explore 에이전트(haiku) 실행: 현재 디렉토리에 기존 소스 코드가 있는지 확인
- 소스 파일이 있고 사용자 아이디어가 수정/확장을 참조하면: 브라운필드
- 아니면: 그린필드
브라운필드의 경우: explore 에이전트로 관련 코드 영역 매핑, codebase_context로 저장 3.5. 런타임 설정 로드:
- omc.deepInterview.ambiguityThreshold 읽기; 미정의 시 0.2 사용 → <resolvedThreshold>
상태 초기화 state_write(mode="deep-interview"):

{
  "active": true,
  "current_phase": "deep-interview",
  "state": {
    "interview_id": "<uuid>",
    "type": "greenfield|brownfield",
    "initial_idea": "<프롬프트 안전한 초기 컨텍스트 요약 또는 사용자 입력>",
    "rounds": [],
    "current_ambiguity": 1.0,
    "threshold": "<resolvedThreshold>",
    "codebase_context": null,
    "challenge_modes_used": [],
    "ontology_snapshots": []
  }
}

인터뷰 시작 안내:

Deep Interview를 시작합니다. 구현 전에 아이디어를 완전히 이해하기 위해 집중 질문을 드립니다. 매 답변 후 명확도 점수를 보여드립니다. 모호도가 <resolvedThresholdPercent>% 아래로 내려가면 실행으로 넘어갑니다.

아이디어: "{initial_idea}" 프로젝트 유형: {그린필드|브라운필드} 현재 모호도: 100% (아직 시작 전)

Phase 2: 인터뷰 루프

ambiguity ≤ threshold 또는 사용자가 조기 종료할 때까지 반복:

Step 2a: 다음 질문 생성

질문 생성 프롬프트 구성:

프롬프트 안전한 초기 컨텍스트 요약
이전 Q&A 라운드 (예산 내로 요약)
차원별 현재 명확도 점수 (가장 약한 차원은?)
챌린지 에이전트 모드 (활성화된 경우)
브라운필드 코드베이스 컨텍스트 (해당 시)

질문 타겟팅 전략 (LLM/VLM 연구 특화):

차원	질문 스타일	예시
목표 명확도	"이 방법이 정확히 무엇을 해결하나요?"	"이 접근이 기존 방법 대비 어떤 근본적 한계를 극복하려는 건가요 — 표현력 부족인가요, 학습 효율인가요, 아니면 일반화인가요?"
제약 명확도	"어떤 경계가 있나요?"	"추가 파라미터 예산이 있나요? 기존 백본을 frozen으로 유지해야 하나요, 아니면 fine-tuning도 허용하나요?"
성공 기준	"어떻게 개선됐다는 걸 알 수 있나요?"	"어떤 벤치마크에서 얼마나 개선되면 유의미하다고 보시나요? 어블레이션에서 어떤 패턴이 나와야 이 가설이 맞다고 볼 수 있나요?"
컨텍스트 명확도 (브라운필드)	"기존 코드/실험과 어떻게 연결되나요?"	"기존 학습 파이프라인에 추가하는 건가요, 아니면 새 학습 루프가 필요한가요? mid-train과 SFT 중 어느 단계에서 적용하나요?"
스코프 퍼지 / 온톨로지	"이게 근본적으로 무엇인가요?"	"지난 라운드에서 '어텐션 개선', '표현 학습', '메모리 효율'이라는 표현이 섞였는데 — 이 방법의 핵심 메커니즘을 한 문장으로 표현하면 무엇인가요?"

Step 2b: 질문하기

AskUserQuestion으로 생성된 질문 제시:

라운드 {n} | 타겟: {weakest_dimension} | 이유: {one_sentence_targeting_rationale} | 모호도: {score}%

{question}

Step 2c: 모호도 점수 계산

사용자 답변 후 모든 차원의 명확도 점수 계산.

그린필드 모호도: 1 - (goal×0.40 + constraints×0.30 + criteria×0.30) 브라운필드 모호도: 1 - (goal×0.35 + constraints×0.25 + criteria×0.25 + context×0.15)

Step 2d: 진행 상황 보고

라운드 {n} 완료.

| 차원 | 점수 | 가중치 | 가중 합계 | 갭 |
|------|------|--------|----------|-----|
| 목표 명확도 | {s} | {w} | {s*w} | {gap 또는 "명확"} |
| 제약 명확도 | {s} | {w} | {s*w} | {gap 또는 "명확"} |
| 성공 기준 | {s} | {w} | {s*w} | {gap 또는 "명확"} |
| 컨텍스트 (브라운필드) | {s} | {w} | {s*w} | {gap 또는 "명확"} |
| **모호도** | | | **{score}%** | |

**온톨로지:** {entity_count}개 엔티티 | 안정도: {stability_ratio} | 신규: {new} | 변경: {changed} | 안정: {stable}

**다음 타겟:** {weakest_dimension} — {weakest_dimension_rationale}

{score <= threshold ? "명확도 임계값 달성! 진행 가능합니다." : "다음 질문은 {weakest_dimension}에 집중합니다."}

Step 2e: 상태 업데이트

state_write로 새 라운드와 점수 저장.

Step 2f: 소프트 한계 확인

라운드 3+: 사용자가 "충분해", "시작해", "그냥 해줘" 라고 하면 조기 종료 허용
라운드 10: 소프트 경고: "10라운드입니다. 현재 모호도: {score}%. 계속하시겠습니까?"
라운드 20: 하드 캡: "최대 인터뷰 라운드 도달. 현재 명확도 수준({score}%)으로 진행합니다."

Phase 3: 챌린지 에이전트 (LLM/VLM 연구 특화)

라운드 4+: 반론 모드

반론 모드: 사용자의 핵심 가정에 도전합니다. "반대가 사실이라면?" 또는 "이 제약이 실제로 존재하지 않는다면?" 형식.

예: "이 방법이 정말 필요한지 먼저 질문하고 싶습니다. 단순히 더 많은 학습 데이터나 longer context를 쓰는 것만으로도 같은 효과를 낼 수 있다면 어떻게 되나요? 이 메커니즘이 scale-up으로는 해결 안 되는 구조적 한계를 다루는 건지 먼저 확인하는 게 중요합니다."

라운드 6+: 단순화 모드

단순화 모드: 복잡도를 제거할 수 있는지 탐색.

예: "논문에 넣을 수 있는 가장 단순한 베이스라인은 무엇인가요? 제안한 방법에서 핵심 컴포넌트 하나만 남기고 나머지를 제거했을 때 여전히 의미 있는 개선이 나올까요? 그게 ablation의 출발점이 됩니다."

라운드 8+ (모호도 > 0.3): 온톨로지 모드

온톨로지 모드: 8라운드 후에도 모호도가 높으면 개념 자체가 불안정한 것.

예: "지금까지 '표현 개선', '어텐션 효율화', '정보 압축'이라는 표현이 혼재했습니다. 추적된 엔티티: {current_entities_summary}. 이 방법의 핵심이 representation learning인가요, inference efficiency인가요, 아니면 training objective 설계인가요? 범주가 달라지면 베이스라인과 평가 지표가 완전히 달라집니다."

Phase 4: 스펙 결정화

모호도 ≤ 임계값 (또는 하드 캡 / 조기 종료)이 되면:

스펙 생성 (opus 모델, 프롬프트 안전 전사본 사용)
파일 저장: .omc/specs/deep-interview-{slug}.md

스펙 구조:

# Deep Interview 스펙: {title}

## 메타데이터
- 인터뷰 ID: {uuid}
- 라운드: {count}
- 최종 모호도 점수: {score}%
- 유형: 그린필드 | 브라운필드
- 생성일: {timestamp}
- 임계값: {threshold}

## 명확도 분석
| 차원 | 점수 | 가중치 | 가중 합계 |
|------|------|--------|----------|

## 목표
{인터뷰에서 도출된 명확한 목표 진술}

## 연구 가설
{검증 가능한 형태로: "X를 추가하면 Y 벤치마크에서 Z% 개선을 기대한다"}

## 제약 조건
- {제약 1} (예: 추가 파라미터 < 500K)
- {제약 2} (예: 기존 mid-train 파이프라인 호환)

## 비목표 (명시적 제외 범위)
- {제외 1}

## 수용 기준 (실험 성공 조건)
- [ ] {측정 가능한 기준 1} (예: ChartQA +2% vs 베이스라인)
- [ ] {어블레이션 기준} (예: TAB만 제거 시 성능 하락 확인)
- [ ] {구현 기준} (예: 기존 테스트 통과)

## 드러나고 해결된 가정
| 가정 | 챌린지 | 해결 방법 |
|------|--------|---------|

## 기술 컨텍스트 (브라운필드)
{explore 에이전트가 찾은 관련 코드 위치}
- 수정 파일: {file:line}
- 인터페이스 포인트: {함수명, 클래스명}
- 기존 유사 구현: {참고 코드}

## 실험 구성
| 구성 | 설명 | mid-train 스크립트 | SFT 스크립트 |
|------|------|-----------------|------------|

## 온톨로지 (핵심 엔티티)
| 엔티티 | 유형 | 필드 | 관계 |
|--------|------|------|------|

## 인터뷰 전사본
<details>
<summary>전체 Q&A ({n} 라운드)</summary>
...
</details>

Phase 5: 실행 브릿지

스펙 작성 후 AskUserQuestion으로 실행 옵션 제시:

질문: "스펙이 준비됐습니다 (모호도: {score}%). 어떻게 진행하시겠습니까?"

옵션:

Ralplan → Autopilot (권장)
- 설명: "3단계 파이프라인: 이 스펙을 Planner/Architect/Critic으로 합의 정제 후 전체 autopilot 실행."
- 액션: Skill("oh-my-claudecode:omc-plan") with --consensus --direct + 스펙 파일 경로
Autopilot으로 바로 실행 (ralplan 건너뜀)
- 설명: "전체 자율 파이프라인 — 계획, 병렬 구현, QA, 검증. 빠르지만 합의 정제 없음."
- 액션: Skill("oh-my-claudecode:autopilot") with 스펙 파일 경로
Ralph로 실행
- 설명: "지속성 루프 + 아키텍트 검증 — 모든 수용 기준이 통과할 때까지 계속 작업"
- 액션: Skill("oh-my-claudecode:ralph") with 스펙 파일 경로
더 구체화하기
- 설명: "인터뷰를 계속해 명확도 향상 (현재: {score}%)"
- 액션: Phase 2 인터뷰 루프로 복귀

IMPORTANT: 실행 선택 시 반드시 Skill()로 선택된 스킬 호출. 직접 구현 금지.

<Tool_Usage>

AskUserQuestion: 각 인터뷰 질문 제시
Task(subagent_type="oh-my-claudecode:explore", model="haiku"): 브라운필드 코드베이스 탐색 (사용자에게 묻기 전에 실행)
opus 모델 (temperature 0.1): 모호도 점수 계산 — 일관성이 중요
state_write / state_read: 인터뷰 상태 저장
Write: 최종 스펙을 .omc/specs/에 저장
Skill(): 실행 모드 브릿지 — 직접 구현 금지 </Tool_Usage>

점수: 목표=0.9, 제약=0.4, 기준=0.7
다음 질문은 제약(최저 0.4) 타겟:

"이 모듈을 추가할 때 백본 파라미터를 함께 업데이트하나요,
아니면 frozen 상태로 새 모듈만 학습하나요?
두 방식은 학습 안정성과 GPU 메모리 요구사항이 크게 달라집니다."

왜 좋은가: 약한 차원 식별, 왜 이게 병목인지 설명, 결정이 다운스트림에 미치는 영향까지 명시.

[explore 에이전트 실행: "find training loop and optimizer setup in train script"]
[결과: "2_train_visengram_mhc.py:259 — engram_modules만 optimizer에 등록, base model frozen"]

질문: "현재 학습 루프는 engram_modules만 optimizer에 등록합니다.
새 모듈도 같은 파라미터 그룹에 넣을 건가요,
아니면 별도 learning rate를 써야 하는 이유가 있나요?"

왜 좋은가: explore로 먼저 파악 후 repo 증거 인용. 사용자에게 코드가 이미 알려주는 것을 묻지 않음.

라운드 5 | 반론 모드 | 모호도: 38%

이 방법이 cross-attention을 개선한다고 하셨는데 —
만약 더 많은 학습 데이터나 더 긴 학습만으로도 같은 효과를 낼 수 있다면
어떻게 되나요? 이 메커니즘이 데이터/compute 확장으로는 해결 안 되는
구조적 한계를 다루는 것인지, 아니면 sample efficiency 개선인지
먼저 구분하는 게 중요할 것 같습니다.

왜 좋은가: 연구에서 흔한 "구조 개선 vs 스케일 업" 혼동에 도전. 논문 포지셔닝을 사전에 명확히 함.

사용자: "그냥 시작해, 실험해보면서 결정하자"
시스템: "현재 모호도 32% (임계값: 20%). 아직 불명확한 부분:
  - 성공 기준: 0.5 (어떤 벤치마크에서 어느 정도 향상이면 성공인가?)
  - 제약 조건: 0.6 (기존 체크포인트와 호환 필요 여부?)

이 상태로 진행하면 실험 후 재설계가 필요할 수 있습니다. 그래도 진행하시겠습니까?"
  [예, 진행] [2-3개 질문 더] [취소]

<Escalation_And_Stop_Conditions>

하드 캡 20라운드: 현재 명확도 수준으로 진행, 위험 명시
소프트 경고 10라운드: 계속하거나 진행하도록 제안
조기 종료 (라운드 3+): 모호도 > 임계값이어도 경고와 함께 허용
사용자가 "중단", "취소", "그만": 즉시 중단, 재개를 위해 상태 저장
모호도 정체 (3라운드 동안 ±0.05): 온톨로지 모드로 재구성
모든 차원 0.9+: 최소 라운드 전이라도 스펙 생성으로 건너뜀
코드베이스 탐색 실패: 그린필드로 진행, 제한 사항 명시 </Escalation_And_Stop_Conditions>

<Final_Checklist>

.claude/settings.json 선택적 설정:

{
  "omc": {
    "deepInterview": {
      "ambiguityThreshold": 0.2,
      "maxRounds": 20,
      "softWarningRounds": 10,
      "minRoundsBeforeExit": 3,
      "enableChallengeAgents": true,
      "scoringModel": "opus"
    }
  }
}

재개

중단된 경우 /deep-interview를 다시 실행. .omc/state/에서 상태를 읽어 마지막 완료 라운드에서 재개.

브라운필드 vs 그린필드 가중치

차원	그린필드	브라운필드
목표 명확도	40%	35%
제약 명확도	30%	25%
성공 기준	30%	25%
컨텍스트 명확도	N/A	15%

3단계 파이프라인 (권장 경로)

1단계: Deep Interview       2단계: Ralplan              3단계: Autopilot
┌───────────────────┐    ┌────────────────────────┐    ┌──────────────────┐
│ 소크라테스 Q&A    │    │ Planner: 계획 생성     │    │ Phase 2: 실행    │
│ 모호도 점수 계산  │───>│ Architect: 검토        │───>│ Phase 3: QA      │
│ 챌린지 에이전트   │    │ Critic: 검증           │    │ Phase 4: 검증    │
│ 스펙 결정화       │    │ 합의까지 루프          │    │ Phase 5: 정리    │
│ 게이트: ≤20% 모호 │    │ ADR + RALPLAN-DR 요약  │    │                  │
└───────────────────┘    └────────────────────────┘    └──────────────────┘
출력: spec.md             출력: consensus-plan.md       출력: 동작하는 코드

deep-interview

About