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 を指しています。架空のリポジトリで 1 回試用しました。