변경 사항 검토하기
이 스킬은 지침이며, 완전한 체크리스트가 아닙니다. 변경 사항의 라이브 베이스와 정확한 헤드를 가져와 확인하고, 프로필의 commands.change-scope 명령어로 변경된 경로를 나열한 후 diff와 디자인을 이해하기에 충분한 주변 코드를 읽으십시오. 리타겟이나 병합 후에는 베이스를 다시 설정하십시오. 스타일보다는 정확성, 생명주기, 보안, 중단된 필수 동작에 우선순위를 두십시오. 사소한 리스트보다는 하나의 입증된 차단 이슈가 있는 짧은 리뷰가 더 좋습니다.
diff를 판단하기 전에 요구사항을 읽으십시오. 변경된 경로를 아래 정보 소스에 매핑하고, 각 소유 페이지를 연 후에만 해당 요구사항에 대해 diff를 읽으십시오. 규칙을 기억에 의존하여 diff를 판단하는 것은 위반 사항이 리뷰를 통과하게 만드는 방법입니다.
진실의 소스
AGENTS.md(루트 및 각 수정된 서브트리): 상위 명령..agents/project-profile.md: 명령어, 활성화된 표면, 표면별 증거, 프로젝트별 규칙.docs/defensive-patterns/: 리뷰에서 적용되는 규칙, 아티팩트 패밀리당 한 페이지; diff가 닿는 모든 페이지를 읽으십시오.docs/AGENTS.md및 docs-standard: 문서 배치 및 규율.- prose-standard: 주석, 문서, 프롬프트, 표시 문자열에 필요한 범위와 편집 판단.
- error-handling: 실패 분류, 소유권, 격리, 보장, 보고.
- lifecycle-review: 플러그인, 서비스, 컴포넌트에서의 싱글톤 상태, 취소되지 않은 효과, 정리 순서.
- test-reliability: 리소스를 소유하거나 비동기적이거나 불안정한 테스트의 격리 및 회귀 방지.
.agents/notes/: 디자인 근거. Agent 노트와의 불일치는 자동 거부가 아닌 디자인 논의로 취급하십시오.- 프로필이
surfaces.ui를 활성화한 경우,ui-ux-review및responsive-ui스킬.
차단 요구사항
- 새로운 산문은 의미론적 리뷰를 받습니다. 추가되거나 변경된 모든 마크다운 문단, API 문서, 주석, 프롬프트, 설명, 진단 메시지, 표시 문자열에 prose-standard를 적용하십시오. 자동화된 검사는 정확성, 배치, 범위를 확립하지 않습니다.
- 문서는 코드와 일치해야 합니다. 구성, 기본값, 오류, 와이어 필드, 이벤트, 공개 동작은 동일한 diff에서 소유 README 및 API 문서를 업데이트합니다. 구현 설명, 테스트 워크스루, 리뷰 기록, 중복된 근거를 지적하십시오.
- 소유권 및 정리. 생명주기가 있는 플러그인, 서비스, 컴포넌트 코드의 경우, 변경된 동작과 영향을 받는 소비자에 lifecycle-review를 적용하십시오. 각 새 등록은 폐기를 증명해야 합니다.
- 필요한 증거가 존재해야 합니다. 작성자가 diff에 대한 관련 검사를 실행했는지 확인하고(pre-push-checks 스킬 참조), CI가 나머지를 커버하는지 확인하십시오. 둘 다 감지할 수 없는 의미론적 격차를 검토하십시오.
- 로컬라이즈된 UI 복사본. 프로필이
surfaces.localized-ui를 활성화한 경우, 마크업, 템플릿, 헬퍼 반환값, 접근성 속성, 컴포넌트 기본값에 포함된 제품 텍스트를 거부하고, 로케일 메커니즘과 각 영향을 받는 로케일의 증거를 요구하십시오. 사용자, 모델, 와이어 데이터는 그대로 유지됩니다. - 브레이킹 체인지는 기록되어야 합니다. 프로필이
surfaces.public-api를 활성화한 경우, 외부에서 인지 가능한 중단은 동일한 diff에 업그레이드 가이드를 포함해야 합니다(upgrade-guide 스킬 참조).
수동 검사
- 의도 및 인터페이스 계약: 변경된 모든 인터페이스의 양쪽을 추적하십시오. 구현이 설명 및 Agent 노트(오류, 취소, 소유권, 폐기 포함)와 일치하는지 확인하십시오.
- 오류 처리: 이후 작업의 전제 조건이 유지된다는 것을 상태 소유자가 확인하지 않는 한, catch-and-continue를 거부하십시오.
- 생명주기 및 동시성: 비동기 설정, 콜백, 프로세스, 또는 종료의 경우, 게시 전 경합, await 중 취소, 독립적인 오류 보고, 콜백 격리, 재진입 전 소유권, 완전한 분리 정리, 조용한 폐기를 확인하십시오.
- 기능 및 소비자 적합성: 모든 현재 소비자를 추적한 후, 소비자별 동작이 공유 인터페이스로 유출되는 것을 지적하십시오. 역방향도 지적하십시오: 유일한 호출자가 하나의 내부 소비자인 일반 서비스의 새 공개 메서드; 대신 생성 시 해당 소비자에게 전달되는 비공개 기능을 선호하십시오.
- 범위, 소유권 및 필요성: 각 추상화, 상태 머신, 옵션, 방어적 복사본, 호환성 경로를 현재 계약, 프로덕션 소비자, 소유 모듈에 매핑하십시오. 관련 없는 기능과 추측성 일반화에 도전하십시오.
- 구성 및 공개 선택: 각 기본값, 공개 연산 집합, 형식, 가져온 외부 개념을 지지하는 현재 소비자 증거 또는 선례가 무엇인지 질문하십시오. 해당 증거가 없을 때 명시적인 선택 또는 연기를 요구하십시오.
- 모델 관점: 프로젝트가 모델에 프롬프트, 도구 스키마, 또는 결과를 보낼 때, 모델이 받는 정확한 텍스트를 검사하십시오. 모델의 작업 범위를 벗어난 개념을 지적하고, 안정적인 텍스트는 그대로, 동적 동작은 테스트 또는 스냅샷을 통해 확인하십시오.
- 강제성: 각 거부 경로를 실행하는 연산까지 추적하십시오. 스키마, 프롬프트, 퍼사드, 래퍼, 리스너 순서를 우회할 수 있는 직접 및 대체 호출자를 실행하십시오.
- 차용 및 파생 상태: 각 유지된 값이 차용된 것인지 소유된 것인지 판단한 후, 알림과 모든 캐시, 프롬프트, UI 메아리, 재생, 쿼리 뷰를 문서화된 성공 지점 및 권위 있는 소스까지 추적하십시오.
- 경계는 최종 연산을 포괄합니다: 래퍼와 메타데이터를 포함하여 완전히 방출되거나 유지된 결과의 소유자를 찾으십시오. 아주 작은 한계, 정확한 한계, 과도하게 큰 단일 청크, 멀티바이트 텍스트를 바이트 한계에 대해 조사하십시오.
- 실제 진입 경로: 테스트는 관련된 경우 출하된 로더, 바이너리, 워커, 또는 서브프로세스를 실행합니다. 수동으로 조립된 테스트 설정은 잘못된 내보내기를 잡아내지 못합니다.
- 테스트 강도: 단언문은 의도된 회귀에서 실패하고, 구현을 다시 설명하기보다 외부 상태, 로그, 이벤트, 또는 폐기를 확인해야 합니다. 커버리지는 필요하지만 시나리오가 올바르다는 증거는 아닙니다.
- 음성 제어: 변경된 각 수용 규칙에 대해 의도적으로 유효하지 않은 사례가 실제 실행기를 통해 실패하는지 확인하십시오.
- 구현된 Agent 노트는 출하된 현실과 일치합니다: 변경 사항이 제안된 노트를 구현하는 경우, 동일한 diff에서 현재 시제의 출하된 상태로 이동하여 다시 작성하십시오.
- 번역: 양쪽의 의미와 용어를 비교하십시오. 일치하는 구조는 번역 품질을 증명하지 않습니다.
결과 보고
결함, 위치, 영향, 증거를 명시하십시오. 가장 좁은 관련 diff 범위에 인라인으로 지역화된 결함을 배치하고, 교차적인 아키텍처, 범위, 종합을 위해서는 최상위 코멘트를 사용하십시오. 차단 이슈와 제안을 분리하고, 통과하는 검사에 의해 이미 적용된 이슈는 생략하십시오. 리뷰를 받을 때는 각 주장을 확인하고 기술적인 근거로 수정하거나 반박하십시오.