gil/fe-agent-new
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
eebbbea6afaf50340d723100e07e40bad8ed9d2e
fe-agent-new/skills/nuxt-code-review/SKILL.md

5.9 KiB
Raw Blame History

name, description
name description
nuxt-code-review 브랜치/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. 변경 범위를 파악한다: 
    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` 스킬의 역할이다.