apply-review

name	apply-review
description	현재 작업 중인 PR에 달린 코드 리뷰를 확인하고, 타당한 리뷰는 코드를 고쳐 반영(커밋·푸시·PR 갱신)하고, 부당한 리뷰는 이유를 설명하며 무시합니다. PR 리뷰 코멘트를 반영하거나, 리뷰 피드백에 대응하거나, "리뷰 반영", "리뷰 적용", "코드리뷰 처리"를 요청할 때 반드시 이 스킬을 사용하세요.

코드 리뷰 반영 (apply-review)

현재 작업의 PR에 달린 코드 리뷰를 가져와 하나씩 평가하고, 타당하면 코드에 반영하고 부당하면 무시합니다. 모든 판단은 대화창에 설명하고 PR 코멘트로도 남깁니다 (적용한 것·무시한 것 모두).

핵심 원칙

• 모든 설명은 개발자가 아니어도 이해할 수 있게, 짧고 쉽게. 전문 용어 대신 "무엇을 왜 바꿨는지/안 바꿨는지"를 한두 문장으로.
• 언어 규칙: 사용자 대화창 설명은 한국어, PR 코멘트·커밋 메시지·PR 본문은 영어 (.claude/rules/git-workflow.md).
• 리뷰를 맹목적으로 따르지 않습니다. 각 리뷰가 정말 맞는지, 우리 코드 맥락에서 타당한지 직접 판단합니다. 틀리거나 불필요하면 정중히 무시하고 이유를 댑니다.
• 되돌리기 어려운 작업(커밋·푸시·PR 갱신) 전에는 반드시 /qa-pr을 통과해야 합니다.

0단계: PR 컨텍스트 확정

먼저 지금 어떤 PR을 다루는지 정합니다.

git branch --show-current
gh pr view --json number,title,url

다음 두 경우에는 작업을 멈추고 사용자에게 PR 링크를 요청하세요. 추측해서 진행하지 않습니다.

• 현재 브랜치가 master인 경우 (master에서는 직접 작업하지 않습니다 — .claude/rules/git-workflow.md)
• gh pr view가 실패하는 등 현재 컨텍스트로 PR을 알 수 없는 경우

요청 예시: "현재 브랜치가 master라(또는 연결된 PR을 찾지 못해) 어떤 PR의 리뷰를 반영할지 알 수 없어요. PR 링크를 알려주세요."

링크를 받으면 거기서 {owner}/{repo}와 PR 번호를 파싱하고, 해당 PR 브랜치로 이동해 작업합니다:

gh pr checkout {number} --repo {owner}/{repo}

체크아웃 후 다시 git branch --show-current로 master가 아님을 확인합니다. 리모트: origin=내 포크(jihea-park/pinpoint), upstream=pinpoint-apm/pinpoint.

1단계: 리뷰 수집

확정된 PR의 리뷰 전부(요약 리뷰 + 인라인 코멘트, Copilot·사람 모두)를 가져옵니다.

# PR 번호와 저장소가 아직 없으면 다시 확인
gh pr view --json number,title,url

# 리뷰 요약(승인/변경요청/총평) — 리뷰어와 본문
gh api repos/{owner}/{repo}/pulls/{number}/reviews \
  --jq '.[] | {id, user: .user.login, state, body}'

# 인라인 코드 코멘트 — 파일·라인·내용·comment id (반영 대상의 핵심)
gh api repos/{owner}/{repo}/pulls/{number}/comments \
  --jq '.[] | {id, user: .user.login, path, line, body}'

{owner}/{repo}는 PR이 올라간 저장소(보통 pinpoint-apm/pinpoint). 위 gh pr view의 url(예: https://github.com/pinpoint-apm/pinpoint/pull/13913)에서 파싱해 채웁니다. 이미 답글이 달려 처리된 코멘트는 중복 대응하지 않도록 in_reply_to_id가 없는(최상위) 코멘트 위주로 봅니다.

2단계: 각 리뷰를 하나씩 평가

리뷰 코멘트마다 다음을 따집니다. 추측하지 말고 실제 코드를 열어 확인하세요.

1. 무엇을 지적하는가 — 코멘트가 가리키는 파일·라인을 직접 읽습니다.
2. 타당한가 — 우리 코드 맥락에서 실제 문제인지, 프로젝트 규약(.claude/rules/)에 비춰 맞는지 판단합니다.
3. 부수효과는 없는가 — 고쳤을 때 다른 동작이 깨지지 않는지 봅니다.

판단은 두 갈래입니다:

• 타당함 → 반영 (3단계로)
• 부당하거나 불필요함 → 무시: 왜 적용하지 않는지 쉬운 말로 설명합니다. 예) 리뷰가 가정한 상황이 실제로는 생기지 않음 / 이미 다른 곳에서 처리됨 / 이슈 범위 밖 / 제안대로면 오히려 기존 동작이 깨짐.

부당해 보여도 단정하기 전에 한 번 더 코드로 확인하세요. 반대로 "리뷰어가 그렇게 말했으니까"는 적용의 이유가 될 수 없습니다.

3단계: 타당한 리뷰 반영 — 영향 분석 후 수정

코드를 고치기 전에 .claude/rules/code-review-policy.md의 회귀 방지 절차를 따릅니다:

• 고칠 파일의 모든 호출자·소비자를 먼저 파악합니다 (타입/훅/아톰/props/엔드포인트 변경 시 사용처 전부 Grep).
• 수정이 이번 PR이 해결하려던 이슈와 충돌하지 않는지 확인합니다. (PR 제목·본문·연결 이슈의 의도를 다시 읽기)
• 수정 후, 영향받은 파일을 다시 읽어 기존 시그니처·반환 타입·props·import 경로가 깨지지 않았는지 검증합니다.

여러 리뷰를 반영할 경우 관련 수정을 모아 하나의 커밋으로 묶습니다(성격이 전혀 다르면 분리 가능).

4단계: 리베이스로 최종 코드 만든 뒤 /qa-pr 필수 (게이트)

QA는 커밋·푸시될 최종 코드에 대해 해야 의미가 있습니다. 리베이스로 충돌을 해결하면 코드가 바뀌므로, 리베이스를 먼저 끝내고 그 결과에 /qa-pr을 실행합니다. (QA 뒤에 리베이스를 하면 변경된 코드가 검증되지 않은 채 커밋될 수 있습니다.)

# 1) 먼저 upstream 최신화 리베이스 — 충돌이 있으면 해결까지 완료 (git-workflow.md)
git fetch upstream master
git rebase upstream/master

# 2) 그 다음 /qa-pr 실행 — 빌드(yarn build)·테스트(yarn test)·동작 QA·회귀 점검

판정이 FAIL이면 절대 커밋하지 말고 문제를 먼저 해결합니다. (.claude/rules/git-workflow.md의 QA 게이트) /qa-pr 통과 후 셀프 체크: 디버그 코드(console.log 등) 없음, 코드 스타일 준수, 기존 기능 정상.

5단계: 커밋 · 푸시 · PR 갱신

리베이스와 QA가 모두 끝나고 PASS일 때만 진행합니다.

git add <변경 파일>
git commit -m "[#issue_number] Description"   # 영어로. 같은 플랫폼이면 #issue_number, 다른 플랫폼이면 #noissue (git-workflow.md)
git push origin <branch-name>                 # 기존 PR 갱신이므로 -u 불필요 (이미 origin 추적 중)

커밋·PR 메시지는 항상 영어. 기존 PR이 같은 브랜치를 추적하므로 push만으로 PR이 갱신됩니다.

6단계: 판단을 PR 코멘트로 남기기 (적용·무시 모두)

각 리뷰 코멘트에 답글로 결론을 남깁니다. 답글 본문은 영어로, 짧고 명확하게.

# 특정 인라인 리뷰 코멘트에 답글 (본문은 영어로 — 플레이스홀더도 영어)
gh api repos/{owner}/{repo}/pulls/{number}/comments/{comment_id}/replies \
  --method POST -f body="Applied. <one-line reason in English>"
# 또는 무시한 경우
gh api repos/{owner}/{repo}/pulls/{number}/comments/{comment_id}/replies \
  --method POST -f body="Not applied. <one-line reason in English>"

요약 리뷰(인라인이 아닌 총평)에 대응할 때는 PR 본문 코멘트를 사용:

gh pr comment {number} --body "<summary of applied/ignored items in English>"

7단계: 대화창 보고

마지막으로 사용자에게 쉬운 말로 정리해 보여줍니다:

1. 적용한 리뷰: 무엇을, 왜 타당해서, 어떻게 고쳤는지 (각 한두 문장)
2. 무시한 리뷰: 무엇을, 왜 적용하지 않았는지 (각 한두 문장)
3. QA 결과: PASS / FAIL
4. 반영 결과: 커밋 해시, 푸시·PR 갱신 여부, 남긴 PR 코멘트

적용/무시 어느 쪽이든 "왜"가 가장 중요합니다. 비개발자도 납득할 수 있게 설명하세요.