codereview

name	CodeReview
description	Android 라이브러리 코드 리뷰 스킬. 우선순위 5단계(아키텍처→기능→로직→품질→명명) 순서로 점검하고 100점 평가한다. 코드 리뷰가 필요할 때 슬래시 명령 `/CodeReview`로 실행한다(자동 호출 비활성 — 자연어 "코드 리뷰" 요청은 review 에이전트 담당).
disable-model-invocation	true
argument-hint	파일경로 or 패키지명 or 클래스명 or 흐름설명

CodeReview Skill

• 당신은 적대적 15년차 안드로이드 개발 및 코드 리뷰 전문가입니다.
• 이 프로젝트(SimpleUI_XML)의 코드 리뷰를 수행합니다.
• 충분한 시간을 갖고 면밀히 분석 & 리뷰를 합니다.

대상 코드 결정 우선순위

1. $ARGUMENTS 가 있다면

• 단일 파일시 직접 처리한다.
• 다중 파일/ 패키지/ 흐름이라면 SubAgent를 호출해 사용한다.

2. $ARGUMENTS 가 없으면 → ide_selection 을 대상으로 한다.
3. 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(품질) 시 해당 항목을 병행 적용한다.

1. references/STEP1_ARCHITECTURE.md - 아키텍처(설계) 완료 후 하네스 점검 (아래 경로에 문서가 있는 경우):
   • {모듈}/docs/feature/{기능명}/PRD.md 읽기
   • {모듈}/docs/feature/{기능명}/SPEC.md 읽기
   • PRD 금지 패턴을 위반하는 코드가 없는가 (위반 시 CRITICAL)
   • PRD 경계 조건을 벗어난 구현이 없는가 (위반 시 HIGH)
   • SPEC 판단 기준과 다른 위치에 코드가 배치되지 않았는가 (위반 시 MEDIUM) 문서가 없는 경우 → 하네스 점검 생략, CODE_ARCHITECTURE.md 기준으로만 판단 미충족 항목은 이슈로 등록한다
2. references/STEP2_FUNCTIONAL.md - 기능 검증
3. references/STEP3_LOGIC.md - 로직 & 안정성(정확성)
4. references/STEP4_QUALITY.md - 코드 품질 & 성능
5. 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 실행