88 lines
3.5 KiB
Markdown
88 lines
3.5 KiB
Markdown
---
|
|
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 프리셋과 다름
|
|
- ...
|
|
|
|
### ✅ 좋은 점
|
|
- 간단한 컴포넌트에 잘 맞는 단일 책임 구조
|
|
- ...
|
|
```
|
|
|
|
## 주의사항
|
|
|
|
- 사용자가 리팩토링을 **요청하지 않은 경우** 코드를 직접 수정하지 말고 리뷰만 수행한다.
|
|
- 프로젝트 지침과 공통 지침이 충돌하면 프로젝트 지침을 따르되, 차이를 사용자에게 알린다.
|
|
- 실제 코드 동작 변경(기능 수정)은 리뷰 범위가 아니다. 별도 작업으로 분리 제안한다.
|