game-fe-agent/skills/verify-component-review/SKILL.md

name, description

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

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 프리셋과 다름
- ...

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

주의사항

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