FE 코드 리뷰

FE 코드 리뷰은(는) 무엇을 하나요?

기본 규칙

• 사용자의 언어를 따릅니다. 사용자가 중국어로 작성하면 간체 중국어로 응답합니다.
• 섹션 제목, 상태 레이블 및 권장 사항을 사용자 언어로 번역합니다. 필요할 때는 영어 레이블을 그대로 유지합니다(예: Blocking：必须修改).
• 중국어 요청의 경우 선택한 모드에 대해 중국어 템플릿을 사용합니다. Overall Conclusion, Review Scope, Test Gaps 또는 Final Recommendation과 같은 영어 전용 섹션 제목을 사용하지 마십시오.
• 기본값은 읽기 전용 리뷰입니다.
• 사용자가 명시적으로 요청하지 않는 한 파일을 수정, 포맷, 커밋, 푸시, 리셋, 패키지 설치, 브랜치 변경 또는 파괴적인 명령을 실행하지 마십시오.
• 리뷰 요청, 리뷰 품질 평가 또는 리뷰 보고서 출력 요청은 채팅 출력만 허용합니다. 사용자가 파일 아티팩트나 코드 변경을 명시적으로 요청하지 않는 한 보고서, 계획, 할 일, Markdown 또는 소스 파일을 생성하거나 업데이트하지 마십시오. Agent, Build, Write 또는 이와 유사한 이름의 클라이언트 모드가 이 경계를 무효화하지 않습니다.
• 실제 코드, diff, 호출 경로, 데이터 흐름, 패키지 버전 및 런타임 계약을 기반으로 결과를 도출합니다.
• 이름만으로 의미를 유추하지 마십시오.
• 정적 검사 결과를 런타임 검증으로 제시하지 마십시오.
• 모호한 문제를 보고하지 마십시오. 트리거 조건, 영향, 근본 원인, 제안된 수정 사항 및 검증 방법을 설명하십시오.
• 명확한 문제가 발견되지 않으면 그렇게 직접 말하고 남은 위험이나 확인되지 않은 영역을 나열하십시오.

범위 탐색

요청된 범위를 검사합니다. 사용자가 범위를 지정하지 않으면 모든 커밋되지 않은 변경 사항을 리뷰합니다. 인벤토리를 한 번만 수집합니다.

요청된 범위가 모든 커밋되지 않은 변경 사항이고, 승인된 Skill/workspace 경계 내에서 scripts/collect-review-context.mjs를 사용할 수 있으며 Node.js를 사용할 수 있는 경우, 별도의 Git 인벤토리 명령을 실행하는 대신 다음을 실행합니다:

node <skill-directory>/scripts/collect-review-context.mjs --workspace "$PWD"

이 스크립트는 읽기 전용이며 저장소 루트, HEAD, 상태, 스테이징되지 않은 stat 및 패치, 스테이징된 패치, 추적되지 않은 파일, git diff --check 및 CodeGraph 존재 여부를 반환합니다. 항상 완전한 커밋되지 않은 작업 트리를 수집합니다. 스테이징 전용, 커밋, 병합 커밋, 브랜치, PR, 범위 또는 경로 범위 리뷰에는 실행하지 마십시오. 요청된 범위 밖의 변경 사항을 읽을 수 있기 때문입니다. 해당 범위에는 일치하는 제한된 Git 명령을 사용하십시오. 모든 커밋되지 않은 리뷰의 경우 수집기 출력을 재사용하고 동등한 명령을 다시 실행하지 마십시오. 승인된 경계 내에서 스크립트를 실행할 수 없는 경우 클라이언트가 지원할 때 한 번의 읽기 전용 배치로 동일한 증거를 수동으로 수집하십시오:

git status --short
git diff --stat
git diff --find-renames
git diff --cached --find-renames
git ls-files --others --exclude-standard

리뷰 전에 비교 기준을 설정하고 보고하십시오:

• 커밋되지 않은 변경 사항: HEAD vs 작업 트리 (스테이징, 스테이징되지 않음 및 관련 추적되지 않은 파일 포함)
• 스테이징된 변경 사항: HEAD vs 인덱스
• 커밋: 부모 vs 커밋
• 브랜치 또는 PR: 병합 기준 vs 대상 헤드 (사용자가 다른 범위를 지정하지 않은 경우)
• 병합 커밋: 첫 번째 부모 vs 병합 커밋 (사용자가 다른 부모 또는 기준을 지정하지 않은 경우)

패키지 또는 구성 파일이 변경된 경우 의존성 및 빌드 영향을 검사합니다. 항상 요청된 범위, 비교 기준, 수정된 파일, 스테이징된 파일, 스테이징되지 않은 파일, 추적되지 않은 파일 및 실행되었거나 건너뛴 검증 명령을 요약합니다.

수정 리뷰(Fix Review)의 경우 이전 리뷰 보고서 또는 결과 및 수정 diff도 식별합니다. 원래 기능 범위를 이후의 수정 범위와 분리하여 유지합니다.

저장소 루트에 .codegraph/가 있고 CodeGraph를 사용할 수 있는 경우 광범위한 grep/find 대신 CodeGraph를 먼저 사용하여 심볼, 호출 경로 및 영향 범위를 이해합니다.

다음 순서로 증거를 사용합니다:

1. 저장소 소스, diff, 호출 경로, 테스트, 구성, 잠금 파일 및 프로젝트 문서.
2. 설치된 의존성 유형 및 해결된 로컬 버전의 소스.
3. 코드 리뷰를 허용하는 도구 계약을 가진 공식 문서 (로컬에서 버전에 민감한 프레임워크 또는 라이브러리 동작을 설정할 수 없는 경우에만).

현재 공식 Context7 MCP 도구 계약은 코드 리뷰를 허용하지 않습니다. 이 스킬을 수행하는 동안 직접적으로든 간접적으로든 Context7을 사용하지 마십시오. 여기에는 하위 에이전트, 대리자, 프록시, 래퍼 또는 다른 도구나 세션에 리뷰를 대신 호출하도록 요청하는 것이 포함됩니다. 리뷰 작업을 문서화 질문으로 재구성, 분해, 정리 또는 레이블을 변경하여 제한을 우회하지 마십시오. 결론이 외부 의미론에 의존하고 허용된 권위 있는 소스를 사용할 수 없는 경우 Cannot Verify로 표시하고 누락된 증거를 식별합니다.

외부 문서 서비스를 사용할 때는 검증에 필요한 공개 라이브러리, 버전, API 또는 정리된 동작 질문만 전송하십시오. 비공개 소스 코드, diff, 저장소 경로, 내부 API 데이터, 자격 증명, 토큰, 사용자 데이터 또는 독점 식별자를 절대 전송하지 마십시오.

조건부 브라우저 런타임 증거

다음 모든 조건이 충족되는 경우에만 Playwright 또는 다른 사용 가능한 브라우저 자동화 도구를 사용하십시오:

• 변경된 동작이 브라우저에서 관찰 가능하고 런타임 증거가 결과를 실질적으로 확인하거나 반박할 수 있는 경우(예: 라우팅, 폼, 비동기 UI 상태, 저장소 또는 쿠키 동작, hydration, 포커스, 스크롤, 반응형 오버플로 또는 요청 순서).
• 로컬 경로, URL, 상호 작용 또는 테스트 하네스와 같은 구체적인 진입점이 존재하고 예상되는 관찰 가능한 결과가 요구 사항, 기준 동작 또는 기존 테스트 계약에서 명시적인 경우.
• 의존성 설치, 프로젝트 구성 변경 또는 저장소에 생성된 아티팩트를 작성하지 않고도 실행 가능한 적절한 로컬 또는 격리된 테스트 환경이 이미 있는 경우.
• 초기 상태가 제어 가능하고 반복 가능하며 프로덕션 데이터나 실제 계정에 의존하지 않고 각 실행 전에 재구성할 수 있는 경우.
• 경로가 격리되어 있으며 프로덕션 액세스, 실제 결제, 실제 사용자 데이터, 파괴적인 작업 또는 되돌릴 수 없는 외부 부작용 없이 실행할 수 있는 경우.

저장소, 프로덕션 시스템 및 실제 계정과 관련하여 브라우저 검증을 읽기 전용으로 유지합니다. 시나리오에 필요한 경우 격리된 로컬 브라우저 상태가 변경될 수 있지만 실제로 가능할 때 재설정하고 해당 상태 변경을 제품 데이터 검증으로 취급하지 마십시오.

환경 및 URL 유형, 진입점, 브라우저 및 뷰포트, 초기 상태 및 재현 방법, 예상 결과, 작업, 관찰된 결과 및 관련 콘솔 또는 네트워크 요약을 기록합니다. 자격 증명, 토큰, 개인 데이터, 요청 본문 및 민감한 응답 내용을 마스킹합니다. 런타임 증거가 필요하지만 게이트가 충족되지 않는 경우 Cannot Verify를 사용하고 사용할 수 없는 환경, 상태, 기대 또는 기능을 명시합니다.

브라우저 자동화는 기록된 환경에서 실행된 경로만 증명합니다. 브라우저 검사 통과가 모든 브라우저 또는 뷰포트에서의 동작을 증명하지 않으며 실제 WebView, Native 브리지, 장치, 백엔드, 배포, 모니터링 또는 프로덕션 검증을 대체하지 않습니다.

모드 선택

• 일상적인 변경, 작은 PR, 버그 수정 및 로컬 리팩터링에는 기본적으로 빠른 리뷰(Quick Review)를 사용합니다.
• 결제, 인증, 라우팅/내비게이션, WebView 브리지, RTC/오디오/비디오, SSR/hydration, i18n, 전역 상태/스토어, 캐시/지속성, 빌드/배포 구성, 의존성 업그레이드, 공유 모듈, 성능에 민감한 코드, 릴리스 브랜치, 모듈 간 동작 또는 대규모 리팩터링에는 심층 리뷰(Deep Review)를 사용합니다.
• 사용자가 수정 사항을 재리뷰하거나, 이전 결과를 확인하거나, 리뷰 의견이 해결되었는지 확인하거나, 수정 사항으로 인한 회귀를 감지하도록 요청할 때 수정 리뷰(Fix Review)를 사용합니다.

리뷰 전에 정확히 하나의 모드 참조를 로드합니다:

• 빠른 리뷰: references/quick-review.md
• 심층 리뷰: references/deep-review.md
• 수정 리뷰: references/fix-review.md

수정 리뷰의 경우 현재 대화에서 이전 결과를 사용할 수 있으면 사용합니다. 그렇지 않으면 사용자에게 이전 리뷰 보고서, 문제 목록 또는 읽을 수 있는 경로를 제공하도록 요청합니다. 사용 가능한 기준 없이 이전 결과를 만들거나 문제가 해결되었다고 주장하지 마십시오.

기술 감지

프로젝트 파일을 검사하고 일치하는 참조만 로드합니다:

• React: React, React DOM, Next.js, Remix, JSX/TSX 또는 hooks에 대해 references/react.md를 로드합니다.
• Vue: Vue, Nuxt, Pinia, .vue 파일 또는 Composition API에 대해 references/vue.md를 로드합니다.
• TypeScript: TypeScript 프로젝트 또는 변경된 TypeScript 계약에 대해 references/typescript.md를 로드합니다.
• JavaScript: JavaScript 프로젝트 또는 런타임 형태가 중요한 코드에 대해 references/javascript.md를 로드합니다.
• Hybrid/WebView: 브리지, 네이티브 계약, WebView, 앱 셸, 저장소, 키보드, 안전 영역, 오디오 또는 비디오에 대해 references/hybrid-webview.md를 로드합니다.
• 릴리스 위험: 심층 리뷰, 릴리스 브랜치, 기능 플래그, 롤아웃, 모니터링, 롤백 또는 고위험 흐름에 대해 references/release-risk.md를 로드합니다.

빠른/수정 증거 규율

다음 필수 실행 규칙을 빠른 리뷰(Quick Review) 및 수정 리뷰(Fix Review)에 적용합니다. 이 규칙은 필요한 범위를 줄이지 않으면서 반복적인 탐색을 줄입니다:

• 클라이언트가 일괄 처리를 지원하는 경우 증거 그룹당 하나의 제한된 읽기 전용 라운드 트립을 사용합니다: 선택한 Skill/참조 파일, 초기 컨텍스트 수집기 또는 수동 대체, 변경된 소스 및 직접 소비자 검색, 나머지 적용 가능한 검증. 결과가 관리하기 어려울 정도로 크지 않도록 하거나 첫 번째 결과가 새로운 해결되지 않은 계약을 노출할 때만 그룹을 분할합니다. 명령 수를 낮추기 위해 관련 없는 대용량 파일을 연결하지 마십시오.
• 초기 Git 인벤토리를 고정하고 재사용합니다. 읽기 전용 리뷰에서는 마지막에 status, name-status, stat, 스테이징된 diff, 추적되지 않은 파일 또는 변경되지 않은 diff 쿼리를 반복하지 마십시오. 호스트 평가자가 리뷰 모델이 아닌 독립적인 사후 실행 무결성 비교를 수행합니다.
• 각 선택된 명령, diff, 기준 파일 및 중복되는 소스 범위를 한 번 읽습니다. 필요한 범위를 포함하는 하나의 라인 번호가 있는 읽기를 선호합니다. 반복된 읽기 또는 검색 전에 특정 해결되지 않은 증거 질문을 식별합니다. 기존 출력이 이미 답변한 경우 명령을 건너뜁니다.
• 변경된 파일 및 직접적인 영향을 받는 경로를 알게 된 후에는 .에서 광범위한 rg 검색 또는 필터링되지 않은 rg --files/저장소 파일 인벤토리를 실행하지 마십시오. 변경된 소유자, 명명된 심볼 및 직접적인 영향을 받는 경로로 검색 범위를 지정합니다. 구체적인 일치가 다른 소비자 또는 계약을 노출할 때만 확장합니다.
• 변경된 파일 유형, 임포트 및 최대 하나의 관련 manifest 읽기에서 기술을 감지합니다. 패키지, 잠금, 빌드 또는 TypeScript 구성은 변경되었거나 결과가 해결된 버전 또는 컴파일러/빌드 계약에 의존하는 경우에만 더 깊이 검사합니다. 일반 체크리스트를 완료하기 위해 존재하지 않는 구성 또는 잠금 파일을 조사하지 마십시오.
• 존재하는 것으로 알려진 경로 또는 하나의 제한된 파일 이름 글로브 쿼리를 사용하여 직접적으로 관련된 테스트를 한 번 검색합니다. 해당 검색에서 적용 가능한 테스트가 없음을 확인하면 갭을 기록합니다. 새로운 증거 없이 추측된 테스트 디렉토리 이름 또는 대체 저장소 전체 패턴을 재시도하지 마십시오.
• 동일한 동작 계약을 실행하는 독립적인 표현 또는 결정론적 검사를 하나의 검증 라운드 트립으로 결합합니다. 최종 설명을 준비하기 위해 diff를 다시 실행하지 마십시오.
• 사용자 또는 평가자가 합성 HEAD를 원래 문제 기준으로 명시적으로 선언하는 경우 현재 HEAD와 수정 diff를 확인한 후 해당 선언된 기준을 사용합니다. 마감이 해당 객체에 의존하지 않는 경우 각 객체를 조사하는 대신 사용할 수 없는 원래 커밋 객체를 증거 한계로 기록합니다.
• 증거가 충돌하거나, 변경된 조건이 분류되지 않았거나, 직접적인 영향을 받는 계약이 해결되지 않았거나, 발견 사항에 여전히 트리거와 영향이 없는 경우 이러한 그룹을 넘어 계속합니다. 이는 완전성 규칙이며 하드 명령 또는 토큰 상한이 아닙니다.
• 요청된 기준과 diff가 설정되고, 범위 내의 모든 변경된 조건 원장 항목이 설명되고, 보고된 각 발견 사항에 충분한 증거가 있고, 필요한 검증이 완료되거나 명시적으로 제한되고, 선택된 출력 계약을 일관되게 채울 수 있을 때 탐색을 중지합니다. 주관적인 확신을 높이기 위해 검색 범위를 넓히지 마십시오.

변경 전후 동작 분석

모든 모드에서 이 분석을 수행합니다. 변경된 라인뿐만 아니라 동작을 비교합니다:

1. 변경 전 동작과 변경 후 의도된 동작을 식별합니다.
2. 제거되거나 약화되거나 의도치 않게 유지된 동작을 감지합니다.
3. 누락된 분기, 가드, 폴백, 정리, 취소, 재시도 및 오류 처리를 확인합니다.
4. 발견 사항의 우선순위를 지정하기 전에 요청된 diff에서 수정된 결정 블록 내에서 추가, 변경, 이동, 분할 또는 유지된 모든 조건, 가드, 폴백, 기본값 및 조기 반환에 대한 간결한 내부 변경 조건 원장을 구성합니다. 텍스트적으로 변경되지 않은 가드는 주변 제어 흐름, 반환 동작 또는 상태 쓰기가 변경된 경우에도 범위 내에 유지됩니다. 각 분기가 전후에 취하는 런타임 값을 비교합니다. 기본적으로 원장을 출력하지 마십시오.
5. 해당 원장에서 null 또는 undefined의 부재와 0, false 또는 빈 문자열과 같은 유효한 falsy 값을 구분합니다. 해당 분기 뒤의 상태 쓰기에 대해 이전 truthy 또는 비어 있지 않은 값에서 각 유효한 falsy 값으로의 전환을 직접적인 영향을 받는 소비자를 통해 추적합니다. 현재 값만 별도로 검사하지 마십시오.
6. 최종 결정 전에 모든 원장 항목을 설명합니다: 동작 보존, 증거 갭 또는 발견 사항으로 분류합니다. 보존된 동작 자체가 가시적인 런타임 계약 및 상태 전환에 대해 여전히 올바른지 확인한 후에만 동작 보존을 사용합니다. 수정된 결정 블록에 실질적인 결함이 유지되면 보고하고 diff에 의해 도입된 회귀가 아닌 유지된 결함으로 식별합니다. 다른 발견 사항의 심각도가 더 높다는 이유만으로 영향을 받는 변경 조건을 생략하지 마십시오.
7. 영향을 받는 호출자, 소비자, 이벤트, API 계약, 저장소, 캐시 및 런타임 데이터 형태를 추적합니다.
8. 동작 확인

…

[번역을 위해 잘림]