dev-review — 리뷰어 (3단계)
변경 사항에 대한 독립적인 검토. DIFF를 태스크(TASK)와 비교하세요 — 아무것도 없는 것과 비교하지 마세요.
| 호출 | dev-review <TASK> |
| 입력 | 작업 트리 diff + memory/spec/<TASK>/analysis.md 및 implementation.md |
| 출력 | memory/spec/<TASK>/review.md, status: draft, 평결 approve / needs-changes |
| 게이트 | 소유자가 평결을 수락 — 아래 소유자 게이트 참조 |
| 다음 | needs-changes → dev-implement <TASK> 다시; approve → 소유자가 적용 |
0. 진입 체크
<TASK>가 없음 → 물어보세요.implementation.md가 없거나 비어 있음 → 중단: 아직 검토할 내용이 없습니다.implementation.md가 여전히status: draft→ 그 사실을 알리고 소유자가 요청하면 검토하되, 평결에 2단계가 게이트를 통과하지 못했다고 기록하세요.- DIFF보다 먼저 분석을 읽으십시오. 의도된 바를 모르고 변경을 판단하면 스타일 코멘트만 나오고 중요한 발견을 놓치게 됩니다.
프로세스 (공통)
-
태스크와 분석에서 의도를 재추론한 후, DIFF가 이를 달성하는지 판단하세요. 잘못된 위치에 아름다운 변경을 가하는 것은 중요한 발견입니다.
-
정확성 우선: 경계 조건, 오류 경로, 동시성, 데이터 경계 형태. 그 다음으로 규칙과 명확성. 스타일만의 사소한 지적은 마지막에 하고 그렇게 표시하세요.
-
구현자의 증거를 신뢰하지 말고 직접 재현하세요. 결정적인 검증을 직접 다시 실행하세요(테스트 스위트가 길면
dev-reviewer서브 에이전트에 위임). 구현 노트에는 실행된 내용이 기록되어 있습니다. 당신의 임무는 그것이 여전히 유효하고 올바른 항목이 실행되었는지 확인하는 것입니다. -
영향 범위 확인: 변경된 코드를 소비하는 다른 것은 무엇인가? DIFF가 건드리지 않은 사용처를 grep하세요. 의도하지 않은 lockfile / 설정 / 생성 파일 변경은 발견 사항입니다.
-
발견 사항, 수정 사항이 아님. 심각도(치명 / 수정 권장 / 사소)와 함께 파일 및 라인을 보고하세요. 사소한 기계적 수정은 직접 적용할 수도 있지만, 그 외 모든 것은
dev-implement로 되돌아갑니다. 평결을memory/spec/<TASK>/review.md에 작성하되, 다음으로 시작하세요:--- task: <TASK> stage: review status: draft verdict: approve | needs-changes ---
스택별 리뷰 체크
node: diff에 도입된 타입 회피(any, as, @ts-ignore); 오류 처리가 없는 프로미스 체인; 의도치 않은 의존성 또는 lockfile 변동; 프로젝트 그래프를 우회하는 모노레포 수정(패키지 간 깊은 상대 import).
jvm: 새로운 경계에서의 널 가능성(Kotlin 플랫폼 타입, Optional 오용); 리소스 처리(try-with-resources / use); 새 빈의 트랜잭션 및 DI 스코프; 실제로 실행되도록 배치된 테스트(올바른 모듈, 올바른 명명 규칙).
android: 로직뿐만 아니라 라이프사이클도 확인하세요 — 컴포저블이나 Activity에서 시작된 작업은 회전을 견디고 스코프가 소멸될 때 중단되어야 합니다(repeatOnLifecycle/collectAsStateWithLifecycle에서 수집, 올바른 스코프로 코루틴 취소). 수명이 긴 객체에 보관된 Context는 메모리 누수입니다. AndroidManifest.xml의 새 권한은 런타임 요청 경로도 필요합니다. minSdk보다 높은 API는 명시적 게이트가 필요합니다. 릴리스 빌드는 디버그와 다릅니다 — 리플렉션(직렬화, Room, DI) 관련 항목에 대한 R8/ProGuard 규칙도 변경의 일부입니다. 그리고 계측 테스트가 실제로 실행되었는지 물어보세요: CI에서 가장 자주 건너뛰는 테스트입니다.
php: 새 코드의 declare(strict_types=1) 및 매개변수/반환 타입; 수정된 경로의 주입 표면(원시 SQL, 이스케이프되지 않은 출력); diff에 도입된 오류 억제(@); 프레임워크 규칙과 일치하는 설정/DI 변경.
python: 새로운 경계에서의 타입 힌트(Any, 누락된 반환 타입, diff에 도입된 # type: ignore); 가변 기본 인자 및 가변 클래스 수준 상태; 리소스 종료(파일 및 연결에 with 사용) 및 async 호출이 실제로 대기됨; 예외를 삼키는 예외 처리(except Exception: pass); 매니페스트와 잠금 파일이 함께 변경됨(pyproject.toml와 uv.lock / poetry.lock); Django: 모든 모델 변경에 대한 마이그레이션, 되돌릴 수 있어야 함; 테스트는 실행기가 찾는 위치에 배치(tests/, test_*.py, conftest.py fixture)되고 오래된 마커에 의해 건너뛰지 않아야 함.
소유자 게이트
여기서 멈추세요 — 리뷰어는 변경을 적용하지 않으며 다시 구현하지 않습니다. 평결을 두 문장으로 요약하고 그 근거가 된 발견 사항과 함께 보고하세요.
- needs-changes → 소유자가 결정합니다. 소유자의 지시에 따라 루프는
dev-implement <TASK>로 돌아가고,implementation.md를 처음부터 다시 작성하지 않고 추가합니다.review.md는 무엇이 잘못되었는지 기록으로 남습니다. - approve → 소유자가 명시적으로 수락하면
status: approved를 설정합니다. 변경 적용(커밋, 브랜치, 푸시)은 워크스페이스 git 법칙에 따른 소유자의 행위이며, 이 스킬의 역할이 아닙니다.
완료 조건
review.md에 frontmatter와 심각도별 발견 사항이 포함된 평결이 있고, 결정적인 검증이 당신에 의해 재실행되었으며, 채팅 요약에 평결이 두 문장으로 제공됩니다. 다른 사람의 사후 분석(post-mortem)에서 변호할 수 있는 것만 승인하세요.