critique

critique skill 개요

critique가 하는 일

critique skill은 여러 전문 심사자가 독립적으로 판단하고, 토론을 거쳐 합의에 이르는 방식의 리뷰 워크플로입니다. 한 번 훑어보는 식의 의견보다 더 깊은 판단이 필요한 code review나 변경 검토 작업에 맞게 설계되었습니다.

이런 분들에게 적합합니다

병합 전에 정확성, 품질, 놓친 이슈를 agent가 평가해 주길 원한다면 critique를 쓰세요. Code Review용 일반 프롬프트 대신 구조화된 critique skill이 필요한 리뷰어, 유지보수자, 빌더에게 잘 맞습니다.

중요한 이유

이 skill의 핵심 가치는 불확실한 상황에서도 일관성을 유지한다는 점입니다. 각 judge가 독립적으로 작업을 살피고, 자기 판단을 검증한 뒤, 서로 다른 의견을 조율합니다. 덕분에 피상적인 칭찬, 사각지대, 단선적인 피드백이 줄어듭니다.

가장 잘 맞는 경우

이 skill은 이미 작업물이 존재하고, 그 결과를 판단하는 것이 목적일 때 가장 강합니다. 구현, 리팩터링, 자동 수정이 필요하다면 critique는 맞지 않는 도구입니다.

critique skill 사용 방법

critique skill 설치하기

npx skills add NeoLabHQ/context-engineering-kit --skill critique로 설치합니다. repo 경로는 plugins/reflexion/skills/critique이므로, 이 skill은 독립적인 유틸리티가 아니라 해당 context-engineering kit 안에서 사용하도록 되어 있습니다.

명확한 검토 대상을 제시하기

critique의 사용 패턴은 구체적인 범위를 줄 때 가장 잘 작동합니다. 변경된 파일, commit 범위, PR 링크, 특정 우려 사항처럼 명확한 대상을 주세요. 기본 힌트는 file path, commit, context를 지원하며, 아무것도 주지 않으면 최근 변경 사항만 기준으로 삼습니다.

먼저 확인할 파일부터 읽기

가장 먼저 SKILL.md를 읽고, 그다음 repo 안의 관련 workflow나 metadata 파일을 확인하세요. 이 plugin에는 scripts/, references/, resources/, rules/ 보조 파일이 없으므로, 핵심 운영 지침은 skill 파일 자체에 들어 있습니다.

리뷰 의도를 분명히 하는 프롬프트 작성하기

더 나은 요청은 이런 식입니다: “src/auth.ts와 src/session.ts를 보안, regression 위험, 테스트 커버리지 관점에서 critique 해 주세요.” 반면 “이 코드 리뷰해 주세요”처럼 던지면 어떤 기준이 중요한지 judge가 추측해야 하므로, critique guide의 효용이 떨어집니다.

critique skill FAQ

critique는 code review에만 쓰나요?

아닙니다. 단순한 code review보다 범위가 넓어서, 완료된 작업, 설계 결정, 구현 품질도 판단할 수 있습니다. 다만 결과물이 patch가 아니라 review report여야 할 때 가장 적합합니다.

critique는 일반 프롬프트와 어떻게 다른가요?

일반 프롬프트는 보통 하나의 의견만 냅니다. critique skill은 구조화된 multi-agent 프로세스, 독립 검증, 합의 형성을 더하므로, 신뢰성과 서로 다른 해석의 충돌을 중요하게 볼 때 더 유리합니다.

critique는 초보자도 쉽게 쓸 수 있나요?

네, 범위만 구체적이면 그렇습니다. 초보자일수록 정확한 파일이나 변경 집합을 지정하고, 가장 중요한 기준을 함께 요청할 때 더 좋은 결과를 얻습니다. skill이 모든 것을 알아서 추론해 주길 기대하는 방식은 효과가 떨어집니다.

언제 critique를 쓰지 말아야 하나요?

수정 사항을 자동으로 적용해야 하거나, 작업이 너무 단순하거나, 리뷰 범위가 너무 모호해서 공정하게 평가하기 어려울 때는 쓰지 마세요. 이런 경우에는 직접 구현 프롬프트나 targeted lint/test workflow가 더 빠릅니다.

critique skill 개선 방법

더 강한 리뷰 기준을 제시하기

품질을 가장 크게 끌어올리는 방법은 critique가 무엇을 최적화해야 하는지 알려 주는 것입니다: 정확성, 보안, 성능, 유지보수성, API 호환성, 테스트 완성도 등입니다. 이것이 없으면 judge가 눈에 띄는 문제에만 지나치게 집중하고, 정작 중요한 위험을 놓칠 수 있습니다.

요청 전에 범위를 좁히기

검토 대상이 크다면 commit, module, feature slice로 나누세요. 입력 범위가 제한될 때 critique는 더 잘 작동합니다. 토론이 저장소 전체를 요약하는 데 쓰이지 않고, 실제 tradeoff에 집중할 수 있기 때문입니다.

judge가 확인할 수 있는 근거를 포함하기

관련 file path, 기대 동작, 제약 조건, 알려진 failure mode를 함께 주면 좋습니다. 그러면 critique skill이 의도를 추측하지 않고 주장 자체를 검증할 수 있습니다. Code Review용 critique에서는 특히 이 점이 중요합니다.

첫 보고서를 바탕으로 반복 개선하기

첫 번째 결과에서는 의견 차이를 드러내게 하고, 그다음에는 가장 위험한 발견이나 근거가 약한 영역만 다시 critique 해 보세요. 이런 반복 루프를 거치면 critique skill이 한 번 보고 끝내는 요약이 아니라, 더 날카로운 의사결정 도구가 됩니다.