首頁 / 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 範圍,而不是整段對話歷史,所以它評判的是成果,而不是思考過程。範本把規格當作願景文件(沒寫不等於允許),要求審查者列出它沒有評判的內容,並回傳優點、分為嚴重/重要/次要的問題與整體評估。Skill 接著要求:嚴重問題立刻修,重要問題在繼續之前修,次要問題記下來,審查者說錯時帶著證據反駁。

適合什麼場景

在問題連鎖擴散之前檢查一個功能或任務,以及合併之前。

說明與風險

低風險:純指令檔,不寫檔、不連網;用到的指令只有唯讀的 git 指令(`git rev-parse`、`git diff`)。它需要你的代理具備子代理工具;沒有的話,模型會說明無法派出審查,而不是自己審自己的工作,試用中就是這樣。審查者會看到你的程式碼差異,所以把專有程式碼交給模型之前,請先考慮模型運行在哪裡。部分連結指向不在本站收錄範圍內的姊妹 Skill。已用一個虛構的倉庫試用過一次。