review-and-fix

현재 브랜치의 로컬 변경사항을 직접 읽고 코드 리뷰를 수행한 뒤, 발견된 문제를 수정·커밋·푸시하는 커맨드.

$ARGUMENTS로 처리할 최소 심각도를 받는다. 예: /review-and-fix minor

• critical → 🔴 Critical만 처리
• major (기본값, 미지정 포함) → 🔴 Critical + 🟠 Major 처리
• minor → 🔴 Critical + 🟠 Major + 🟡 Minor 전체 처리

절차

1단계: 로컬 변경 범위 확인

1. 현재 브랜치 확인: git branch --show-current로 브랜치 이름을 가져온다.
2. develop/main 경고: 현재 브랜치가 develop 또는 main이면 경고하고 중단한다.
3. 작업트리 상태 확인: git status --short로 staged/unstaged/untracked 변경을 확인한다.
4. 비교 기준 확인: origin/develop이 있으면 기본 기준으로 사용하고, 없으면 develop을 사용한다.
5. 공통 조상 확인: git merge-base HEAD <기준브랜치>로 현재 브랜치의 로컬 변경 기준점을 찾는다.

2단계: diff 수집

1. 브랜치 diff 수집: git diff <merge-base>...HEAD로 기준 브랜치 이후의 커밋 변경사항을 수집한다.
2. 작업트리 diff 수집: staged 변경은 git diff --cached, unstaged 변경은 git diff로 수집한다.
3. 변경 파일 목록 파악: git diff --name-only <merge-base>...HEAD, git diff --cached --name-only, git diff --name-only, git status --short의 ?? 파일을 합쳐 중복 없이 확인한다.
4. untracked 파일 확인: ?? 파일은 diff가 없더라도 파일 전체를 Read로 읽어 리뷰 대상에 포함한다.
5. 변경 없음 처리: 수집된 diff와 변경 파일이 모두 없으면 사용자에게 알리고 종료한다.

3단계: 코드 리뷰

변경된 각 파일을 Read로 읽어 diff뿐 아니라 파일 전체 컨텍스트를 파악한 뒤 문제점을 찾는다.

리뷰 관점

• 보안: 인젝션, XSS, 인증/인가 누락, 민감 정보 노출
• 정합성: 로직 오류, 엣지 케이스 미처리, 누락된 에러 처리
• 성능: 불필요한 쿼리, N+1, 무한 루프 가능성
• 아키텍처: CLAUDE.md에 명시된 레이어드 아키텍처 원칙 위반 여부
  • 백엔드: Router → Service → Repository 분리
  • 프런트엔드: Presentation → Domain → Data 분리
• 코드 품질: 네이밍, 중복 코드, 불필요한 복잡도, console.log 잔존

심각도 분류

• 🔴 Critical: 보안 취약점, 데이터 손실/훼손, 크래시/무한 루프 유발
• 🟠 Major: 로직 오류, 누락된 에러 처리, 성능 문제, 아키텍처 원칙 위반
• 🟡 Minor: 코드 스타일, 네이밍 개선, 불필요한 코드, 타입 미비

4단계: 리뷰 결과 정리 & 사용자 확인

$ARGUMENTS (미지정 시 major) 기준으로 필터링한 뒤 아래 형식으로 출력한다:

[1] 🔴 Critical — API/app/services/auth.py:194
    JWT 시크릿이 하드코딩되어 있음...

[2] 🟠 Major — Web/src/pages/login.tsx:28
    returnTo를 검증 없이 리디렉션에 사용...

• 발견된 항목이 없으면 사용자에게 알리고 종료한다.
• 출력 후 사용자에게 수정 진행 여부를 확인받는다.

5단계: 코드 수정

각 항목을 순서대로 처리한다: