PR 검토은(는) 무엇을 하나요?
PR을 검토하는 절차입니다. 검토 규칙(어조, 댓글 분류, 결정 흐름, 금지 사항)은 Playbook의 "PR Reviews"에 있습니다. 이 스킬은 방법에 관한 것입니다. 여기에 규칙을 다시 설명하지 말고, 적용하세요. Playbook의 "공유 표준"이 모든 곳에 적용됩니다(간결할 것, AI 슬롭 금지, 확인하되 단정하지 말 것, 절대 지어내지 말 것).
검토 전
- 먼저 티켓을 요청하세요. Playbook의 필수 첫 단계에 따라, 티켓을 받기 전까지 diff를 가져오거나 분석하지 마세요. 티켓은 작업 유형(기능 vs 후속 작업 vs 조사)과 수락 기준을 설정하며, 이는 검토 방식을 변경합니다.
- PR 식별: PR 번호/URL이 주어지지 않았다면 요청하세요.
컨텍스트 수집
- GitHub CLI를 사용하여 diff와 메타데이터를 가져옵니다:
gh pr view <pr>및gh pr diff <pr>. - 조사 PR의 경우,
docs/investigations/에서 예상 형식도 확인하세요. - 동작이 주변 코드에 의존하는 경우, diff 청크뿐만 아니라 변경된 파일을 전체적으로 읽으세요.
검토
diff를 파일별로 살펴보세요. Playbook의 "PR Reviews" 섹션을 적용하세요:
- Playbook 체크리스트 실행(수락 기준, 컴파일/테스트 실패, 호출자 업데이트, 테스트 커버리지, 조사에 대한 증거).
- 각 발견 사항을 blocking, nit, 또는 question으로 분류하세요(Playbook 기준).
- Playbook의 결정 흐름을 사용하여 각 관찰 사항에 댓글을 남길 가치가 있는지 결정하세요.
- 범위 규칙은 티켓 유형에 따라 다릅니다(후속 작업: 여기서 모든 것을 해결, 기능: 리팩터링 허용). 티켓에서 유형을 확인하세요.
- Playbook의 "확인하되 단정하지 말라"에 따라: 주장을 반복하기 전에 직접 확인하세요. CI를 위해
gh pr checks <pr>실행, 제거된 기호를 찾기 위해 repo에서 grep 실행. PR 설명은 작성자의 주장이지 증거가 아닙니다. - Playbook의 "기존 동작을 묵묵히 제거하지 말라"에 따라: 확인되지 않은 동작 회귀는 작성자가 설명에 표시했더라도 blocking 발견 사항입니다.
출력
Playbook의 "PR Reviews > 형식"을 따르세요. 검토 결과를 채팅에 직접 출력하고(파일이 아닙니다, 사용자가 요청하지 않는 한), 판결 한 줄 후에 발견 사항을 나열하세요. 산문 에세이, 대화 로그, 또는 "수집된 컨텍스트"/"초기 검토"와 같은 섹션이 아님에 유의하세요. 각 발견 사항은 정확히 다음과 같습니다: 위치+코드 참조 라인, 복사 가능한 펜스 블록 안의 댓글, 그리고 이유. 구체적으로, 발견 사항은 다음과 같습니다:
### Blocking
`internal/adapters/users/adapter.go:281`
```go
_, err := u.providersClient.Update(ctx, request)
```
댓글 (PR에 붙여넣기):
이것은 이러한 쓰기가 의존하는 최종 일관성 재시도를 제거합니다. Core->Users 지연은 NotFound로 표면화되며, 새로운 일시적 전용 정책은 이를 재시도하지 않으므로 쓰기가 즉시 실패합니다.
이유: AC #3은 애플리케이션 수준 오류를 재시도하는 경로가 없는지 확인하도록 요구합니다. 이 경로는 그랬고, diff는 기간이 사라졌는지 확인하지 않고 제거합니다.
````
발견 사항당 하나의 블록을 반복하고, `### Blocking` / `### Nits` / `### Questions` 아래에 그룹화하세요(빈 그룹은 생략). "댓글" 뒤의 펜스 블록만 사용자가 GitHub에 복사하는 내용입니다. 나머지는 탐색을 위한 것입니다. 모든 것이 괜찮다면, 판결 한 줄만 출력하세요.
## 게시(요청 시에만)
사용자가 채팅 초안 대신 댓글을 게시하기를 원한다면, 먼저 확인한 후 `gh pr review` / `gh pr comment`를 사용하세요. 기본값은 채팅에 초안 작성입니다.