---
name: verify-component-review
description: Vue 3 / Nuxt 컴포넌트 파일을 팀 공통 지침 기준으로 리뷰할 때 사용합니다. 사용자가 "이 컴포넌트 리뷰해줘", "컨벤션 맞는지 봐줘", "컴포넌트 체크" 등을 요청하면 트리거됩니다.
---

# Vue 컴포넌트 리뷰

이 skill 은 `.vue` 파일 하나 또는 여러 개에 대해 팀 공통 지침 기준으로 리뷰 체크리스트를
수행합니다. 프로젝트 전용 컨벤션(`.claude/project/conventions.md`)이 있으면 그 규칙을
**우선**합니다.

## 체크리스트

### 1. 파일 구조

- [ ] `<script setup lang="ts">` 를 사용하는가? (Options API 금지)
- [ ] 파일 길이가 팀/프로젝트 제한을 넘지 않는가? (공통 200줄, 프로젝트별 오버라이드 확인)
- [ ] 하나의 컴포넌트가 단일 책임을 지키는가?

### 2. Props / Emits

- [ ] `defineProps<T>()` 제네릭 형태로 타입을 명시했는가?
- [ ] `defineEmits<{ ... }>()` 제네릭 형태로 선언했는가?
- [ ] Props 개수가 많다면 객체 props 로 묶여 있는가?
- [ ] 불리언 prop 은 `is`/`has`/`can`/`should` 로 시작하는가?

### 3. 반응성

- [ ] `ref` 와 `reactive` 를 팀 규칙대로 사용하고 있는가?
- [ ] 불필요한 `reactive` 래핑이 없는가?
- [ ] 계산된 값은 `computed` 로 뽑아냈는가?

### 4. 스타일 (Tailwind)

- [ ] 임의값 클래스(`w-[123px]`) 남용이 없는가?
- [ ] 색상/간격 토큰을 사용하는가? (임의 색상 금지)
- [ ] 조건부 클래스는 `clsx` / `cn` 로 가독성 확보되었는가?
- [ ] 클래스 순서는 `prettier-plugin-tailwindcss` 규칙을 따르는가?

### 5. 네이밍

- [ ] 파일명: `PascalCase.vue`
- [ ] 이벤트 핸들러: `handle*` 또는 `on*` 접두사
- [ ] 상수: `UPPER_SNAKE_CASE`

### 6. 의존성 / 로직

- [ ] 비즈니스 로직이 컴포넌트에 직접 박혀있지 않고 composable 로 추출되었는가?
- [ ] `$fetch` / `fetch` 직접 호출이 없는가? (프로젝트 규칙에 따라 api wrapper 사용)
- [ ] `any` 타입 사용이 없는가?

## 작업 순서

1. 리뷰 대상 파일을 읽는다. 여러 파일이면 하나씩 순차 처리한다.
2. `.claude/project/conventions.md` 가 있으면 먼저 읽고, 공통 규칙과의 차이를 기억한다.
3. 위 체크리스트를 항목별로 점검하고, 위반 사항을 발견하면 **파일명:라인번호** 와
   함께 문제 요약 + 수정 예시를 제시한다.
4. 단순 포맷 이슈는 "Prettier/ESLint 로 자동 해결 가능" 이라고 덧붙인다.
5. 마지막에 우선순위별 요약(Critical / Warning / Nit)을 출력한다.

## 출력 형식

```
## 리뷰 결과: <파일명>

### 🚨 Critical (반드시 수정)
- [라인 23] Props 타입이 `any` 로 선언됨. `defineProps<{ id: string }>()` 로 변경
- ...

### ⚠️ Warning (수정 권장)
- [라인 45] 파일 길이 210줄. 하위 컴포넌트 2개로 분리 검토
- ...

### 💡 Nit (선택)
- [라인 12] 클래스 순서가 Tailwind 프리셋과 다름
- ...

### ✅ 좋은 점
- 간단한 컴포넌트에 잘 맞는 단일 책임 구조
- ...
```

## 주의사항

- 사용자가 리팩토링을 **요청하지 않은 경우** 코드를 직접 수정하지 말고 리뷰만 수행한다.
- 프로젝트 지침과 공통 지침이 충돌하면 프로젝트 지침을 따르되, 차이를 사용자에게 알린다.
- 실제 코드 동작 변경(기능 수정)은 리뷰 범위가 아니다. 별도 작업으로 분리 제안한다.