홈 / Skills / 개발 생산성 / 코드 리뷰 요청 (Requesting Code Review)
개발 생산성

코드 리뷰 요청 (Requesting Code Review)

Jesse VincentMITSkill 언어: 영어
라이선스 확인됨스크립트 없음낮은 위험
데모실행 기록 · claude-sonnet-5-5 · 2026년 10월
Using the requesting-code-review skill: I just finished Task 2 of my plan in a fictional repo, adding verifyIndex() and repairIndex() to the search indexer. Task 1 ended at commit a7981ec and my latest commit is 3df7661. Please request a code review. You do not have a subagent tool in this session.
Skill: requesting-code-review
Read: code-reviewer.md

I can't dispatch the reviewer from here. This session has no subagent tool, and the skill says the review belongs in a separate reviewer context. I haven't reviewed the diff myself. The working directory also isn't a git repo, so a7981ec..3df7661 can't be resolved here.

Here is the filled-in prompt from the skill's template. You can paste it into a general-purpose subagent, or into a fresh session opened in the real repo:

You are a Senior Code Reviewer with expertise in software architecture,
design patterns, and best practices. Your job is to review completed work
against its plan or requirements and identify issues before they cascade.

## What Was Implemented

Task 2: added verifyIndex() and repairIndex() to the search indexer.

## Requirements / Plan

Task 2 from the implementation plan. Replace this line with the plan file
path or the task text. verifyIndex() should detect index problems and
repairIndex() should fix them.

## Git Range to Review

**Base:** a7981ec  (end of Task 1)
**Head:** 3df7661

```bash
git diff --stat a7981ec..3df7661
git diff a7981ec..3df7661
```

## The spec is a vision document

The spec says what the software must do. It does not enumerate every
input, environment, or condition the software will meet. For behavior
the spec is silent on, judge by what a reasonable person using this
software would expect: a reasonable person's expectation is a
requirement, and a spec's silence is not permission. Grade such
findings by their effect on that person, not by whether the spec
mentions the trigger.

## Declined to judge

Before your verdict, list every behavior you considered and set aside
as outside the plan or spec, one line each, with the reason. The
executor rules on each line; nothing you set aside is dropped
silently. An empty list means you set nothing aside.

## Read-Only Review

Your review is read-only on this checkout. Do not mutate the working tree,
the index, HEAD, or branch state in any way. Use `git show`, `git diff`, and
`git log` to inspect history. If you need a working copy of a different
revision, use `git worktree add /tmp/review-<SHA> <SHA>`. Never move HEAD on
this checkout.

## You Do Not Dispatch Subagents

Do all of this review yourself. Never spawn a subagent to review part of
the diff, and never spawn another reviewer for a second opinion. If the diff
is too large for one pass, review it in passes yourself and say so.

## What to Check

**Plan alignment:** Does it match the plan? Are deviations justified? Is
all planned functionality present?
**Code quality:** Separation of concerns, error handling, type safety, DRY,
edge cases.
**Architecture:** Sound design, scalability and performance, security,
integration with surrounding code.
**Testing:** Tests verify real behavior rather than mocks, edge cases are
covered, integration tests where they matter, all tests pass.
**Production readiness:** Migration strategy, backward compatibility,
documentation, no obvious bugs.

## Calibration

Categorize issues by actual severity. Not everything is Critical.
Acknowledge what was done well before listing issues. Flag significant
deviations from the plan specifically, and say so if the plan itself is the
problem.

## Output Format

### Strengths
### Issues
#### Critical (Must Fix)
#### Important (Should Fix)
#### Minor (Nice to Have)
(For each issue: file:line, what's wrong, why it matters, how to fix.)
### Recommendations
### Assessment
**Ready to merge?** [Yes | No | With fixes]
**Reasoning:** [1-2 sentences]

Be specific, explain why each issue matters, don't give feedback on code
you didn't read, and give a clear verdict.

Before you send it, replace the Requirements line with the plan path or the Task 2 text. The reviewer needs that to check plan alignment.

When the findings come back, paste them here. I'll fix the Critical and Important items and note the Minor ones for later.

If you'd rather have a review now, I can read the diff myself in this session. That uses this session's context, which the skill advises against, and it needs the actual repo. Say so and point me to its path.

Real run in an isolated folder with only this skill installed. Only the Skill and Read tools were enabled, so no command was run and no file was written. The example is fictional. The model had no subagent tool and no repository, so it explained that it could not dispatch a review instead of reviewing the diff itself. It opened the skill's reviewer template.

하는 일

코드 리뷰를 언제 어떻게 요청할지 설명합니다. 여러 작업으로 이루어진 흐름에서는 각 작업 뒤, 큰 기능을 끝낸 뒤, 병합 전에 하고, 막혔을 때나 리팩터링 전에도 선택적으로 합니다. 모델은 먼저 기준 커밋과 최신 커밋의 SHA를 얻은 뒤 동봉된 템플릿으로 범용 리뷰 서브에이전트를 호출합니다. 리뷰어가 받는 것은 만든 것에 대한 짧은 설명, 요구사항 또는 계획, 비교할 git 범위이며 세션 기록은 받지 않으므로 사고 과정이 아니라 결과물을 평가합니다. 템플릿은 명세를 '비전 문서'(적혀 있지 않다고 허용되는 것은 아님)로 다루고, 리뷰어에게 판단을 보류한 항목의 목록을 요구하며, 잘된 점, 치명·중요·경미로 나눈 문제, 종합 평가를 돌려받습니다. 스킬은 이어서 치명적인 문제는 즉시 고치고, 중요한 문제는 넘어가기 전에 고치고, 경미한 문제는 기록해 두고, 리뷰어가 틀렸다면 근거를 들어 반박하라고 안내합니다.

이런 때 좋습니다

문제가 연쇄적으로 퍼지기 전에 기능이나 작업을 점검할 때, 병합 전.

참고 및 위험

낮은 위험:파일을 쓰지 않고 네트워크 요청도 하지 않는 지침 패키지이며, 쓰는 명령은 읽기 전용 git 명령(`git rev-parse`, `git diff`)뿐입니다. 사용하는 에이전트에 서브에이전트 도구가 필요하며, 없으면 시험 실행에서 보듯 모델은 자기 작업을 스스로 리뷰하는 대신 리뷰를 호출할 수 없다고 설명합니다. 리뷰어는 코드 변경분을 보게 되므로 비공개 코드를 넘기기 전에 모델이 어디에서 실행되는지 생각하세요. 일부 링크는 이 사이트에 없는 자매 스킬을 가리킵니다. 가상의 저장소로 한 번 시험 실행했습니다.