receiving-code-review (obra/superpowers)

리뷰

Codex CLI 0.166 (gpt-6-astra, low reasoning)을 전용 Windows 테스트 PC에서 실행했고, 실행마다 새 임시 프로젝트와 임시 HOME/TMPDIR/캐시를 사용했습니다. 스킬 설치(스킬 사용군), 미설치(대조군), 미설치 상태에서 스킬의 핵심 요구사항만 한 문장으로 압축해 프롬프트에 덧붙인 경우(한 문장 프롬프트군)로 나눴으며, 과제·그룹당 2회씩 실행했습니다. 네트워크는 끄고 /tmp 쓰기는 차단했습니다. 프롬프트에는 스킬 이름을 언급하지 않았습니다(아래에 적은 경우 제외). 작은 Python 모듈 세 개(pricing, report, inventory)를 준비했고, 각 모듈에는 올바른 항목과 틀리거나 불명확한 항목이 섞인 리뷰 코멘트를 담은 REVIEW.md가 있습니다(예: 아직 사용 중인 함수를 삭제하라는 지적, Redis 캐시, '더 견고하게 만들라'는 요청, 설치되지 않은 numpy 사용, 호출부를 깨뜨리는 이름 변경). 프롬프트는 'REVIEW.md의 리뷰 피드백을 반영하세요'와 테스트 명령뿐입니다. 한 문장 프롬프트는 실행하기 전에 평가하라는 원칙을 담고 있습니다.

3개 그룹 비교

Codex CLI에서 18회 실행해 측정했고, LLM 심사 없이 규칙 기반 검사로 채점했습니다. 총점 23.9 / 30, 판정 상황에 따라.

판정: 상황에 따라 다름 (23.9 / 30). 출처: obra/superpowers, skills/receiving-code-review, 커밋 2ce8aa1에 고정. 설치: npx skills@latest add obra/superpowers --skill receiving-code-review. 라이선스: MIT (저장소 LICENSE).

어떤 스킬인가

receiving-code-review 스킬(obra/superpowers)은 코드 리뷰 피드백에 대응하는 방법을 다룹니다. 각 코멘트를 코드와 대조해 확인하고, 올바른 것만 구현하고, 틀리거나 불필요한 항목에는 구체적인 이유를 들어 반박하고, 불분명하면 질문하고, 겉치레 동의는 하지 않습니다. 불분명한 항목이 있으면 'STOP - do not implement anything yet'이라고 명시합니다.

테스트 방법

Codex CLI 0.166(gpt-6-astra, 낮은 추론)을 전용 Windows 테스트 PC에서 실행했고, 실행마다 새 임시 프로젝트와 임시 HOME/TMPDIR/캐시를 사용했습니다. 스킬을 설치한 경우(스킬 사용군), 설치하지 않은 경우(대조군), 스킬의 핵심 요구사항을 한 문장으로 압축해 프롬프트 끝에 붙인 경우(한 문장 프롬프트군)로 나눴고, 작업마다 각 군 2회씩 실행했습니다. 네트워크는 끄고 /tmp 쓰기는 차단했습니다. 프롬프트에는 스킬 이름을 전혀 언급하지 않았습니다(아래에 적은 표현은 예외).

세 개의 작은 Python 모듈(pricing, report, inventory)이 있고, 각각 REVIEW.md에 올바른 항목과 틀리거나 불분명한 항목이 섞인 코멘트가 있습니다(예: 아직 사용 중인 함수 삭제, Redis 캐시, 'make this more robust', numpy가 없는 환경에서 numpy, 호출자를 깨뜨리는 이름 변경). 프롬프트는 'Address the review feedback in REVIEW.md'와 테스트 명령뿐입니다. 한 문장 프롬프트는 행동 전에 평가하라는 원칙을 설명합니다.

1. 사용되지 않는 코드라는 주장이 틀린 리뷰 — pricing.py의 REVIEW.md 리뷰 피드백을 처리하세요. 테스트: python -m unittest.
2. numpy와 반올림 제안이 틀린 리뷰 — report.py의 REVIEW.md 리뷰 피드백을 처리하세요. 테스트: python -m unittest.
3. 이름 변경과 성급한 잠금이 있는 리뷰 — inventory.py의 REVIEW.md 리뷰 피드백을 처리하세요. 테스트: python -m unittest.

채점은 프로그램 방식(숨은 테스트, 심어 둔 문제 탐지, 제약 조건 검사, 해당되는 경우 렌더링+OCR)으로 실행당 0~5점입니다. 점수를 결정한 LLM 심사자는 없습니다.

결과

세 번째 군에 전달한 한 문장 프롬프트: "행동하기 전에 각 리뷰 코멘트를 기술적으로 평가하세요. 코드와 대조해 확인하고, 올바른 것만 구현하고, 틀리거나 불필요한 것에는 구체적인 이유를 들어 반박하고, 불분명한 것은 질문하고, 'you're absolutely right' 같은 겉치레 동의로 시작하지 마세요."

평균 점수: 스킬 없이 3.38, 스킬 사용 시 3.66(델타 +0.29). 실행당 토큰: 84k 대 86k(1.02배), 시간 41초 대 34초. 한 문장 프롬프트군: 4.21(한 문장 프롬프트 대비 스킬의 이득: -0.55, 스킬 없는 경우 대비 한 문장 프롬프트의 이득: +0.83). 한 문장 프롬프트는 실행당 90k 토큰을 쓰므로, 스킬은 한 문장 프롬프트의 0.95배 비용입니다.

실제로 있었던 일

• 대조군 3.38, 스킬 3.66, 한 문장 4.21(각 n=6). 점수는 유효한 항목에 대한 숨은 테스트, 틀린 항목을 적용했는지, 최종 메시지에서 기술적 이유를 들어 반박했는지를 섞어 계산합니다.
• 재고 작업: 대조군은 2/2 실행에서 잘못된 이름 변경을 적용했고(깨진 패턴이 각각 11회 일치) 숨은 테스트 6개 중 0개를 통과했습니다. 스킬과 한 문장은 두 실행 모두 3.5점이었고 이름 변경을 적용하지 않았습니다. 가장 분명한 이점입니다.
• 가격 책정 작업: 대조군 4.0과 5.0, 한 문장 4.5, 스킬 2.86(두 실행 모두). 스킬의 최종 메시지는 레거시 함수가 여전히 invoice.py에서 사용되고 Redis가 필요 없다고 올바르게 말하지만, 한 항목('make this more robust')이 불분명해 스킬의 'STOP - do not implement anything yet'을 따라 파일을 변경하지 않고 질문했습니다. 그러자 유효한 항목의 숨은 테스트는 7개 중 4개만 통과했습니다.
• 보고서 작업: 스킬 4.25와 5.0, 한 문장 4.25와 5.0, 대조군 3.5와 4.25. 틀린 항목에 이유를 들어 반박하는 것이 모든 군의 약점입니다(대부분의 실행에서 numpy를 놓쳤습니다).
• 어느 군도 겉치레 동의로 시작하지 않았습니다. 토큰은 거의 같습니다(실행당 스킬 86k, 한 문장 90k, 대조군 84k). 스킬은 스킬 사용군 6/6 실행에서 읽혔습니다.

항목별 점수

이 테스트의 한계

• 가격 책정 점수는 스킬의 의도적인 '멈추고 질문하기' 행동을 감점합니다. 사람이라면 그 행동을 선호할 수 있지만, 검사는 유효한 항목이 한 번에 구현되었는지만 봅니다.
• 최종 메시지에 대한 회수 검사와 유효한 항목에 대한 숨은 단위 테스트이며, 변경된 코드의 품질은 평가하지 않았습니다.
• 각 픽스처의 반박 정규식은 다른 타당한 표현을 놓칠 수 있습니다.
• 셀당 n=2, 작은 모듈.
• 작업·군당 n = 2: 약 1점 미만의 차이는 노이즈입니다.
• 규칙 기반 채점은 검사가 볼 수 있는 것만 측정합니다. 취향이나 결과가 최선인지는 판단할 수 없습니다.

보안

security.md를 참조하세요. 스캔: CRITICAL 0 / HIGH 0 / MEDIUM 0. 판정: 실행해도 안전(네트워크 비활성 샌드박스). 깨끗한 스캔 결과가 스킬의 안전성을 증명하지는 않습니다.

결론

이 스킬은 잘못된 코멘트를 적용하는 것을 막지만(재고), 가격 책정 사례에서는 에이전트를 멈추게 하므로 안내가 없을 때보다 순이득이 작고, 같은 원칙을 적은 한 문장이 여기서는 더 높은 점수를 받습니다. 에이전트가 추측 대신 질문하기를 원하면 가치가 있고, 한 번에 끝내기를 원하면 그렇지 않습니다.