리뷰 범위 스킬
목적
코드 변경이 정확히 의도된 대로만 수행되는지 확인합니다—그 이상도, 그 이하도 아닙니다. 이것은 합격/불합격 게이트이며, 피드백 세션이 아닙니다.
사용时机
- TDD 검증 단계
- PR 범위 준수 검토
- 범위 검증이 필요한 모든 코드 리뷰
필요한 입력
context_files
- 구현 계획 또는 요구 사항 문서
- 설계 문서 (있는 경우)
- 검토할 변경된 파일
context_data
commit_details: 이 변경 사항이 수행해야 할 작업requirements: 처리 중인 REQ-* 목록constraints: 충족되어야 하는 CC-* 제약 조건 목록allowed_files: 수정이 허용된 파일 (범위 경계)
절차
1. 범위 경계 설정
입력에서 다음을 식별합니다:
- 반드시 수행해야 할 사항 (요구 사항)
- 반드시 수행하지 말아야 할 사항 (제약 조건)
- 변경이 허용된 파일
- 예상되는 동작
2. 변경 사항 검토
각 변경된 파일에 대해:
- 이 파일이 허용된 집합에 속하는가?
- 변경 사항이 명시된 요구 사항을 해결하는가?
- 요구 사항과 관련 없는 변경이 있는가?
- 변경 사항이 제약 조건을 위반하는가?
3. 결과 보고
모든 검사 통과 시:
ACCEPT
검사 실패 시 위반 사항 나열:
VIOLATIONS:
- <파일>:<라인> - <자신의 말로 설명>
- <파일> - <설명>
[선택 사항] THEMES: <언급할 가치가 있는 패턴>
위반 형식
위반 사항을 위치와 명확한 설명과 함께 자연스럽게 기술합니다:
- src/parser.rs:45 - 커밋 범위에 없는 로깅 인프라 추가됨
- src/config.rs - 허용된 집합 외부의 파일 수정됨
위반 사항에서 패턴을 발견한 경우 언급합니다:
THEMES: 여러 변경 사항이 명시된 요구 사항을 넘어 오류 처리 리팩토링까지 확장됨
최소 변경 편향 확인
구현 에이전트는 목표를 달성하기 위해 가능한 가장 작은 변경을 하려는 편향이 있습니다. 위반 사항을 식별한 후, 다음을 고려하십시오:
위반 사항이 코드를 더 유지보수하기 쉽게 만들 수 있는 잠재적인 리팩토링을 가리키는가? 구현자가 더 나은 구조적 해결책을 외면하고 빠른 수정을 선호했는가?
그렇다면, REFACTORING 섹션에 이를 기록합니다:
REFACTORING: <구현자가 회피한 구조적 개선 사항 설명>
이는 위반 사항이 아니라, 오케스트레이터가 고려할 플래그입니다.
이 스킬이 수행하지 않는 작업
- 위반 사항과 관련 없는 개선 제안
- 일반적인 건설적인 피드백 제공
- 코드 스타일 검토 (이 작업은 review-style 스킬 사용)
이것은 이진 게이트입니다: ACCEPT 또는 VIOLATIONS. 리팩토링 노트는 선택적 플래그이며, 차단 사항이 아닙니다.