김경종
2.5 KiB
2.5 KiB
name, description
| name | description |
|---|---|
| review | Use when reviewing repository changes against AGENTS.md, architecture decisions, tests, and build requirements. |
Repository Review
AGENTS.md를 먼저 읽고 변경 범위와 직접 관련된 제품 문서, 코드와 테스트만 추가로
읽는다. context_files가 있으면 해당 목록을 우선한다. 전체 docs/를 일괄 읽도록
요구하지 않는다.
사용자가 범위를 지정하지 않으면 현재 작업 트리의 변경을 리뷰한다. 실제 결함을 심각도순으로 제시하고 각 finding에 파일과 줄 번호, 영향, 근거와 수정 방안을 적는다.
다음을 해당 변경에 적용할 수 있는 범위에서 확인한다.
- 공개 C# API의 접근성·호환성·nullability 계약, 프로젝트 참조 방향과 관련 ADR
- 제품 프로젝트가 테스트 프로젝트를 참조하지 않는지 확인
- 새 C# 동작을 먼저 재현한 실패 테스트의 명령·결과와 구현 후 회귀 검증
- 실제
global.json,.sln/ SDK 스타일.csproj, version 2.harness/config.json에 따른 .NET 8 SDK 선택, 각 제품·테스트 프로젝트의 실제 TFM 평가와 restore/build/test 결과; 상속된 props와 속성 참조를 포함한TargetFramework/TargetFrameworks도 확인 testProjects가 전체 제품 테스트를 포함하고 각 프로젝트의 현재 TRX에 실행된 테스트가 있는지 확인; 테스트 0건·skip-only·누락·과거 결과는 성공 근거가 아니다- nullable 진단, 경고의 오류 처리와 범위 밖 변경
- async 코드 변경 시 취소·예외 전파,
IDisposable/IAsyncDisposable사용 변경 시 자원 해제 확인; 모든 제품에 async나 DI를 요구하지 않는다 - C# 대응 테스트 파일 존재를 red-green 증거로 혼동하지 않는지,
Program.cs등의 면제가 정확한 경로와 이유로 한정되고 제품 검증을 우회하지 않는지 확인 - Harness 변경이면 관련 Python 테스트와 운영 문서의 필드·동작 일치
명시적으로 validation: docs-only인 문서 step은 실제 변경이 허용된 문서 경로에만
있을 때 제품 build를 생략할 수 있다. 그 외에는 기존 전체 검증을 사용한다. 실행하지
못한 검사는 성공으로 추정하지 않고 미검증과 이유를 기록한다.
finding 뒤에는 아키텍처, 기술 스택, 테스트, 필수 규칙, build 가능 여부를 각각
통과, 실패, 미검증으로 요약한다. finding이 없으면 발견된 문제가 없다고 쓰고
남은 검증 공백을 밝힌다.