review について
review は実装前に仕様を批判的に検証するエージェントスキルで、影響範囲の大きい変更に適しています。コード、調査結果、テスト、文書を根拠に指摘を分類し、最後に GO または NO-GO を示します。
主な機能
- 01根拠に基づく仕様レビュー
- 02目標・不変条件・インターフェース・制約の確認
- 03重大度による分類
- 04テスト可能な強化条件の草案
- 05明確な GO または NO-GO 判定
活用シーン
- 01実装前の高影響変更のレビュー
- 02呼び出し元とのインターフェース変更の照合
- 03未対応のエッジケースの発見
- 04仕様修正を実装のゲートにする
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/reviewを入力して読み込まれたか確認します。
詳細
review — 実装前に仕様へ反証を試みる
すべての指摘には根拠を示してください。ファイル名:行番号、または情報源を記載します。根拠がない場合は [unverified] を付けてください。まず反証を試みます。証明できない欠陥も、見過ごすのではなく指摘します。
LLM は、自身の判断だけでは自己修正できません。放置すると、判断がずれたり劣化したりします。レビューを有効にするには、唯一有効な方法で修正します。つまり、コード、§R、テストスイート、ドキュメントという外部の根拠に基づく、独立した批判的なレビュアーを用意します。「問題なさそう」はレビューではありません。反証を試みることがレビューです。
レビューするタイミング
- 影響範囲の大きい変更（共有モジュール、認証、データ、金銭、公開 API）で、
/buildの前に行います。 - 他のコードが依存する §I または §V に仕様の変更があった場合に行います。
- 誤った実装のコストがレビュー1回のコストを上回ると、適切な規模の判断で示された場合に行います。
些細で、元に戻せて、十分に理解されている変更は省略します。タイプミスへの敵対的なレビューは欠陥を幻視し、予算を無駄にします。自己批判のパラドックスは現実です。
フェーズ 0 — 内容の把握
仕様を読みます。§G §C §I §R §V §T を確認し、全体を把握します。レビューするのは仕様であり、会話の記憶ではありません。
フェーズ 1 — 熟練レビュアーの構築
一般的な批評家ではなく、実際の判断力を持つレビュアーを用意します。
- コードベース — この仕様が触れるモジュールを grep で検索し、読みます。どのようなパターンや不変条件がすでに成り立っていますか？
- §R — 調査で何が明らかになりましたか？§R と矛盾する仕様上の判断は指摘事項です。
- 最新情報 — ベストプラクティスに関する主張に確信が持てない場合は、その情報を取得します。古くなった前提は欠陥です。
根拠のないレビュアーの意見に価値はありません。まず、その判断力を根拠によって確かなものにします。
フェーズ 2 — 反証
以下の観点から仕様を検証します。それぞれについて、どのような場合に破綻するかを探します。
- 目標と実態 — §G は実際の問題を解決しますか。それとも代替指標にすぎませんか？
- 不変条件の不足 — §V で検出されない問題には何がありますか？（指摘事項の多くはここで見つかります）
- インターフェースのずれ — §I は既存の呼び出し元が期待するものと一致していますか？（呼び出し元のファイル名:行番号を引用します）
- 制約の衝突 — 2つの §C の項目は矛盾していますか？いずれかが §R と対立していますか？
- 未対応の境界ケース — §T が扱っていない入力、順序、失敗、または並行処理のケースはありませんか？
- 粒度 — §T が曖昧すぎて実行できない、あるいは細かすぎて単なるタイピング作業になっていませんか？
フェーズ 3 — 分類
各指摘事項を 根拠 → 主張 → 重大度 の形式で記載します。
- BLOCK — この仕様に基づく実装で、実際の欠陥がリリースされます。先に修正が必要です。
- HARDEN — 実装で後退しないよう、§V に検証を追加または明確化します。
- NOTE — 知っておく価値はありますが、ブロックするほどではありません。
根拠がない場合は、重大度を NOTE に下げて [unverified] を付けます。勘を BLOCK に格上げしては⊥いけません。
フェーズ 4 — §V の強化とゲート
- 各 HARDEN の指摘事項について、対応する §V の草案を作成します（テスト可能で、対象となる §I または振る舞いを示すもの）。執筆するようspecに渡します。
- 明示的なゲートで締めくくります。
## review verdict
BLOCK: 1 — §I.api shape ≠ caller src/client.ts:40. fix §I before build.
HARDEN: 2 — drafted V8 (idempotent refund), V9 (tx around dual write).
NOTE: 1 — §T4 vague, split before /build.
gate: NO-GO until BLOCK cleared. then /build §T after spec writes V8,V9.
必ず GO または NO-GO を示し、曖昧なままにしません。レビューは、自信に満ちた誤った実装を止めるチェックポイントです。
境界
- SPEC.md を書いては⊥いけません。§V の草案を作り、spec に渡します。
- 根拠のない指摘を事実として伝えては⊥いけません。
[unverified]を付けます。 - 些細なことをレビューしては⊥いけません。適切な規模に調整するか、省略します。
- ユーザーの意図を書き換えては⊥いけません。強化するのは仕様であり、目標を置き換えるのではありません。