review-code— agent skill

입력

$ARGUMENTS

Step 1 — 리뷰 대상 결정

• $ARGUMENTS가 비어 있으면 → git diff HEAD로 변경사항 확인. 추가로 git status --short로 untracked 파일을 확인하고, 리뷰가 필요한 신규 파일이 있으면 함께 포함한다.
• $ARGUMENTS가 있으면 → 해당 파일 또는 폴더의 코드를 Read/Glob으로 읽어 리뷰

Step 2 — 리뷰 체크리스트

각 항목을 확인하되, 해당 없는 항목은 생략한다. 파일 성격에 따라 적용 범위를 조정한다.

• 테스트 파일 (*Test.kt, *Spec.* 등): 가독성·정확성 위주, 아키텍처·보안 항목은 최소화
• 설정/빌드 파일 (*.gradle, *.json, *.yaml 등): 보안·정확성 위주
• 일반 소스 파일: 모든 항목 적용

가독성 (references/common/coding-philosophy.md 기준)

• 코드가 명확하고 읽기 쉬운가
• 함수·변수명이 역할을 잘 표현하는가 (네이밍 규칙 준수)
• 중복 코드가 없는가
• 구조적으로 명확한가 (불필요한 람다·복잡한 연산자 체인 남용 여부)
• 계약이 명시되어 있는가 (require / check / assert)
• 빠른 실패 원칙이 지켜지는가 (잘못된 상태를 조용히 넘기지 않는가)
• 주석이 적절한 위치에만 있는가 (공개 API 또는 코드로 설명 불가한 이유)

정확성

• 에러 처리가 적절한가
• 사전조건·사후조건·불변식이 지켜지는가
• 입력값 유효성 검사가 구현되어 있는가 (시스템 경계)

보안

• 시크릿 키·API 키가 노출되지 않았는가

아키텍처 _(플랫폼별 references 기준 적용)_

• 레이어 규칙이 지켜지는가
• 의존성 방향이 올바른가
• 플랫폼별 패턴이 프로젝트 규칙과 일치하는가 (references/android/kotlin-conventions.md, references/android/compose-patterns.md 기준)
• Service 관련 코드는 references/android/service-guidelines.md 기준 적용

테스트

• 핵심 기능의 테스트가 있는가 (핵심 흐름과 경계 조건 중심)
• 테스트 패턴이 프로젝트 규칙과 일치하는가

출력 및 종료 [STOP]

리뷰 결과를 아래 형식으로 출력한 뒤 반드시 여기서 멈출 것 — 코드 수정은 수행하지 않는다.

출력 형식

## 코드 리뷰

### 📋 리뷰 대상
(파일 목록 또는 diff 범위)

### ✅ 잘된 점

### ⚠️ 개선 사항
- 🔴 Critical — 즉시 수정 필수
- 🟡 Warning — 수정 권장
- 🟢 Suggestion — 개선 고려

각 항목: 문제 설명 + 파일경로:라인번호 + 개선 코드 예시

### 📝 총평

행동 원칙

• 문제 지적 시 반드시 개선 코드 예시를 포함할 것
• 파일경로:라인번호 형식으로 위치를 명시할 것
• 리뷰 결과 출력 후 멈춘다 — 코드 수정은 하지 않는다