differential-review

differential-review 개요

differential-review가 하는 일

differential-review 스킬은 일반적인 프롬프트보다 훨씬 엄격한 기준으로 PR, 커밋, diff를 검토하는 보안 중심 워크플로입니다. 특히 인증, 암호화, 외부 호출, 상태 변경처럼 리스크가 큰 경로에서 변경이 회귀를 일으키는지 판단해야 하는 리뷰어를 위해 만들어졌습니다.

어떤 경우에 가장 잘 맞는가

보안에 민감한 코드를 검토 중이거나, 큰 diff를 인수받았거나, 코드베이스 규모에 맞게 반복 가능한 방법이 필요하다면 differential-review 스킬이 잘 맞습니다. 엔지니어, 보안 리뷰어, AI 지원 감사자처럼 피상적인 줄 단위 훑기가 아니라 증거 기반 결론을 원할 때 특히 유용합니다.

무엇이 다른가

differential-review의 핵심 가치는 결론보다 먼저 맥락을 강제한다는 점입니다. 기준 히스토리, 영향 범위, 테스트 커버리지, 그리고 명시적인 신뢰 한계를 먼저 보게 만듭니다. 또한 저장소는 출력을 구조화된 마크다운 보고서로 밀어주기 때문에, 이 스킬은 단순한 분석 프롬프트가 아니라 산출물이 있는 리뷰 프로세스입니다.

differential-review 스킬 사용 방법

스킬 설치 및 로드

일반적인 differential-review install 흐름은 먼저 저장소 툴체인을 준비한 뒤, 에이전트가 스킬 폴더를 가리키도록 설정하는 방식입니다. 이 패키지의 설치 경로는 plugins/differential-review/skills/differential-review입니다. Trail of Bits skills repo를 사용 중이라면 프로젝트의 skills 명령으로 설치한 뒤, 먼저 SKILL.md를 여세요.

리뷰에 맞는 입력을 주기

가장 좋은 differential-review usage를 원한다면, 특정 base/head 범위, 커밋, 또는 PR을 지정하고 보안상 우려가 있다면 함께 밝혀 주세요. 좋은 입력 예시는 다음과 같습니다: “base..head를 auth bypass, reentrancy, 누락된 테스트 관점에서 검토하고, 외부 호출 경로와 상태 전이를 중심으로 봐 주세요.” 반대로 “이 diff 좀 봐줘” 같은 입력은 추측의 여지를 너무 많이 남깁니다.

먼저 읽어야 할 파일

좋은 differential-review guide는 SKILL.md에서 시작해 methodology.md, adversarial.md, patterns.md, reporting.md 순으로 읽는 것에서 출발합니다. 이 파일들은 기준 맥락을 어떻게 만들지, 어떤 공격 모델을 쓸지, 무엇을 패턴으로 스캔할지, 최종 보고서를 어떤 형식으로 쓸지를 알려 줍니다. 이 플러그인에는 보조 스크립트나 추가 참조 폴더가 없으므로, 스킬 파일이 곧 단일한 기준 स्रोत입니다.

출력 품질을 바꾸는 워크플로 팁

깨끗한 diff, 기준 커밋, 그리고 호출부와 테스트를 살필 수 있을 만큼의 저장소 맥락을 제공할 수 있을 때 이 스킬을 쓰는 것이 가장 좋습니다. 코드베이스가 작은지, 중간인지, 큰지 알려 주거나 스킬이 스스로 규모를 추론하게 둘 수는 있지만, 기준/히스토리 단계를 건너뛰면 안 됩니다. differential-review for Code Review에서 가장 가치가 큰 입력은 변경된 파일, 의심되는 신뢰 경계, 수상한 함수, 그리고 이미 알고 있는 회귀 이력처럼 구체적인 정보입니다.

differential-review 스킬 FAQ

differential-review는 보안 리뷰에만 쓰는가?

네, 주로 그렇습니다. 일반적인 스타일 정리나 기능 승인용이 아니라 보안 중심의 differential review를 위해 설계되었습니다. 물론 일반 코드 리뷰에도 사용할 수 있지만, 변경이 신뢰 경계, 데이터 무결성, 악용 가능성에 영향을 줄 수 있을 때 진가가 가장 잘 드러납니다.

일반 프롬프트와는 어떻게 다른가?

일반 프롬프트는 diff를 요약하는 데 그칠 수 있지만, differential-review는 히스토리, 영향 범위, 공격자 모델링을 통해 위험을 입증하거나 반박하려고 합니다. 또한 마크다운 보고서를 기대하므로, 결과를 넘기거나 보관하기가 더 쉽습니다.

초보자도 사용하기 쉬운가?

초보자도 사용할 수는 있지만, 특정 diff를 가리킬 수 있고 구조화된 분석을 원한다는 전제를 둡니다. 코드베이스를 잘 모르더라도 이 스킬은 기준 맥락을 요구하고 누락된 커버리지를 명시하게 만들기 때문에 도움이 됩니다.

언제는 쓰지 말아야 하나?

사소한 텍스트 변경, 낮은 위험도의 포맷팅 전용 PR, 또는 한 문단 요약만 필요한 경우에는 differential-review를 쓰지 마세요. 의미 있는 보안 또는 회귀 위험이 없을 때는 과한 도구이며, 깊게 점검할 가치가 있는 대상이 있을 때만 프로세스가 의미를 갖습니다.

differential-review 스킬 개선 방법

더 강한 리뷰 맥락을 제공하기

가장 큰 개선 효과는 스킬에 정확한 리뷰 범위를 주는 데서 나옵니다. PR 번호, 커밋 범위, 대상 브랜치, 그리고 의심되는 위험 영역을 명시하세요. 프로젝트 도메인을 알고 있다면 그것도 먼저 말해 주세요. Solidity 변경인지, API auth 흐름인지, 결제 경로인지에 따라 분석이 맞는 공격 모델 쪽으로 더 정확히 향합니다.

처음부터 적절한 깊이를 요청하기

differential-review usage를 더 좋게 만들고 싶다면, 정확성, 악용 가능성, 회귀 위험 중 무엇을 더 중시하는지 명확히 하세요. 예를 들어: “외부에서 호출 가능한 함수, 변경된 검증 로직, 새 분기에 대한 누락된 테스트를 중심으로 봐 주세요.” 이렇게 요청하면 가장 중요한 경로에 검색 범위를 좁히고, 잡음성 발견을 줄일 수 있습니다.

흔한 실패 모드를 주의하기

가장 흔한 누락은 작은 diff를 낮은 위험으로 취급하는 것, 삭제된 코드 히스토리를 무시하는 것, 그리고 영향 범위를 판단할 때 전이적 호출자를 잊는 것입니다. 이 스킬은 바로 그 실수를 피하도록 설계되어 있지만, 그것을 제대로 수행하려면 여전히 구체적인 기준점과 명확하게 경계가 정해진 diff가 필요합니다.

첫 보고서 이후 반복하기

첫 보고서를 다음 검토의 기준으로 삼아 보세요. 결과가 너무 넓다면 공격자 모델을 더 좁히거나 한 서브시스템을 더 깊게 보라고 요청하세요. 너무 얕다면 더 많은 히스토리, 더 강한 테스트 점검, 또는 불변식과 회귀 경로에 더 엄격하게 집중하도록 다시 실행해 달라고 요청하세요.