receive-reviewlisted

리뷰 피드백을 받았을 때 "네 맞습니다" 식의 performative agreement도, "그건 그냥 취향이죠" 식의 defensive rejection도 막는다. 각 항목을 **증거 기반으로 검증** 후 명시적 의사결정을 내린다. 받는 쪽도 주는 쪽만큼 기술적 엄밀성이 필요하다. ## 사용 시점 - GitHub PR 리뷰 코멘트 받은 직후 - `/feedback`, `/security`, `/design-audit`, `/review-pr` 출력 받은 직후 - 토론 verdict (`.claude/messages/debates/`) 도착 직후 - 동료가 구두/메시지로 피드백 줬을 때 (사용자가 정리해서 입력) ## 호출 형태 ```bash /receive-review # 사용자가 피드백 텍스트를 인라인 입력 /receive-review pr <N> # GitHub PR #N의 리뷰 코멘트 자동 가져오기 (gh CLI) /receive-review file <path> # 파일에서 피드백 로드 (예: /feedback 출력) /receive-review debate <debate-id> # 토론 verdict 항목별 처리 ``` ## 절차 ### 1. 피드백 수집 ```bash # PR 모드 gh pr view <N> --json reviews,comments --jq '...' # debate 모드 cat .claude/messages/debates/debate-<id>.json | jq '.action_items' # file 모드 cat <path> ``` ### 2. 항목 분리 리뷰가 한 덩어리로 와도 **개별 의견 단위로 분리**한다. 보통 한 코멘트당 1~3개 항목. ``` 원문: "이 함수 너무 길고, error handling도 빠졌어요. 그리고 변수명 `data`는 너무 모호한 것 같습니다." → 분리: Item 1: 함수 길이 (architecture) Item 2: error handling 누락 (bug/correctness) Item 3: 변수명 'data' (style/preference) ``` ### 3. 카테고리 분류 (6 카테고리) | 카테고리 | 정의 | 검증 방법 | |---------|------|----------| | **Bug/Correctness** | 코드가 틀렸거나 실패할 가능성 | 재현 시도 + 실패 테스트 작성 | | **Security** | 취약점, 데이터 누출 위험 | `security` 에이전트 또는 OWASP 매핑 | | **Performance** | 측정 가능한 성능 저하 | 벤치마크 또는 메트릭 | | **Architecture** | 설계 패턴, 모듈 경계 | `planner`/`feedback` 에이전트 의견 | | **Style/Convention** | 코드 스타일, 네이밍 | `rules/` 디렉토리 매핑 | | **Preference*