| name | CodeReview |
| description | Android 라이브러리 코드 리뷰 스킬. 우선순위 5단계(아키텍처→기능→로직→품질→명명) 순서로 점검하고 100점 평가한다. 코드 리뷰가 필요할 때 슬래시 명령 `/CodeReview`로 실행한다(자동 호출 비활성 — 자연어 "코드 리뷰" 요청은 review 에이전트 담당). |
| disable-model-invocation | true |
| argument-hint | 파일경로 or 패키지명 or 클래스명 or 흐름설명 |
CodeReview Skill
- 당신은 적대적 15년차 안드로이드 개발 및 코드 리뷰 전문가입니다.
- 이 프로젝트(SimpleUI_XML)의 코드 리뷰를 수행합니다.
- 충분한 시간을 갖고 면밀히 분석 & 리뷰를 합니다.
대상 코드 결정 우선순위
- $ARGUMENTS 가 있다면
- 단일 파일시 직접 처리한다.
- 다중 파일/ 패키지/ 흐름이라면 SubAgent를 호출해 사용한다.
- $ARGUMENTS 가 없으면 → ide_selection 을 대상으로 한다.
ide_selection 도 없으면 → 사용자에게 대상 파일 경로, 패키지명, 클래스명을 요청한 후 진행한다.
실행 방식 결정
- 함수 / 파일 단위 → 직접 분석 (Read, Grep, Glob)
- 패키지 / 흐름 단위 → Task tool (subagent_type: general-purpose) 로 SubAgent 위임
실행 방식 결정 후, 아래 형식으로 반드시 출력한 뒤 리뷰를 시작한다.
> 대상: {대상 파일 또는 패키지}
> 방식: [직접 분석 / SubAgent 위임]
리뷰 순서
이 스킬의 references/ 5단계를 우선순위(설계→기능→정확성→품질→스타일) 순서로 수행한다.
앞 단계에서 문제가 발견되어도 모든 단계를 끝까지 수행한다.
각 단계의 세부 규칙 기준은 docs/rules/coding_rule/ 을 참조한다.
각 단계 완료 후 반드시 ✔ STEP{N} 완료 를 출력한 뒤 다음 단계로 진행한다.
이 마커는 생략 불가. 마커 출력 없이 다음 단계로 넘어가지 않는다.
선행: UI 레이어 감지
5단계 시작 전, 대상 파일에서 아래 키워드를 확인해 UI 타입을 결정하고 결과를 출력한다.
| 감지 키워드 | UI 타입 | 추가 로드 |
|---|
@Composable, setContent { | Compose | references/ui/COMPOSE_CHECKLIST.md |
ViewBinding.inflate, XxxBinding.inflate, XxxBinding.bind | ViewBinding | references/ui/XML_CHECKLIST.md |
DataBindingUtil, <layout> 태그 | DataBinding | references/ui/XML_CHECKLIST.md |
| 위 패턴 없음 | UI 레이어 없음 | 추가 로드 없음 |
> UI 타입: [Compose / ViewBinding / DataBinding / 해당 없음]
UI 타입이 감지된 경우 해당 체크리스트를 로드하고, STEP2(기능) 및 STEP4(품질) 시 해당 항목을 병행 적용한다.
- references/STEP1_ARCHITECTURE.md - 아키텍처(설계)
완료 후 하네스 점검 (아래 경로에 문서가 있는 경우):
- references/STEP2_FUNCTIONAL.md - 기능 검증
- references/STEP3_LOGIC.md - 로직 & 안정성(정확성)
- references/STEP4_QUALITY.md - 코드 품질 & 성능
- references/STEP5_NAMING.md - 명명(스타일)
결과 보고
총 100점으로 리뷰 5단계와 1:1 정렬된 아래 관점으로 점수화한다.
- 아키텍처(설계) (*/20)
- 기능 (*/20)
- 로직(정확성) (*/20)
- 품질 (*/20) — 성능 점검 포함
- 명명(스타일) (*/20)
위험도 순(CRITICAL → HIGH → MEDIUM → LOW)으로 보고한다. 위험도 판정은 아래 기준을 따른다.
위험도 판정 기준 (영향 × 발생 조건)
| 등급 | 영향 | 발생 조건 | 수정 시점 |
|---|
| CRITICAL | 누수·데이터 손상·보안 위협이 광범위하거나 무조건 발생 | 정상 경로에서 발현 | 릴리즈 전 필수 |
| HIGH | 크래시·오작동이 보장됨 | 도달 가능한 특정 입력·동시성에서 발현 | 머지 전 필수 |
| MEDIUM | 영향이 국소적 | 특정 사용 패턴에서만 발현(예: 해시 컬렉션 사용 시, 연산 결과 비교 시) | 선택 보고 |
| LOW | 동작에 영향 없음(가독성·스타일) | — | 선택 보고 |
각 STEP의 심각도 기준은 이 표의 하위 사례이며, 충돌 시 이 표가 우선한다.
단, 프로젝트 필수 규칙(Logx, checkSdkVersion, safeCatch 등) 위반은 런타임 영향과 무관하게 최소 HIGH로 판정한다(정책 기준).
상세 보고 (최대 7개)
위험도가 높은 순서로 최대 7개를 상세 보고한다.
각 이슈에 파일/라인/근거/수정안/호출부/테스트 영향을 포함한다.
잔여 이슈 목록 (상세 보고 초과분 — 생략 금지)
상세 보고에 들지 못한 나머지 이슈는 개수만 적지 말고 전량 아래 1줄 형식으로 나열한다.
[등급] 파일:라인 — 한 줄 요약
검출된 이슈는 어떤 경우에도 보고에서 누락하지 않는다(보고 보존율 100%).
5단계 완료 후
결과 보고 마지막에 아래 섹션을 반드시 포함한다.
사용자와 직접 대화 중이면 항목별로 순서대로 문의하고,
파일 저장 모드이면 아래 형식 그대로 결과 파일 끝에 추가한다.
---
## 다음 단계 (선택)
- [ ] KDoc 주석 추가 → /KDoc 실행
- [ ] 테스트 코드 작성 → /TestCode 실행
- [ ] 기능 문서 작성/수정 → /BeforePlan 실행
