RIJUDEVx/interrogate

Interrogate (심층 검토)

설정된 각 모델당 하나의 리뷰어를 생성하여 코드 변경 사항을 적대적으로 검토합니다. 모든 모델은 동일한 프롬프트와 평가 기준(rubric)을 받습니다. 적대적 신호는 할당된 페르소나가 아닌 모델 다양성에서 비롯됩니다.

리뷰어가 제기한 문제점은 실행을 통해 입증될 때만 생존합니다.

최종 결과물은 종합된 판정입니다. 변경 사항을 자동으로 적용하지 마십시오.

1단계, 범위 결정

컨텍스트에서 검토할 대상을 식별합니다:

• 사용자가 특정 파일이나 diff를 지정한 경우, 이를 사용합니다.
• 기능 브랜치(feature branch)에 있는 경우 git diff main...HEAD (또는 적절한 기준 브랜치)를 실행하여 전체 변경 세트를 가져옵니다.
• 사용자의 메시지가 최근 작업을 참조하는 경우, 관련 파일을 수집합니다.

diff(또는 파일 내용)와 리뷰어가 코드를 이해하는 데 필요한 주변 컨텍스트 파일을 함께 패키징합니다.

2단계, 의도 명시

리뷰어를 생성하기 전에 의도를 명시적으로 밝힙니다. 다음을 참고하여 의도를 도출합니다:

• 사용자의 메시지
• 커밋 메시지
• PR 설명(있는 경우)
• 코드 자체

명확한 단락 하나를 작성합니다. 의도가 확실하지 않은 경우, 진행하기 전에 사용자에게 질문합니다.

3단계, 리뷰어 생성

모든 리뷰어를 단일 메시지로 실행합니다. 각 슬롯당 하나씩, 하네스(harnes)의 하위 에이전트 도구 또는 delegate_task를 사용합니다.

모델 다양성을 목표로 합니다: 서로 다른 모델 군은 서로 다른 버그를 찾습니다. T3 Code에서는 사용자가 즐겨찾는 모델 중 서로 다른 군에서 3-4개의 강력한 모델을 선택하고 각각을 delegate_task로 시작합니다(t3-tools 스킬에 단계가 있습니다). 다른 환경에서는 하네스가 제공하는 뚜렷한 고성능 모델 3-4개를 선택합니다. 하위 에이전트별로 모델을 선택할 수 없는 경우, 모델 재정의 없이 리뷰어를 생성하고 독립적인 컨텍스트에서 다양성을 확보합니다.

하위 에이전트	역할
리뷰어 A	추론 중심 리뷰어
리뷰어 B	두 번째, 독립적인 모델 군
리뷰어 C	세 번째, 빠르거나 다른 군
리뷰어 D	적대적/엄격한 코드 품질 리뷰어

각 리뷰어에 대해 범용 하위 에이전트를 생성합니다:

• OpenCode / Codex: subagent_type: general (task 도구 사용)
• Claude Code: subagent_type: general-purpose
• 기타 하네스: 리포지토리를 읽을 수 있는 가장 가까운 범용 하위 에이전트

리뷰어는 정신적으로 읽기 전용 상태를 유지합니다. 파일을 편집해서는 안 됩니다. 재현(재)이 필요한 리뷰어는 자체 스크래치 복사본 또는 작업 트리에서 실행하며, 절대 원본 위치에서 실행하지 않습니다.

모든 리뷰어에게 다음 지침과 함께 채워진 템플릿을 제공합니다:

이 변경 사항을 깨뜨리십시오. 각 발견 사항을 실제 코드에 대한 실행(예: 실패하는 테스트, 재현 스크립트, 또는 잘못된 동작을 보여주는 명령어 출력)으로 입증하십시오. 디자인이나 계획의 경우, 프로토타입을 실행하거나 현재 트리를 탐색하십시오. 재현(재)은 자신의 작업 트리 내에서 유지하십시오. 각 발견 사항을 제목, 정확한 명령어, 출력된 내용, 그리고 의도가 요구하는 출력과 함께 보고하십시오. 실행하지 않은 것은 제외하십시오. 여기에는 스타일, 명명, 구조 및 향후 변경이 필요할 위험이 포함됩니다. 발견 사항이 없어도 유효한 결과입니다.

모델 슬러그(slug)가 확인 불가능하다고 거부되면, 작업 도구의 오류 메시지에서 유효한 슬러그를 확인하고, 가장 가까운 동등한 모델(동일 군의 가장 높은 추론 계층 선호)을 선택하여 유효한 슬러그로 생성합니다. 슬러그 문제로 검토를 차단하지 마십시오.

references/reviewer-prompt.md를 읽고 템플릿을 다음으로 채웁니다:

1. 명시된 의도
2. diff 또는 파일 내용
3. references/rubric.md의 검토 루브릭
4. references/code-quality-review.md의 코드 품질 렌즈

모든 리뷰어는 동일한 채워진 템플릿을 받으므로 모든 모델이 코드 품질 렌즈를 적용합니다.

4단계, 종합

결과가 돌아오면 통합된 그림을 구성합니다:

1. 각 발견 사항 검증: 명령어를 다시 실행합니다. 출력이 실패를 보여주고 그 실패가 의도를 깨뜨릴 때만 발견 사항을 유지합니다. 나머지는 폐기합니다. 근본 원인이 동일한 발견 사항은 병합합니다.
2. 모든 발견 사항 분석: 리뷰어의 결과를 분석합니다.
3. 합의 식별: 2개 이상의 모델이 독립적으로 제기한 발견 사항은 가장 신호가 강합니다.
4. 단독 모델 발견 사항: 여전히 읽을 가치가 있지만 가중치를 적절히 조정합니다.
5. 중복 제거: 서로 다른 모델이 동일한 문제를 다르게 설명할 수 있습니다. 이를 병합하고 어떤 모델이 제기했는지 기록합니다.
6. 불일치 기록: 한 모델이 플래그를 지정하고 다른 모델이 명시적으로 반대 의견을 제시하는 경우, 이는 판정에 유용한 컨텍스트입니다.

5단계, 리드 판정

당신은 리드 리뷰어(lead reviewer)이며, 실용적인 시니어 엔지니어로서 중립적인 집계자가 아닙니다.

전체 프레임워크는 references/lead-judgment.md를 참조하십시오.

모든 발견 사항을 다음 버킷을 사용하여 분류합니다:

• 조치 필요 (Act on): 실제 목표를 고려할 때 정확성, 보안 또는 유지보수성에 영향을 미치는 실제 문제. 이는 실제 PR을 차단할 것입니다.
• 고려 (Consider): 합법적인 지적이지만 현재 해결하는 비용이 이점보다 클지 확실하지 않음. 사용자의 주의를 기울일 가치가 있습니다.
• 참고 (Noted): 기술적으로 유효하지만 실행 가능하지 않음. 컨텍스트에 따라 다르거나, 시기상조의 최적화이거나, 현재 단계에서 영향이 낮습니다.
• 기각 (Dismissed): 틀렸거나, 지나치게 까다롭거나, 컨텍스트가 누락됨. 간단한 이유 설명.

각 발견 사항에 대해 다음을 포함합니다:

• 어떤 모델이 제기했는지
• 카테고리 (조치 필요 / 고려 / 참고 / 기각)
• 분류에 대한 한 줄짜리 근거

출력 형식

다음 구조로 판정을 제시합니다:

의도

[2단계의 명시된 의도 단락]

리뷰어

• 리뷰어 [레이블]: [모델 이름], [N개 발견 사항] (리뷰어당 하나의 불릿)

조치 필요

[해결해야 할 발견 사항. 각각: 설명, 어떤 모델이 제기했는지, 왜 중요한지]

고려

[생각해볼 가치가 있는 발견 사항. 각각: 설명, 어떤 모델이 제기했는지, 트레이드오프]

참고

[유효하지만 우선순위가 낮음. 간략한 목록]

기각

[기각된 발견 사항과 간략한 근거. 실행으로 입증되지 않은 발견 사항 포함.]

합의 지도

[모델들이 어디에서 동의했는지, 어디에서 갈렸는지, 그리고 동의/불일치 패턴이 무엇을 말해주는지?]

블래스트 레디우스 (파급 효과)

변경이 작지만 아직 신뢰할 수 없고, diff 너머에서 무엇을 깨뜨리는지 질문할 때 이 모드를 사용하십시오. 호출자를 나열하는 것은 작업이 아닙니다. grep은 몇 초 안에 그것들을 찾습니다. 작업은 grep이 보여주지 않는 고장입니다.

자신의 작성 내용을 신뢰하지 마십시오

변경 사항이 무엇을 깨뜨리는지에 대한 작성 내용은 그럴듯해 보이지만 가치가 없습니다. 사실 여부와 관계없이 설득력 있게 읽힙니다. 따라서 작성 내용을 그대로 전달하지 마십시오. 전체가 의존하는 한두 가지 사실을 찾아 코드를 실행하여 입증하십시오.

확실성 수준

변경 사항의 안전성이 의존하는 각 사실에 대해, 저렴하게 할 수 있는 한 이 목록의 아래 단계까지 내려가고, 어디에서 멈췄는지 말하십시오.

1. 당신이 그렇게 말했습니다. 그 자체로는 가치 없음.
2. 당신이 라인을 가리켰습니다. 실제 file:line, 또는 라이브러리 자체 소스.
3. 잘못된 사례가 발생할 수 없다는 것을 보여주었습니다. 실패 단계를 단계별로 따라가며 도달하지 않음을 확인.
4. 실행했습니다. 실제 코드를 호출하고 틀렸을 때 큰 소리로 실패하는 스크립트 또는 테스트.
5. 실행 중인 앱에서 재현했습니다.

4단계까지 갈 수 없는 안전 사실은 그렇게 말하십시오. 확정된 것으로 작성하지 마십시오. 4단계는 일반적으로 앱이 배송하는 것과 동일한 라이브러리를 가져와서 걱정하는 정확한 함수를 호출하는 작은 스크립트 하나입니다.

단계

1. 변경 사항을 읽습니다. diff, 추가, 변경, 삭제된 심볼, 그리고 diff가 명시적으로 알려주지 않는 부분을 포함하여 이제 다르게 수행하는 작업. 그 이유를 위해 PR 및 커밋 메시지를 가져옵니다.
2. 안전한 이유가 되는 하나의 사실을 찾습니다. 위험해 보이는 대부분의 변경 사항은 "이 호출은 이미 죽은 캐시 항목만 삭제하고 다른 작업은 수행하지 않음"과 같은 단일 사실 때문에 안전합니다. 그 사실을 찾으십시오. 그것이 유지된다면 대부분 위험한 경우가 한 번에 해소됩니다. 긴 '아마도' 목록이 아니라 여기에 시간을 투자하십시오.
3. grep이 멈추는 곳을 살펴봅니다. 호출하는 라이브러리의 소스를 읽고, 고정된 버전과 로컬 패치를 확인합니다. 실행 시점(microtask, 언마운트 및 정리, Solid 대 React 등)을 파악합니다. 심볼 검색이 놓치는 것(API가 반환하는 JSON, DB 열, 와이어 형식, 동일한 바이트를 읽는 다른 언어, 기능 플래그, 세 단계 아래의 코드)을 추적합니다.
4. 각 위험에 대해 정직합니다. 발생할 실제 가능성과 발생할 경우 실제 비용을 제시합니다. 확인한 위험만 유지합니다. 확인하고 제외한 것은 별도로 나열합니다. 실제 file:line을 인용하고, 아무것도 찾지 못한 검색도 여전히 답변입니다. 호출자나 API를 절대 지어내지 마십시오.
5. 하나의 사실을 입증합니다. 실제 코드를 실행하는 스크립트나 테스트를 작성하고 실행한 다음 어떤 일이 발생했는지 붙여넣습니다. 저렴하게 입증할 수 없으면 입증되지 않음으로 표시합니다. 과장하지 마십시오.
6. 크거나 광범위한 변경 사항인 경우, 위 검토를 여러 모델과 함께 실행합니다. 서로 다른 모델이 서로 다른 실제 버그를 잡습니다.

전달할 내용

• 하는 일. 변경된 사항. 명확하지 않은 부분 포함.
• 안전한 이유가 되는 하나의 사실. 이를 명시하고, 어느 단계까지 확인했는지 말하고, 증거를 제시합니다. 입증할 수 없으면 입증되지 않음이라고 씁니다.
• 위험. 실제 위험만. 각각 어떻게 깨지는지, file:line, 가능성과 심각성, 그리고 확인 방법을 명시합니다. 중요한 위험에 대한 증거를 붙여넣습니다.
• 제외된 사항. 확인한 사항과 괜찮은 이유.
• 병합 전에. 실제 버그를 잡는 가장 저렴한 테스트 또는 재현(재). 작성한 스크립트 포함.

unslop을 통해 작성하고, 실제 코드를 인용하며, 공개적인 곳으로 가기 전에 개인 정보를 제거하십시오.

답변: 위 작성 내용. 하나의 안전 사실이 입증되었거나 입증되지 않음으로 표시됨.