android-reviewlisted

## 입력 ``` $ARGUMENTS ``` ## Step 1 — 리뷰 대상 결정 - `$ARGUMENTS`가 **비어 있으면** → `git diff HEAD`로 변경사항 확인. 추가로 `git status --short`로 untracked 파일을 확인하고, 리뷰가 필요한 신규 파일이 있으면 함께 포함한다. - `$ARGUMENTS`가 **있으면** → 해당 파일 또는 폴더의 코드를 Read/Glob으로 읽어 리뷰 ## Step 2 — 리뷰 체크리스트 각 항목을 확인하되, 해당 없는 항목은 생략한다. 파일 성격에 따라 적용 범위를 조정한다. - **테스트 파일** (`*Test.kt`, `*Spec.*` 등): 가독성·정확성 위주, 아키텍처·보안 항목은 최소화 - **설정/빌드 파일** (`*.gradle`, `*.json`, `*.yaml` 등): 보안·정확성 위주 - **일반 소스 파일**: 모든 항목 적용 > **references 는 리뷰 대상 레포의 규칙이 아니다 — 인용 전에 출처를 확인한다.** > `references/android/kotlin-conventions.md`·`compose-patterns.md`는 첫 줄에 밝히듯 **특정 참고 > 프로젝트에서 쓰이는 관례**이고, `coding-philosophy.md`는 개인 철학, `service-guidelines.md`만 > 플랫폼 공식 문서 기반이다. 아래 체크리스트가 "프로젝트 규칙과 일치하는가"라고 쓴 것은 **리뷰 > 대상 레포의 규칙**을 뜻하며, references 는 그 후보를 떠올리게 하는 재료일 뿐이다. > > 그래서 references 를 근거로 지적할 때는 ① 그 규칙이 리뷰 대상 레포에도 적용되는지 판단하고, > ② 아니면 지적에서 빼거나 "다른 프로젝트 관례"라고 밝히며, ③ 그럼에도 유효하면 **언어·플랫폼 > 동작 같은 프로젝트 무관한 근거**를 대거나 **그 레포에 이미 있는 관례**를 찾아 인용한다. > DI 프레임워크·아키텍처 계층처럼 레포마다 다른 항목은 걸러내면서 에러 처리·네이밍처럼 보편적으로 > 보이는 항목만 그대로 인용하면 판단이 일관되지 않게 된다 — 같은 문서면 같은 기준으로 판단한다. **가독성** (`${SKILL_DIR}/references/common/coding-philosophy.md` 기준) - 코드가 명확하고 읽기 쉬운가 - 함수·변수명이 역할을 잘 표현하는가 (네이밍 규칙 준수) - 중복 코드가 없는가 - 구조적으로 명확한가 (불필요한 람다·복잡한 연산�� 체인 남용 여부) - 계약이 명시되어 있는가 (`require` / `check` / `assert`) - 빠른 실패 원칙이 지켜지는가 (잘못된 상태를 조용히 넘기지 않는가) - 주석이 적절한 위치에만 있는가 (공개 API 또는 코드로 설명 불가한 이유) **정확성** - 에러 처리가 적절한가 - 사전조건·사후조건·불변식이 지켜지는가 - 입력값 유효성 검��가 구현되어 있는가 (시스템 경계) **보안** - 시크릿 키·API 키가 노출