---
name: nuxt-code-review
description: |
  브랜치/PR 단위 코드 리뷰를 수행합니다. git diff 기반으로 변경된 코드 전체를
  팀 컨벤션과 평가 기준에 따라 근거 기반(evidence-based)으로 리뷰합니다.
  "코드 리뷰해줘", "PR 리뷰", "브랜치 리뷰", "변경사항 검토", "diff 리뷰" 등을
  요청하면 트리거됩니다. (단일 .vue 파일 심층 리뷰는 vue-component-review 스킬을 사용하세요.)
---

# Nuxt 코드 리뷰 (브랜치/PR 단위)

이 스킬은 현재 브랜치의 전체 변경사항을 대상으로 근거 기반 코드 리뷰를 수행합니다.
모든 코멘트는 `references/evaluation-criteria.md`의 기준 ID를 인용하여 주관적 의견이 아닌
팀 컨벤션에 근거합니다.

## 핵심 원칙

1. **근거 인용 필수**: 모든 코멘트는 평가 기준 ID(예: `VUE-002`)를 반드시 인용한다. 기준 없는 의견은 코멘트로 작성하지 않는다.
2. **수정 제안 필수**: "이 코드가 잘못됐다"만으로는 부족하다. 구체적인 수정 방법(before/after)을 함께 제시한다.
3. **리플렉션으로 오탐 제거**: 최종 출력 전 모든 코멘트를 재검증하여 컨텍스트를 오해한 오탐을 제거한다.

## 작업 순서

### Phase 1: 컨텍스트 수집

1. 베이스 브랜치를 확인한다. 사용자가 명시하지 않으면 `main`으로 가정하고 알린다.
2. 변경 범위를 파악한다:
   ```bash
   git diff <base>...HEAD --stat
   git log <base>...HEAD --oneline
   ```
3. 프로젝트 전용 컨벤션 파일이 있으면 읽는다 (우선순위 높음):
   - `.claude/project/conventions.md`
   - `docs/adr.md` 또는 `docs/adr.yaml`
   - `docs/code-convention.yaml`
4. `references/evaluation-criteria.md`를 로드하여 평가 기준을 준비한다.
5. 변경 의도를 1줄로 요약한다 (커밋 메시지, PR 설명, 파일 목록에서 추론).
6. **대규모 diff 처리**: 변경 파일이 30개 초과 또는 변경 라인이 2000줄 초과이면, 리뷰할 디렉토리나 파일 타입을 사용자에게 물어 범위를 축소한다.

### Phase 2: 구조화된 코드 리뷰

1. `git diff <base>...HEAD`로 전체 diff를 읽는다.
2. 아래 파일은 리뷰에서 제외한다:
   - `.nuxt/`, `node_modules/`, `.output/` 내 파일
   - 락 파일 (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`)
   - 자동 생성 파일 (`*.generated.ts`, `*.d.ts` 중 빌드 산출물)
3. 파일별로 해당하는 평가 기준을 대조하며 검토한다.
4. 각 발견사항을 우선순위에 따라 분류한다:
   - **[p1] 반드시 수정**: 버그, 런타임 에러, 보안 취약점, 팀 표준 위반 중 기능에 영향을 주는 것
   - **[p2] 강력 권장**: 컨벤션 위반, 타입 누락, 유지보수 부담을 주는 패턴
   - **[p3] 권장**: 코드를 더 좋게 만들지만 위반은 아닌 개선사항
   - **[p4] 사소**: 스타일 지적, 네이밍 선호, 사소한 가독성
5. 크로스파일 이슈도 점검한다:
   - 변경된 파일 간 패턴 불일치
   - 타입 변경 후 사용처가 업데이트되지 않은 경우
   - import/export 정합성

### Phase 3: 리뷰 리플렉션 (자기 검증)

모든 코멘트를 최종 출력 전에 재검증한다. 각 코멘트에 대해 스스로 묻는다:

- 인용한 평가 기준이 이 특정 코드 컨텍스트에 실제로 적용되는가?
- 작성자가 이 선택을 의도적으로 했을 수 있는가? (프로젝트 컨벤션, 기술적 제약)
- 제안한 수정이 실제로 올바르고, 사이드 이펙트는 없는가?
- 전체 컨텍스트를 보지 못해 생긴 오탐은 아닌가?

오탐으로 판단되면 해당 코멘트를 최종 출력에서 제거한다. 이 과정은 내부 검증이며 출력에 포함하지 않는다.

### Phase 4: 최종 출력

아래 출력 형식에 따라 최종 리뷰를 작성한다.

## 코멘트 형식

각 코멘트는 다음 구조를 따른다:

```
### [p1] src/components/UserCard.vue:45

- **기준**: VUE-002 (defineProps 제네릭 타입)
- **내용**: Props가 런타임 선언 방식으로 되어 있어 TypeScript 타입 안전성이 보장되지 않습니다.
- **제안**:
  ```ts
  // Before
  const props = defineProps({ name: String, age: Number });
  // After
  const props = defineProps<{ name: string; age: number }>();
  ```
- **사이드 이펙트**: 없음. 런타임 동작 동일.
- **제안 이유**: 제네릭 형태는 IDE 자동완성과 타입 추론에서 우수하며 팀 표준입니다.
```

## 출력 형식

```
## 코드 리뷰 결과

### 리뷰 범위
- 베이스: `main`
- 브랜치: `feature/user-profile`
- 변경 파일: N개 (파일 목록)
- 변경 의도: (1줄 요약)

---

### [p1] 반드시 수정 (N건)

(코멘트들)

### [p2] 강력 권장 (N건)

(코멘트들)

### [p3] 권장 (N건)

(코멘트들)

### [p4] 사소 (N건)

(코멘트들)

---

### 좋은 점

- (코드에서 잘 된 부분 관찰)

### 추가 리뷰 제안

- `UserCard.vue` — 250줄 초과. `vue-component-review` 스킬로 컴포넌트 상세 리뷰를 권장합니다.
```

## 주의사항

- **코드 수정 금지**: 사용자가 수정을 요청하지 않은 경우 리뷰만 수행한다. 수정이 필요하면 별도로 요청받는다.
- **프로젝트 지침 우선**: 프로젝트 전용 컨벤션과 팀 공통 지침이 충돌하면 프로젝트 지침을 따르되, 차이를 사용자에게 알린다.
- **생성 파일 제외**: `.nuxt/`, `node_modules/`, 자동 생성 파일, 락 파일은 리뷰하지 않는다.
- **단일 파일 심층 리뷰 연계**: 개별 `.vue` 파일의 체크리스트 기반 상세 리뷰가 필요하면 `vue-component-review` 스킬 사용을 제안한다.
- **커밋 컨벤션 확인**: 브랜치 커밋 메시지의 Conventional Commits 준수 여부는 `rules/commit-pr.md` 기준으로 확인하되, 커밋 메시지 생성은 `conventional-commit` 스킬의 역할이다.