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。已用一个虚构的仓库试用过一次。