القائمة
현재 작업 중인 PR에 달린 코드 리뷰를 확인하고, 타당한 리뷰는 코드를 고쳐 반영(커밋·푸시·PR 갱신)하고, 부당한 리뷰는 이유를 설명하며 무시합니다. PR 리뷰 코멘트를 반영하거나, 리뷰 피드백에 대응하거나, "리뷰 반영", "리뷰 적용", "코드리뷰 처리"를 요청할 때 반드시 이 스킬을 사용하세요.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
영어와 한국어 로케일 파일 모두에 i18n 번역 키를 추가합니다. 사용자 노출 문자열을 추가하거나, 번역 키가 누락되었거나, 새 UI 텍스트를 국제화할 때 반드시 이 스킬을 사용하세요.
useGetXxx 패턴에 따라 새 React Query API 훅을 생성합니다. 새 백엔드 API를 연동하거나, 엔드포인트에 대한 훅이 필요하거나, 데이터 페칭 로직을 추가할 때 반드시 이 스킬을 사용하세요.
프로젝트의 shadcn/ui + Tailwind 패턴에 따라 새 React 컴포넌트를 생성합니다. UI 프리미티브(버튼, 다이얼로그 등) 또는 도메인 컴포넌트(ServerMap, Inspector 등)를 새로 만들 때 반드시 이 스킬을 사용하세요.
Pinpoint 프로젝트 패턴에 따라 새 페이지를 생성합니다. 애플리케이션에 새 라우트/페이지를 추가하거나, 새 화면을 만들거나, 기존 라우팅 구조에 페이지를 추가할 때 반드시 이 스킬을 사용하세요.
web-frontend, web, web-starter Maven 모듈을 skipTests 옵션으로 순차 빌드합니다.
Pinpoint 프론트엔드 PR 전 QA 게이트. 빌드/테스트를 실행하고 변경된 코드에 대한 동작 QA를 수행합니다. 커밋하거나 PR을 올리기 전에 반드시 이 스킬을 먼저 실행하세요.
| name | apply-review |
| description | 현재 작업 중인 PR에 달린 코드 리뷰를 확인하고, 타당한 리뷰는 코드를 고쳐 반영(커밋·푸시·PR 갱신)하고, 부당한 리뷰는 이유를 설명하며 무시합니다. PR 리뷰 코멘트를 반영하거나, 리뷰 피드백에 대응하거나, "리뷰 반영", "리뷰 적용", "코드리뷰 처리"를 요청할 때 반드시 이 스킬을 사용하세요. |
현재 작업의 PR에 달린 코드 리뷰를 가져와 하나씩 평가하고, 타당하면 코드에 반영하고 부당하면 무시합니다. 모든 판단은 대화창에 설명하고 PR 코멘트로도 남깁니다 (적용한 것·무시한 것 모두).
.claude/rules/git-workflow.md)./qa-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.
확정된 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가 없는(최상위) 코멘트 위주로 봅니다.
리뷰 코멘트마다 다음을 따집니다. 추측하지 말고 실제 코드를 열어 확인하세요.
.claude/rules/)에 비춰 맞는지 판단합니다.판단은 두 갈래입니다:
부당해 보여도 단정하기 전에 한 번 더 코드로 확인하세요. 반대로 "리뷰어가 그렇게 말했으니까"는 적용의 이유가 될 수 없습니다.
코드를 고치기 전에 .claude/rules/code-review-policy.md의 회귀 방지 절차를 따릅니다:
여러 리뷰를 반영할 경우 관련 수정을 모아 하나의 커밋으로 묶습니다(성격이 전혀 다르면 분리 가능).
/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 등) 없음, 코드 스타일 준수, 기존 기능 정상.
리베이스와 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이 갱신됩니다.
각 리뷰 코멘트에 답글로 결론을 남깁니다. 답글 본문은 영어로, 짧고 명확하게.
# 특정 인라인 리뷰 코멘트에 답글 (본문은 영어로 — 플레이스홀더도 영어)
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>"
마지막으로 사용자에게 쉬운 말로 정리해 보여줍니다:
적용/무시 어느 쪽이든 "왜"가 가장 중요합니다. 비개발자도 납득할 수 있게 설명하세요.