review-qualitylisted

## ��력 ``` $ARGUMENTS ``` ## 이 스킬이 하는 일 일반 코드 리뷰(로직 버그·가독성)가 아니라 **"플랫폼이 출시에 요구하는 품질 기준"** 관점의 검토다. 판단 근거는 플랫폼 공식 문서다 — Android Core App Quality, Apple App Review Guidelines(ARG)/Human Interface Guidelines(HIG), 그리고 워치 앱은 Wear OS App Quality. Android↔Apple을 1:1로 이어둔 매핑 표와 Wear OS 전용 항목(WO-*)이 자산으로 있어, 지적할 때마다 **어느 기준에 걸리는지 근거를 인용**한다. 그래야 "왜 고쳐야 하는지"가 명확해지고, 스토어 리젝 리스크인지 권고사항인지 구분된다. ## Step 1 — 검토 대상 결정 - `$ARGUMENTS`에 경로가 있으면 그 경로를, 없으면 현재 작업 디렉터리를 루트로 삼는다. - 너무 크면(모노레포 등) 사용자에게 어느 앱/모듈을 볼지 먼저 확인한다. - **비대화형 실행(서브에이전트·CI 등 사용자에게 물을 수 없는 환경)이면** 묻지 말고, 앱 엔트리 (매니페스트·`tauri.conf.json`·`Info.plist`·앱 `package.json`)가 있는 주 패키지를 대상으로 고른 뒤, "물을 수 없어 ○○를 기본 대상으로 정함"을 리포트 첫머리에 명시한다. 검토가 멈추지 않게 하기 위함이다. ## Step 2 — 스택 감지 `references/detection-hints.md`의 **§1 스택 감지**를 읽고, 루트의 파일 신호로 플랫폼을 판별한다. 하이브리드(RN/Flutter/Tauri/Capacitor)는 네이티브 폴더가 함께 있어 **여러 플랫폼이 동시에 잡힐 수 있다** — 잡힌 플랫폼 전부를 대상으로 한다. 어느 신호도 없으면 사용자에게 대상 플랫폼을 확인한다. Android 신호에 워치 신호(`android.hardware.type.watch`, `androidx.wear.*` 등)가 함께 잡히면 **Wear OS 앱**이다 — Android 항목에 더해 Wear OS 항목(WO-*)을 적용한다. 감지 결과를 한 줄로 먼저 보고한다. 예: "감지: React Native (android/ + ios/ 동반) → Android·Apple 양쪽 점검", "감지: Wear OS 앱 (Jetpack Compose for Wear OS) → Android + Wear OS(WO-*) 점검". ## Step 3 — 해당 플랫폼 항목 점검 감지된 플랫폼에 맞는 항목만 점검한다 — 해당 없는 플랫폼 항목으로 노이즈를 내지 않는다. 1. `references/detection-hints.md`의 플랫폼별 §2~§4 점검 단서로 코드를 확인한다 (grep 패턴·파일 위치가 정리돼 있다). `AndroidManifest.xml`, `Info.plist`, `build.gradle`, `tauri.conf.json` 같은 설정 파일이 가장 밀도 높은 신호원