---
name: work-mr-reviewer
description: |
  GitLab MR 또는 GitHub PR URL / diff를 받아 팀 공통 지침 기준으로
  코드 리뷰 코멘트 초안을 자동 생성합니다. 리뷰어가 비즈니스 로직에 집중할 수 있도록
  컨벤션/스타일 지적은 AI가 사전 처리합니다.

  다음 상황에서 반드시 사용하세요:
  - "이 MR 리뷰해줘", "MR 코멘트 작성해줘"
  - "이 PR 리뷰해줘", "Pull Request 코멘트 작성해줘"
  - "이 PR 어떤지 봐줘: <URL>"
  - 리뷰어 역할로 MR을 검토하기 전 사전 검토가 필요할 때
---

# GitLab MR 리뷰어 (work-mr-reviewer)

MR URL 또는 diff → 팀 공통 지침 기준 리뷰 코멘트 초안 자동 생성.

## 언제 사용하는가

- MR 리뷰 요청을 받았을 때 사전 분석이 필요할 때
- 리뷰 코멘트 작성 시간을 줄이고 싶을 때
- 컨벤션 위반 사항을 일괄 감지하고 싶을 때

## 입력

- GitLab MR URL 또는 `git diff` 출력
- (선택) 리뷰 우선순위 (컨벤션 중심 / 로직 중심 / 전체)

---

## 작업 순서

### Phase 1: 변경사항 파악

1. MR URL이 제공된 경우 diff를 가져온다.
2. 변경된 파일 목록과 변경 규모를 파악한다.
3. 변경 유형을 분류한다: 신규 기능 / 버그픽스 / 리팩토링 / 설정 변경

### Phase 2: 자동 컨벤션 검토

`verify-component-review` 스킬의 체크리스트를 변경된 Vue 파일에 적용한다:

- `<script setup lang="ts">` 사용 여부
- `defineProps<T>()` / `defineEmits<T>()` 제네릭 형태
- `any` 타입 사용 여부
- Tailwind 클래스 7단계 순서
- 네이밍 컨벤션 (camelCase / PascalCase / UPPER_SNAKE_CASE)
- import 순서

### Phase 3: 로직 / 구조 검토

- 컴포넌트 분리 기준 적절성 (200줄 초과 여부)
- 비즈니스 로직의 composable 분리 여부
- 에러 핸들링 / 로딩 상태 처리 여부
- 불필요한 API 호출 또는 상태 중복 여부
- 보안 취약점 (XSS, 민감 정보 등)

### Phase 4: 코멘트 작성

리뷰 코멘트는 아래 형식을 따른다:

```
[등급] 파일명:라인번호
문제: [간단한 설명]
이유: [왜 문제인지 — 팀 규칙 또는 Best Practice 근거]
제안:
\`\`\`
[수정 코드 예시]
\`\`\`
```

등급:
- 🚨 **Blocker** — 반드시 수정 후 머지 (보안, 런타임 에러, 명백한 버그)
- ⚠️ **Major** — 수정 권장 (컨벤션 위반, 성능 문제)
- 💡 **Minor** — 선택적 개선 (가독성, 스타일)
- 💬 **Question** — 로직 확인 필요 (질문 형태)

### Phase 5: 요약

- 전체 변경사항에 대한 한 줄 요약
- Blocker 건수 명시
- 칭찬할 만한 좋은 패턴 1~2개 언급

---

## 출력 형식

```
## MR 리뷰: <MR 제목>

### 변경 요약
- 변경 파일: N개
- 유형: 신규 기능 / 버그픽스 / ...

### 🚨 Blocker (N건)
...

### ⚠️ Major (N건)
...

### 💡 Minor (N건)
...

### 💬 Questions
...

### ✅ 잘된 점
- [좋은 패턴 1~2개]

> 이 리뷰는 AI 초안입니다. 최종 리뷰어의 판단으로 조정해 주세요.
```