agent-review

name	agent-review
description	작업 완료 후 독립 서브에이전트(Opus)를 활용한 적대적 코드 리뷰. 변경사항 리뷰, 코드 품질 검토, 최종 커밋 전 필수 리뷰에 사용.
disable-model-invocation	false
argument-hint	[리뷰 초점 (선택)]

코드 리뷰 - 독립 서브에이전트(Opus) 적대적 리뷰

메인이 변경사항을 경량 정리한 뒤, 독립 서브에이전트에게 적대적(adversarial) 리뷰를 받습니다. 서브에이전트는 저장소를 직접 읽고 명령을 실행해 검증하되, 파일을 수정하지 않습니다 (수정은 메인이 수행).

절차

1. 메인이 git diff --stat 등으로 변경 범위를 파악합니다.
2. codebase-memory-mcp 그래프 도구를 우선 사용하여 변경의 영향 범위를 분석합니다.
   • detect_changes로 변경된 심볼과 blast radius 확인
   • trace_call_path로 변경 함수의 호출자/피호출자 추적
3. 서브에이전트에게 변경 컨텍스트와 리뷰 우선순위를 전달하여 독립 리뷰를 요청합니다.
4. 리뷰 결과를 필터링하여 반영(수정은 메인이 직접)하고 최종 결과를 보고합니다.

서브에이전트 호출 방법

Agent 도구를 사용합니다:

• subagent_type: "general-purpose", model: "opus" (기본)
• 에스컬레이션: 데이터 모델/영속성(serde·마이그레이션), 동시성/레이스, 수치 정밀도, IPC 프로토콜 의미론 등 고위험 변경 리뷰는 model 지정을 생략하여 메인 모델(상위 티어)을 상속시킵니다.
• 백그라운드 실행이 기본 — 완료 시 task-notification으로 자동 수신. 커밋 등 후속 작업은 리뷰 결과 수신 후에만 진행합니다.
• 결과가 즉시 필요하면 run_in_background: false로 동기 실행합니다.

프롬프트 구성

효과가 검증된 템플릿:

당신은 DmNote 프로젝트(Tauri + React)의 엄격한 적대적 코드 리뷰어입니다.
READ-ONLY — 파일을 수정하지 말고 발견 사항만 보고하세요.
작업 디렉토리: (절대 경로)

## 컨텍스트
(무엇을 왜 변경했는지, 커밋 범위 또는 uncommitted 여부.
 예: "git diff로 확인" / "git show <해시>" / "git diff master...HEAD")

## 리뷰 우선순위 (높은 순)
1. (이번 변경에서 가장 회귀 위험이 큰 지점 — 파일/함수를 구체적으로 지목)
2. (기능 완결성 — 타입 분기 누락, 프로토콜 문자열 쌍 불일치 등 도구가 못 잡는 것)
3. (그 외 로직/동작 버그)

이미 검증됨: tsc / eslint / vitest / cargo check / clippy 통과 —
타입·문법이 아니라 로직과 동작에 집중하세요.

의도된 설계: (버그로 오인할 수 있는 의도적 결정들을 명시)

각 발견 사항: 심각도(CRITICAL/HIGH/MEDIUM/LOW), 파일:라인, 문제, 수정안.
문제없는 카테고리는 명시적으로 "CLEAN"이라고 밝히세요.
마지막에 종합 판정: SHIP / FIX-FIRST

핵심 원칙:

• 리뷰 전에 자동 검증(tsc/lint/tests/cargo)을 먼저 통과시키고, 리뷰어에게는 도구가 못 잡는 것(로직/동작/의미)에 집중하도록 지시합니다.
• 메인의 "문제없을 것"이라는 판단은 전달하지 않습니다. 반대로 의도된 설계 결정은 명시해서 오탐을 줄입니다.
• 브랜치 전체 리뷰는 git diff master...HEAD 기준을 프롬프트에 명시합니다.

후속 질문

같은 에이전트에 SendMessage로 특정 발견 사항의 상세/수정안을 추가 요청합니다.

판정 처리

• SHIP: 커밋 진행. LOW 항목은 반영 여부를 재량 판단하고 보고에 명시.
• FIX-FIRST: 지적 사항을 메인이 직접 수정 → 검증 재실행 → 커밋. 수정이 큰 경우 재리뷰.

실패 처리

• 서브에이전트 실패(결과 null) 시: → "서브에이전트 리뷰 실패: [원인]. 메인이 직접 리뷰합니다."를 보고하고 diff를 직접 리뷰합니다.
• fallback 발생 시 반드시 원인을 사용자에게 명시합니다.

피드백 필터링

서브에이전트 피드백을 반영할 때 메인이 자체 판단으로 필터링합니다:

• 방어적 코딩 수준의 제안 (에러 핸들링 강화, 옵셔널 체크 추가 등)이 실질적 버그가 아니라 오버엔지니어링에 해당하면 반영하지 않고 생략합니다.
• 프로젝트 컨벤션(예: let _ = store.update(...) 패턴)에 부합하는 코드에 대한 지적은 무시합니다.
• 미배포/내부 테스트 기능의 엣지 케이스 LOW 항목은 보류 가능(보고에는 명시).

출력 형식

리뷰 요약

(판정 SHIP/FIX-FIRST + 한 줄 평가. fallback인 경우 "[서브에이전트 미사용: 사유]" 명시)

이슈 목록

• [Critical/High/Medium/Low] 파일:라인 - 설명 및 근거 → 반영 여부

반영 내역

(수정한 항목과 보류한 항목의 사유)