메뉴
코드 리뷰 피드백, PR 코멘트, 인라인 제안, 또는 작성한 코드에 대한 비평을 받아 응답이나 조치가 필요할 때 사용. Use when receiving code review feedback, PR comments, inline suggestions, or any critique of written code that requires a response or action.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
아이디어를 설계로 전환하거나, 새로운 기능을 만들거나, 구현 전 구조화된 설계가 필요한 창의적/탐색적 작업에 사용. Use when turning an idea into a design, creating a new feature, or when any creative/exploratory work needs structured design before implementation.
태스크나 unit 구현이 완료되어 머지 전 코드 리뷰가 필요할 때, 또는 사용자가 명시적으로 코드 리뷰를 요청할 때 사용. Use when a task or unit implementation is complete and needs code review before merging, or when the user explicitly requests a code review on their changes.
설계 문서를 상세 구현 계획으로 변환하거나, "구현 계획 작성", "plan 만들어줘" 요청 시 사용. INCEPTION 워크플로우 계획은 aidlc-workflow-planning 사용. Use when a design document needs to be converted into a detailed implementation plan with task breakdown, or when "구현 계획 작성", "plan 만들어줘" is requested. Not for INCEPTION workflow planning — use aidlc-workflow-planning instead.
Use when user explicitly requests "auto 모드", "자동 모드", "auto mode", or "알아서 만들어줘". 초보자를 위한 완전 자동 devflow. greenfield 전용. 요구사항 입력 → inception → construction → build-test를 자동 진행하며 각 flow 종료 시 멀티에이전트 리뷰 필수.
현재 세션에서 구현 계획을 실행할 때 사용. 독립 태스크별 신규 서브에이전트 컨텍스트 활용. Use when executing an implementation plan in the current session with independent tasks that benefit from fresh subagent context per task.
프로덕션 코드 작성, 버그 수정, 리팩토링 시 사용 — 예외 없이 RED-GREEN-REFACTOR 사이클을 강제. Use when writing any production code, fixing bugs, or refactoring — enforces RED-GREEN-REFACTOR cycle with no exceptions.
| name | aidlc-receiving-code-review |
| description | 코드 리뷰 피드백, PR 코멘트, 인라인 제안, 또는 작성한 코드에 대한 비평을 받아 응답이나 조치가 필요할 때 사용. Use when receiving code review feedback, PR comments, inline suggestions, or any critique of written code that requires a response or action. |
| metadata | {"version":"0.1.0","author":"Jay","category":"ai-dlc-workflow","invoke_mode":"user-invocable","return_behavior":"stop-no-gate","skill_nature":"hybrid","lifecycle":"active","model_dependency":"모델이 피드백에 sycophancy로 맹목적 동의함","amplification_notes":"Accept/Rebut 프로토콜 + 금지 응답 목록"} |
다음 상황에서 이 스킬을 실행한다:
리뷰 피드백을 감정 없이 기술적으로 평가하고, 수락할 것은 수락하고, 반박할 것은 근거로 반박한다. 맹목적 동의와 방어적 거부 둘 다 피한다.
다음 표현은 절대 사용하지 않는다. 아첨성 응답은 실제 기술 판단을 흐린다:
| 금지 표현 | 이유 |
|---|---|
| "You're absolutely right!" | 기술적 검토 없는 즉각 동의 |
| "Great point!" | 피드백의 유효성을 미리 확정 |
| "Thanks for catching that!" | 실제로 버그인지 확인 전 인정 |
| "I should have thought of that!" | 자기 비하 — 판단을 흐림 |
| "That's a much better approach!" | 실제로 더 나은지 검증 없이 동의 |
| "Of course, my mistake!" | 본인 코드가 틀렸다고 검증 전에 인정 |
올바른 응답 형식:
DO NOT proceed to 2단계 until all feedback is read and listed. 부분만 읽고 반응하지 않는다.
모든 피드백을 한 번에 읽는다. 아직 동의하거나 반박하지 않는다.
각 이슈에 대해 다음을 파악한다:
이슈 목록 작성:
| # | 이슈 위치 | 표면 제안 | 실제 우려 |
|---|---------|---------|---------|
| 1 | api.py:42 | ... | ... |
| 2 | models.py:15 | ... | ... |
DO NOT proceed to 4단계 until each claim is verified against actual code. 확인 없이 동의/거부하지 않는다.
리뷰어의 주장을 코드에서 직접 확인한다:
# 해당 파일 읽기
# 제안된 변경이 실제로 개선인지 확인
# 현재 코드가 정말 문제가 있는지 확인
# 리뷰어가 다른 부분을 오해한 건 아닌지 확인
확인 없이 "맞아요" 또는 "틀려요"를 말하지 않는다.
각 이슈를 다음 기준으로 평가한다:
YAGNI (You Aren't Gonna Need It) 검증:
현재 코드베이스 맥락 검증:
외부 리뷰어 피드백 처리 (코드베이스를 잘 모르는 리뷰어):
DO NOT respond until 4단계 evaluation is complete for all issues. 평가 없는 응답은 아첨이거나 방어적 거부다.
각 이슈에 대해 세 가지 중 하나로 응답한다:
수락 (Accept):
[이슈 #1] 수락
확인 결과: [구체적 관찰 내용]
이유: [왜 이 변경이 개선인가]
거부 (Reject):
[이슈 #2] 거부
현재 코드 동작: [실제 코드 동작 설명]
거부 이유: [YAGNI / 기존 컨벤션 / 불필요한 복잡성]
대안 (필요시): [대안 제안]
토론 필요 (Discuss):
[이슈 #3] 토론 필요
이해한 우려: [리뷰어의 실제 우려]
내 관점: [내 기술적 판단]
추가 확인 필요: [어떤 정보가 더 필요한가]
수락된 항목만 구현한다. 하나씩 처리한다:
aidlc-verification-before-completion 적용)여러 항목을 한꺼번에 수정하지 않는다 — 무엇이 무엇을 깨뜨렸는지 알 수 없게 된다.
| 분류 | 정의 | 처리 방법 |
|---|---|---|
| Critical | 보안 취약점, 데이터 손실 위험, 명백한 버그 | 즉시 수정 — 다음 단계 진행 전에 처리 |
| Important | 성능 문제, 설계 결함, 테스트 부족 | 진행 전 수정 — 이번 PR에서 처리 |
| Minor | 스타일, 변수명, 주석 | 나중에 처리 가능 — 별도 이슈 생성 |
분류 기준:
리뷰 코멘트:
api.py:67: 이 함수는 예외를 잡지만 로깅을 안 하네요.
프로덕션에서 오류를 추적하기 어려울 것 같아요.
처리:
1단계-3단계: api.py:67 확인
try:
result = process_payment(data)
except PaymentError:
return {"error": "Payment failed"} # 로깅 없음 — 리뷰어 맞음
4단계 평가: Critical에 해당 — 프로덕션 디버깅 불가
5단계 응답:
[이슈 #1] 수락
확인 결과: api.py:67에서 예외를 catch하지만 logger.error() 호출이 없습니다
이유: 프로덕션 장애 추적을 위해 로깅이 필요합니다
분류: Critical — 즉시 수정
6단계 구현:
except PaymentError as e:
logger.error("결제 처리 실패: %s", str(e), exc_info=True)
return {"error": "Payment failed"}
리뷰 코멘트:
UserRepository 클래스는 인터페이스로 분리해야 합니다.
IUserRepository와 UserRepositoryImpl로 나누세요.
처리:
1단계-3단계: 프로젝트 확인
4단계 평가: YAGNI — 현재 구현체가 1개뿐이고 추가 구현체 계획 없음
5단계 응답:
[이슈 #1] 거부
현재 코드 동작: UserRepository 구현체가 1개이며, 테스트는 pytest fixtures로 처리합니다
거부 이유: YAGNI — 현재 요구사항에서 다형성이 필요 없습니다.
인터페이스 분리는 구현체가 2개 이상 필요할 때 도입할 예정입니다.
기존 컨벤션: 프로젝트의 다른 Repository 클래스들도 동일 패턴을 사용합니다
증상: 거부 응답을 했는데 리뷰어가 다시 같은 이슈를 제기함
처리 방법:
증상: 피드백이 일반적으로는 맞지만 이 프로젝트에 맞지 않는 경우
처리 방법:
"일반적으로는 좋은 접근이지만, 이 프로젝트에서는 [맥락] 때문에
[현재 방식]을 사용하고 있습니다. [근거]"